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

Lex Trotman elextr at xxxxx
Thu Sep 1 03:42:07 UTC 2016


On 31 August 2016 at 11:27, Matthew Brush <mbrush at codebrainz.ca> wrote:
> 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.

Agree with Matthew.

The point of not using the standard Scintilla lexer is to be able to
add semantic information made available for the language support
library in the FT-Plugin.

The major example of this is fixing the current situation where any
name that is a type in any scope is coloured as a type in every other
scope, even if the type is not visible there.

That means that the lexer is intimately tied into the FT-Plugin so it
likely won't run without the FT-Plugin anyway, so actually including
it in the plugin and accessing it via the container lexers interface
looks better than having a separate DLL that won't run by itself
anyway and then has to be sure its loaded at the right time.

Cheers
Lex

>
> Cheers,
> Matthew Brush
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel


More information about the Devel mailing list