You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for creating this! It's been super helpful — I've been using this for more than a year now.
One thing I noticed is that this extension does not appear to conform to how Sublime structures extensions, as a result, every time a new version of this plugin is released, the plugin-wide settings will be deleted. The reason why is that there appears to be no way of setting a 'user' settings file for extension wide settings.
To illustrate, these are the options on my Sublime:
1 Preferences > Package Settings > Typescript > Plugin Settings — Default
Works
2 Preferences > Package Settings > Typescript > Plugin Settings — User
Does not exist, redirects to general user settings of the whole of Sublime text
3 Preferences > Package Settings > Typescript > Typescript Settings — Default
Works
4 Preferences > Package Settings > Typescript > Typescript Settings — User
Works
The #2 needs to exist so that the users have a place to save their own configuration that is retained across updates. This is not so simple as just creating the file, because the way the config files are named makes impossible for #2 to exist. Like this:
In a hypothetical Sublime extension called 'Acme', there are two config files:
1 One called Acme.sublime-settings and it lives in Packages/User. This is the user's own config file that persists between updates
2 One called Acme/Preferences.sublime-settings. This lives in Packages/Acme and this is the file that gets deleted and recreated when the extension updates
The issue with this package is that there are two config file sets — in the extension folder, there is both Typescript.sublime-settings and 'Preferences.sublime-settings. The former is the extension settings (let's say ExtConf) and the latter is the typescript settings (TSConf). The issue is that this doesn't work — ST will try to create a Typescript.sublime-settingsin the User folder to match thePreferences.sublime-settings` as the user version of the ExtConf, but that is the file that is being looked for the user version of the TSConf by the extension, and not for the user version of the ExtConf. This makes it so that it is impossible to retain user's own extension preferences for this extension across updates.
I'm not really sure I understand this issue (I don't use ST3, and have always used Preferences.sublime-settings for an TS settings in testing ) but we're open to PRs moving us to this model, so long as it doesn't break backwards compatibility for existing users.
I'm not really sure I understand this issue (I don't use ST3, and have always used Preferences.sublime-settings for an TS settings in testing ) but we're open to PRs moving us to this model, so long as it doesn't break backwards compatibility for existing users.
And there is a very important thing: the default settings file Preferences.sublime-settings do not show all acceptable settings, a good PackageName.sublime-settings file is important for users (Note: .sublime-settings can be comment).
When I want to disable the underline of highlight variables, I don't know how, and I just google it, find this #717 (solve it by set "typescript_highlight_occurrences": false), however, this option don't show in docs :(.
Hi there,
Thanks for creating this! It's been super helpful — I've been using this for more than a year now.
One thing I noticed is that this extension does not appear to conform to how Sublime structures extensions, as a result, every time a new version of this plugin is released, the plugin-wide settings will be deleted. The reason why is that there appears to be no way of setting a 'user' settings file for extension wide settings.
To illustrate, these are the options on my Sublime:
The #2 needs to exist so that the users have a place to save their own configuration that is retained across updates. This is not so simple as just creating the file, because the way the config files are named makes impossible for #2 to exist. Like this:
In a hypothetical Sublime extension called 'Acme', there are two config files:
1 One called
Acme.sublime-settings
and it lives inPackages/User
. This is the user's own config file that persists between updates2 One called
Acme/Preferences.sublime-settings
. This lives inPackages/Acme
and this is the file that gets deleted and recreated when the extension updatesThe issue with this package is that there are two config file sets — in the extension folder, there is both
Typescript.sublime-settings
and 'Preferences.sublime-settings. The former is the extension settings (let's say ExtConf) and the latter is the typescript settings (TSConf). The issue is that this doesn't work — ST will try to create a
Typescript.sublime-settingsin the User folder to match the
Preferences.sublime-settings` as the user version of the ExtConf, but that is the file that is being looked for the user version of the TSConf by the extension, and not for the user version of the ExtConf. This makes it so that it is impossible to retain user's own extension preferences for this extension across updates.Here's one example of two-config-file setup that does it right:
https://github.com/victorporof/Sublime-HTMLPrettify
Hope this helps.
The text was updated successfully, but these errors were encountered: