On 2016-08-30 06:43 AM, Colomban Wendling wrote:
Le 29/08/2016 à 05:14, Matthew Brush a écrit :
[…]
Syntax Highlighting
Most likely using an API based on/similar to Scintilla's "container lexers".
At the minimum, it could have a callback something like:
gboolean (*highlight)(GeanyPlugin*, GeanyDocument*, guint start_pos, guint end_pos, gpointer user_data);As with Scintilla's "container lexer", it would just tell the provider what and where to highlight. It might be pointless providing `end_pos` it could probably just highlight a whole line at time (maybe like Scintilla's 'style-needed' notification).
I'm really not sure it's a good idea to go the custom callback way. IMO, we should first try and see how easy it'd be with plugins providing their own full-blown Scintilla lexer library that we just add and use.
The only positive I really see, which in practice probably won't exist, is modularity and ability to re-use lexers independent of Geany/ft-plugin (ie. for all Scintilla-using apps). I say in practice because at least with my `LexClang.so` I needed it to be bound into Geany anyway to get hooks for when to re-parse (you can't re-parse a million token C++ file each time Scintilla wants to re-colour a line of code). Further, the dynamic lexer needs to cooperate with Geany/ft-plugin, or at least deviate from normal Scintilla lexers, if it wanted to provide/setup its own lexical states/styles (TBD how this part will go).
Having our own callback means one more indirection, and changing the SciLexer to CONTAINER anyway, so I don't see much advantage just now.
With the `LexClang.so` dynamic lexer I made, dynamic lexers seemed not to fit well (too isolated, too many assumptions that it's a simple dumb lexer and not a semantic-based on, etc) . All I really wanted was a way to disable Scintilla's lexer (ie. switch it to `SCLEX_CONTAINER`) without changing the filetype in Geany, and without doing it behind Geany's back from the plugin.
Cheers, Matthew Brush