Sublime Forum

Syntax, auto-completion, tooltips and linting package for Sublime Text Settings

#1

Inspired by the following discussion I forked the EasySettings package to see what’s possible to make editing settings a bit easier.

The results of this brainstorming can be found here.

PackageDev already includes several syntax definitions for sublime files and helpers to create packages. Therefore we discussed whether to add syntax/completions/tooltips/linting of sublime-settings to this package.

But somehow I think it might not be too obvious this package provides support for such features. As my fork is no longer compatible with ST2 it might not be a good idea to replace the existing EasySettings package if the author even would be willing to. Therefore a pull request may not be a good idea, too.

That’s why I’d like to ask the community about what might be the best idea.

  1. Merge the features into PackageDev
  2. Create a new Package (maybe EasySettings3)
  3. Any better ideas?
2 Likes
#2

From my experience I think would be better the option 2. Create a new Package (maybe EasySettings3). Package dev has already a lots of features. So would be more manageable to introduce your new features through a new package because think it is better to KISS (Keep It Simple, Stupid):

  1. It would keep simple a new programmer start contributing, as there are less things to be worried.
  2. Also if someone has trouble with some of the system, he could easily debug they separately as there are less things to be looked into.

I think at some point, there is a limit between how much more you can break something keeping it simple and manageable. So you could not break too much. But as this package is specifically for user settings, most users could not bother about installing package dev, so for them would be better just to install this package. And if they found problems would be easier for them start fixing it.

I would advise to merge it with package dev if it has overlapping features, i,.e., both packages already offer these features for Sublime Settings files. But may be on this case these features could be deprecated from Package Dev and supported only by this package.

For reference, the package https://github.com/spywhere/Javatar had deprecated the autocomplete feature for maintenance overhead:

Auto-completion feature is a really great feature to have on Javatar. However, due to the development time and the feature scope of auto-complete, Javatar cannot implement the auto-completion within the expected time frame. To simplified the words, the auto-completion feature is cancelled.

0 Likes
#3

I’ve always felt that settings auto completion and linting for packages (as opposed to core Preferences) should be handled by a dependency on Package Control, and each package should instruct that dependency what settings are valid etc. (Although saying that, the dependency could handle the core settings too)
About the syntax definition, well, for most people, the standard JSON one is enough; for others - power users and package authors, I think that PackageDev’s will be the best one (when it’s complete/rewritten), and therefore shouldn’t need to be part of a separate package. (PackageDev already covers the other syntaxes, it’d be odd if it left this one out…)

0 Likes
#4

Saw this package after making my own… https://github.com/math2001/SettingsAutoCompletion :unamused:

0 Likes
#5

… each package should instruct that dependency what settings are valid …

This would definitely be a clean and good solution. I also thought about that, because GitGutter allows all package settings to be placed into a Preferences.sublime-settings by adding the prefix git_gutter_ to the keys.

The questions to answer are:

  1. What’s the easiest way for packages to mark certain keys as valid?
  2. How to support packages which may be no longer maintained or the author is not willing to put effort into supporting settings completion/linting? (e.g.: theme or color scheme packages)
  3. How can such a solution being built with least package dependencies?

In the end requesting a sublime-settings file with proper comments answers all these questions best at the moment.

For future use I am absolutely with you to somehow offer some kind of API to give packages the ability to provide valid settings just like the on_query_completions event does at the moment.

About the syntax definition, well, for most people, the standard JSON one is enough …

The functionality of my EasySettings fork does not require a separate syntax. It was added because of the idea to add everything to PackageDev. Nevertheless I find the idea of having an extended syntax for sublime-settings files quite interesting as it allows separate icons to be added to sublime-files (see A Icon File) and display the file type in the statusbar like Sublime Text Settings (JSON). Furthermore packages can use the separate scope to do certain actions or handle events for it only.

Default JSON misses the keys to be highlighted. Most color schemes just use the meta.structure.dictionary.key scope for highlighting which I find bad practice.

The Sublime Text Settings.sublime-syntax file included in my fork makes use of Default JSON.sublime-syntax and I do not intend to write a standalone syntax. It just alters default syntax by allowing an object at toplevel only and adding a keyword.other.name.key.sublime.settings scope to top-level keys.

I think that PackageDev’s will be the best one (when it’s complete/rewritten), and therefore shouldn’t need to be part of a separate package.

This leads to a very fundamental question: What is the primary intend of settings and keybindings completion? Is it meant to make package developement easier or do we want to help end users to customize settings?

From my point of view some features of PackageDev do address normal user use cases, which would be better placed into core or separate package. Editing settings/keybindings is one of them. As @addons_zz says: keep it stupid and simple.

0 Likes
#6

Sorry, didn’t see it, but the original EasySettings exists for years now. I used it for a while when I decided to have a deeper look into it due to several exceptions it raised from time to time.

I had a look onto your code. It depends on the side-by-side settings of ST and does not work if the base file is located within a sublime-package.

Traceback (most recent call last):
  File "C:\Apps\Sublime\sublime_plugin.py", line 673, in on_post_window_command
    callback.on_post_window_command(window, name, args)
  File "C:\Apps\Sublime\Data\Packages\User\SettingsAutoCompletion.py", line 49, in on_post_window_command
    window.extract_variables()))
  File "C:\Apps\Sublime\Data\Packages\User\SettingsAutoCompletion.py", line 13, in get_keys
    with open(file) as fp:
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Apps\\Sublime\\Data\\Packages/Default/Preferences.sublime-settings'
0 Likes
#7

PackageDev is intended to ease working with ST resource files of all sorts, which includes syntax definitions and settings files alike. However, your argument that it’s not exactly end-user-focussed is valid, which this particular feature is. An advantage of distributing this feature in PD would be that it gets shipped to many users already, but on the other hand it might be extending its scope too much. On the plus side, we could rely on proper scoping for providing the completions, since a reliable syntax definition will be provided by the package.

I’m not too convinced of a Dependency for this. It seems too impractical and would most likely only get used by a handful of packages and it would then also become a feature that the user themselves didn’t request when they install a random package that makes use of it.

2 Likes
#8

You exactly point to the thoughts which made me start this thread.

I like PackageDev because it provides interesting features to ease the work with ST files. Having everything in one package makes things easier for users as they don’t need to look out for a couple of packages which may interfere with each other and introduce some unhandled/unwanted side effects.

If PackageDev is meant for resource files in general, adding the EasySettings stuff in there may be a good idea.

But the name of the package doesn’t really tell about this wide scope.

I’m not too convinced of a Dependency for this.

If some kind of plugin API may be considered it should work like ST’s API. A package would need to export a certain interface class which is loaded by the EasySettings module, just like the EventListeners. But from my current point of view, asking package devs to place a sublime-settings file to their package is the easiest and safest solution. @ihodev already did so for his Boxy Theme :wink:

0 Likes