[Geany-Devel] [FT-plugins] Proposed "Features"

Colomban Wendling lists.ban at xxxxx
Thu Sep 1 11:06:26 UTC 2016

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.


More information about the Devel mailing list