Projects Customization Roadmap?

[tajmone]

I would like ST to offer more customization power inside projects. By searching the forum I’ve noticed that this topic comes up quite often, so there seems to be a general need for this.

From what I understand, currently you can only rely on the *.sublime-project file to customize how ST should handle a specific project; but in real-life usage ST users would benefit from a broader customizable spectrum.

For example, snippets. Some snippets might be useful in a project but interfere in others, so having a way to confine snippets to a single project would be really cool. For example, I have tons of snippets for a given syntax, but they fall into different groups according to locale (Italian vs English), and when I’m working on a English project I have to remove the Italian snippets folder for ST package folder otherwise they clutter up the working session — and viceversa, when working with Italian I have to remove the English snippets folder.

The ideal solution would probably be via introduction of specially named folders which can be placed inside a project tree (eg .sublime) which ST would then load only when that project is active. This folder should be treated just like the packages folder, thus allowing any valid ST configurations to be loaded and override base settings.

From what I’ve read in the technical answers, it seems that there are some problems with this as ST has some code handle plugins, etc. which is shared by all running instances of ST.

I hope a solution could be found to this, eg. by changing the way ST instances work when in “project modality”, thus allowing to have highly customizable projects. I think this would be a great improvement not only in terms of how users could organize their personal work, but also in terms of community shared projects — eg. over Git.

Just think, how nice would it be to clone a project from GitHub and find that when you open it in ST you find that it also provides snippets, completions, commands and other project-specific useful stuff?

Any chances this might happen at some point in the future? Or would it require too much rewriting in ST core and it’s therefore never going to happpen?

[Remi]

Well snippets have scope selection baked in so it might be possible to filter using that, however your source file would have to have something that identified them as language=italian, or language=english in the syntax. If that’s the case you might be able to have two sets of snippets.

It is possible to put other settings in a project file as well. I do that with VHDL Mode and your commands can use that to override a personal setting. Might not help snippets though because that’s not a full on API TextCommand.

[tajmone]

Well snippets have scope selection baked in so it might be possible to filter using that,

This approach sounds promising. I’ll look into it. My only concern is for the shared snippets — i.e. if adding an extra segment to the syntax scope might jeopardize the shared sniipets. But probably this isn’t the case.

however your source file would have to have something that identified them as language=italian, or language=english in the syntax. If that’s the case you might be able to have two sets of snippets.

I had though of using file extensions variations for this — either via a secondary extension (*.alan -> *.en.alan/*.it.alan) or different ones altogether (*.alanIt/*.alanEn), but the latter might complicate things a bit.

The first_line_match in syntax files could also have been exploited to check for a in-comment patter (eg -- !#en) but it looks like this is only used when the extension isn’t registered/known:

( https://www.sublimetext.com/docs/3/syntax.html#header )

The allowed keys in the header area are:

• name. This defines the name shown for the syntax in the menu. It’s optional, and will be derived from the file name if not used.
• file_extensions. A list of strings, defining what file extensions this syntax should be used for
• first_line_match. When a file is opened without a recognized extension, the first line of the file contents will be tested against this regex, to see if the syntax should be applied.

Anyhow, various factors have to be taken into consideration, for I’d avoid ending up having ST see 3 different syntaxes altogether (Alan, Alan Italian, Alan English), but instead only add an extra scope (as you said).

Would the best thing be to tail-append the locale scope to the lang (e.g. source.alan -> source.alan.en) or tail-sufiix it (e.g. source.alan -> source.en.alan)? I’m not sure what sort of impact this could have on the various scope expressions of the main syntax, snippets, completions or color schemes.

Defintely, if the projects themselves could have a dedicate folder that ST would use for extra snippets, completions, etc., it would be a much easier and portable solution — especially since contributors could add their own snippets via Git, while this solution would only work for either private projects or a specific syntax-related package.

It’s a pitty that many configurations in ST are confined to the package folders only.

[Remi]

I tinkered with Inform long ago, but had never really played with Alan. Do you have a link to the repository with the different snippets and syntax? Just seeing what sorts of things changes between Italian and English might be valuable.

It is possible to manually set the syntax for a file as well which may be of some use. AlanItalian.sublime-syntax and AlanEnglish.sublime-syntax could coexist. One would be chosen automatically, but if you found yourself in the other language, you could switch.

In that manner if you had two syntax files marking with language specific scopes, you definitely could have source.it.alan and source.eng.alan. Snippets could definitely coexist at that point and be scoped for each variation.

It’s not as nice as an automatic detection method, but it could be a workaround. There are a lot of syntax experts floating around and there might very well be a better solution.

[tajmone]

Do you have a link to the repository with the different snippets and syntax? Just seeing what sorts of things changes between Italian and English might be valuable.

Sure! The Alan syntax is one and the same, the English vs Italian differences comes with the Standard Library (Alan doesn’t provide any infrastrcture, verbs, etc, just the base classes and the language to build on from scratch).

This is the Italian library (Alpha WIP) which I’m working on:

• https://github.com/tajmone/Alan3-Italian

And this is the upstream English library which I’m translating:

• https://github.com/AnssiR66/AlanStdLib

This is the Sublime-Alan package that I’m working on:

• https://github.com/tajmone/sublime-alan

It’s far from complete, but it’s making my life a lot easier during the intense library translation/editing code, especially for the test suite where I have to write lots of small test adventures and time play a huge factor.

In that manner if you had two syntax files marking with language specific scopes, you definitely could have source.it.alan and source.eng.alan. Snippets could definitely coexist at that point and be scoped for each variation.

Having to manually set the language wouldn’t be a big deal, after all working sessions are preserved when you reopen ST or switch projects. What I’m not sure here is how the basic Alan syntax definition could be shared with all three without having to duplicate it — basically, the Alan.sublime-syntax is one and the same, the libraries just define custom classes, verbs, etc., for which I’ve created lots of snippets that simplify and quicken writing code with.

Maybe ‘Alan Italian’ and ‘Alan English’ could just include the main ‘Alan’ syntax, as if it was an embedded syntax? I haven’t yet had a chance to work with embedded syntaxes, so I have no idea if that would do the trick (kind of wrapping Alan into a parent scope).

Surely, those snippets make the whole programming/authoring experience much smoother for writing IF is mostly a pattern-ripetitive work (verbs, syntaxes, room, etc.) and tab-navigable snippets are a blessing for this.

[mlf]

The ideal solution would probably be via introduction of specially named folders which can be placed inside a project tree (eg .sublime) which ST would then load only when that project is active. This folder should be treated just like the packages folder, thus allowing any valid ST configurations to be loaded and override base settings.

A security nightmare, then. You clone what you think is a some source code you would like to check, open it on ST, and, woops, your hard drive is empty (if you are lucky).

[tajmone]

Mhhh. Maybe only non Python script stuff, like snippets and completions — that shouldn’t pose a threat. Probably snippets are most useful stuff to share in project, especially in libraries where dedicated coding template are useful that wouldn’t otherwise be helpful elsewhere (and having them in a package or the User folder would just clutter up things).

But then, isn’t the security issue you mentioned also true for any third party package that one installs?