Packages
Packages copied to clipboard
sublimehq
[TeX.DocStrip] Basic DocStrip support
This PR adds support for the DocStrip format of TeX, used by many LaTeX packages to specify their installation.
https://www.texlive.info/CTAN/macros/latex/base/docstrip.pdf
I've inherited from the base TeX syntax, and just prepended the new commands to the main context. This is not quite accurate, in the sense that many plainTeX constructs would simply be invalid in a docstrip file -- as there is no typesetting to be done, typesetting and math commands don't really make sense. But I think it is OK to highlight these commands, and probably better to handle things like this, because if we manually select the subset that is supported, and later on add something new in TeX that also works in DocStrip, we might forget to change DocStrips main context.
In general, DocStrip files are usually rather short and simple, and typically look like the examples given in https://texdoc.org/serve/dtxtut.pdf/0 (appendix A).
Finally, since the goal is not to produce typeset output, but instead to describe how files are generated, I've used a source main scope.
I've used a
sourcemain scope
This means that color schemes which have defined special highlighting rules for TeX/LaTeX (which seems quite possible because LaTeX isn't really comparable to the other programming or markup languages and for historic reasons the syntax doesn't pay much attention to the scope naming guidelines), by using the text.tex base scope, would need to define the same rules again for the source scope in order to make them work with such files too. It isn't really a backward compatibility break, because the .ins file extension wasn't recognized by the LaTeX syntaxes before, but it seems that those files would be highlighted relatively well with the regular LaTeX syntax and I wonder whether changing the base scope would have do anything useful. And in general to change the base scope from text to source while extending a syntax seems quite unprecedented afaik.
https://github.com/sublimehq/Packages/issues/3531 contains some discussion about source vs. text and why the one or the other may (or may not?) be more suitable for some of the file types - mainly due to purpose though.
Note: Any feedback of experienced LaTeX users is very much appriciated. I can give only technical support on all those PRs as I don't use it at all.
@ngc92 FYI: if you click the Edit button at the top right to change the pull request title, you can click the target branch right below it on the left side and change it from master to develop/latex.
Maybe we should keep going with text.tex. ... main scope for compatibility reasons with existing color schemes.
Is this really an issue? First, the ins files would not even have been recognized by default before, and second, almost any command that appears in a typical ins file will have a different scope that if you were to highlight as TeX, as all the commands would be scoped as unspecific support.function with standard TeX syntax.
Conceptually, I guess the .ins file is somewhat comparable to a Makefile, and these are also scoped source.
TBH, I am a bit uncertain about it. While being fine with scoping source code source, arguments about backward compatibility with existing maybe no longer maintained color schemes is to be considdered.
I don't have any numbers about possibly effected color schemes.
Default color schemes wouldn't be effected however.
We've actually haven't switched from text. to source. by inheritance in any other syntax yet. TeX may be special or original text. main scope was just not so well choosen with regards to the nature of TeX.
The .ins extension hasn't been assigned to a syntax by intent, I guess. It's quite generic and may be used by various syntaxes.
So we should not add that at this point.
@ngc92 Could you close and re-open? I had tried fixing CI for your pulls against develop/latex in #3636.
Do we really want to bind *.ins file extension to that syntax?
Probably high risk of false positives, no?