Ciao.
I would like an opinion on how I’ve been handling a problem in a package I’m creating; ie., if I’ve taken the correct approach to solve it.
The solution I came up with works, but I was wondering wether it is elegant or not, if I could have taken a better approach, or if indeed it might pose a problem if I were to decide to publish the package for general use.
Link to the project mentioned here:
The Problem
Basically, I’m working on a language syntax, but I also want to the compiler errors report from Build operations to be syntax highlighted in order to use colors to make the log more readable in ST console.
Here is the achieved result:
… I’m just wondering if the end justifies the means! ie: if in my attempt to achieve this I’ve “bent the rules” to the point of making the package unfit for distribution.
Adopted Solution
In short:
- I’ve created an hidden syntax definition to highlight the Build log from STDIN
- I’ve set the Build System to use this hidden syntax to highlight results
- I’ve hidden in the default color scheme of my package an extra section targetting the scopes of the hidden syntax
- I’ve added in the hidden syntax settings to always use that color scheme
Hidden Syntax Definition
I’ve decided to take advantage of the Build Systems syntax option, so I’ve added to my package an extra syntax called Alan Compiler Output.sublime-syntax which is inteded solely for highlighting the compiler output from Build operations.
In fact, I’ve declared it as hidden:
name: Alan Compiler Output
comment: Colors Alan build sytems error report
hidden: true
scope: text.alancompiler
And I didn’t asociated any file extensions with it either, since it will only be used to highlight text coming from STDIN.
I’ve then added to my package’s Build system settings to use this syntax to highlight the compiler’s output:
// "Alan.sublime-build"
{
"shell_cmd": "alan -cc \"$file\"",
"working_dir": "$file_path",
"selector": "source.alan",
"file_patterns": [ "*.alan" ],
// ===========================================================================
// Capture Errors and Warnings from Compiler Output for Results Navigation
// ===========================================================================
// Whith `-cc` option, Alan reports have this form:
// "sourcefile.alan", line 5(24): 101 E : Error message.
// "sourcefile.alan", line 8(13): 200 W : Warning message.
// ---------------------------------------------------------------------------
"file_regex": "^\"([^\"]+)\", line (\\d+)\\((\\d+)\\): (.*)$",
// ===========================================================================
// Syntax Highlight the Compiler Log (WIP experimental feature):
"syntax": "Packages/Alan/Alan Compiler Output.sublime-syntax",
}
Color Scheme Problem and Solution
The real problem was (is) the color scheme for highlighting the results in ST console.
The syntax I’ve created for the purpose uses highly arbitrary scopes (I have no idea how a log file should be scoped), after all its only intended for “internal use”.
Which means that a dedicated color scheme is required to cover these scopes and achieve the desired coloring results.
Hijacking the Package’s Scheme
So, what I did, was to take advantage of the color scheme that I’ve created for this package, and add at its end a block of settings targetting specifically the scopes of the highlighted log.
In the Alan DarkFluo.sublime-color-scheme file, I’ve added at the end:
},
// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
// Alan Compiler Output Syntax
// /////////////////////////////////////////////////////////////////////
// The following colors are used to syntax highlight Alan compiler's
// output during Build operatrions. The output is captured through the
// "Alan Compiler Output" syntax definition, which is hidden to the user
// and used only in build systems. Regardless of which color scheme the
// users assigns to Alan syntax, the settings for "Alan Compiler Output"
// will always refer to this color scheme in order to ensure that the
// compiler output is colored as expected. The scopes for this syntax
// are rather arbitrarily chosen, as there is no real use for them beside
// coloring the error messages.
{
// Base Text Color
"name": "Base Color",
"scope": "text.alancompiler",
"foreground": "var(grey)",
"background": "#000000", // transparent
"font_style": "",
},
{
// Strings
"name": "Strings",
"scope": "string.quoted.double.alancompiler",
"foreground": "var(tint3)",
"background": "#000000", // transparent
},
… where all the rules are targetting specifically the text.alancompiler scope, and should therefore not interfere with other languages using this color scheme. Also, I’m using text scopes here, instead of code.
The idea is that although the user might not be actually using the color scheme supplied with the package for any syntax, the hidden syntax used to highlight the compiler output can rely on it being present in the package, and thus use is to color the log syntax.
Enforcing the Scheme on the Hidden Syntax
I then added to the package a Alan Compiler Output.sublime-settings file, which enforces the color scheme on the ``Alan Compiler Output` syntax:
{
"color_scheme": "Alan DarkFluo.sublime-color-scheme",
}
Whilst I know that packages should not usually fiddle with settings, I’ve reasoned that:
- This being a hidden syntax not intended for end-user direct use, it’s ok to enforce some settings on it.
- Since there seems to be no way to create a hidden color scheme, the only viable approach was to take advantage of the scheme that ships with the package.
Conclusion
As mentioned, this works, and actually looks nice since the output is nicely colored: each error type receives a specific colors combination, making it easy to read through long error reports.
Since I’ve only published one package so far, and I even with that one I had to fix some settings before it was accepted on Package.io, I wanted to know if this approach I’ve taken is OK.
Also, I didn’t know how to scope the error log from the compiler; so, right now I’ve used arbitrary scope, and even went as far as using meta scopes in the color scheme rules (but only for the hidden syntax!).
Where can I find references or examples on how to scope log files and the like?
Thanks,
Tristano (Italy)