Le 31/08/2016 à 03:27, Matthew Brush a écrit :
On 2016-08-30 06:43 AM, Colomban Wendling wrote:
Le 29/08/2016 à 05:14, Matthew Brush a écrit :
[…]
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.
Okay then, if there's good reasons to do so, fine.
I just thought that it would be handier if later on plugins want to be able to add new filetypes altogether (e.g. not necessarily based on lib<language>, but just filetypes), but maybe not, or maybe it's not good for all cases.
Regards, Colomban