Geany/dobkeratops/Rust

[Neil Hodgson]

Someone called dobkeratops has been trying to add Rust support to Geany and get a Rust lexer integrated into Scintilla by sending a pull-request from GitHub through the SourceForge messaging system. Replies through SourceForge fail. The pointed to repository has multiple branches and the only Rust lexer that looks viable is nothing more than taking the D lexer from a previous release and substitute/d/rust/.

It would be great if someone from Geany could work out what is happening and, once the lexer is working well, create a patch and attach it to a feature request issue.

Neil

[Lex Trotman]

Hi Neil,

Thanks, the OP has been getting assistance on the Geany IRC list. It has
already been suggested to him that he submit the lexer via the ML. When it
is more ready I'm sure he will send it again.

Cheers
Lex

Post by Neil Hodgson
Someone called dobkeratops has been trying to add Rust support to Geany
and get a Rust lexer integrated into Scintilla by sending a pull-request
from GitHub through the SourceForge messaging system. Replies through
SourceForge fail. The pointed to repository has multiple branches and the
only Rust lexer that looks viable is nothing more than taking the D lexer
from a previous release and substitute/d/rust/.
It would be great if someone from Geany could work out what is
happening and, once the lexer is working well, create a patch and attach it
to a feature request issue.
Neil
--
You received this message because you are subscribed to the Google Groups
"scintilla-interest" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/scintilla-interest.
For more options, visit https://groups.google.com/groups/opt_out.

[d***@gmail.com]

Hi,
Initially i cloned the D lexer. i figured if i get a placeholder in, its there if someone else wants to do those changes in parallel whilst i'm focussing on geany.

thinking about it more, perhaps its better if the C lexer in scintilla got additional options to handle rust

In order of importance, the issues I have are:-
[1]'lifetimes vs 'strings' [2]keywords [3] :types


[1] Need to disable Single quoted 'literals'/ 'string literals'
unless i hack the color coding, i get rust pointers showing up highlighted as errors
eg fn foo<'a,'b,A>(ptr:&'a A ptr2:&'a A, ptr3:&'a Aptr4:&'b A)->&'a A ...
// it thinks its an unterminated string :( so highlights the background

[2] different keywords - easy enough, but

[2.1] Keywords++ i want more keyword contexts. declarations vs modifiers vs structural. Really helps seeing whats going on eg if you have many windows open and you use 'missioncontrol' or 'expo'/scale' color coding guides the eye.
Rust has more keywords to differentiate elements- instead of just 'classes',you have struct(data)/trait(interfaces)/impl(ementation). and a nice 'fn' keyword highlights function definitions too.

[3] types- rust introduces types with ":" same as scala
so its easy to color code them in function signatures.. This is not just eye-candy: it really helps when alternating between reading C/C++ and Rust.

the exception is Struct{member1:initialize expr , member2: initialer expr..} i would be happy to introduce a space to differentiate that.
eg
varname:type /* no space between :type*/
member: initalizer expr /* member: */


[4] highlighting of <type parameters> - i have this showing up really nicely in Gedit with just regex. really helps clarify complex function signatures. I'm happy to disambiguate < > in expresions with ordering > < and extra parens if needbe. type params are way more common than expressions needing both < and > in that order.
Rust makes generic programming easier (polymorphic lambdas, no headers, traits=c++ "concepts"++) so rust programmers can really go to town writing generic code, if in doubt parameterize it and its more re-useable.


Could these be added to the(?) general purpose C lexer in scintilla, and a host program simply differentiates Rust with various options..
how to handle ' - char literals(C), string literals(JS), other(rust)
how to handle ":" nothing special (default), or highlights types (Scala, Rust) with my suggested space 'hack'
:[A-Za-z] is recognized and highlighted as a type
:\w+[A-Za-z] is not

[Neil Hodgson]

Post by d***@gmail.com
Initially i cloned the D lexer. i figured if i get a placeholder in, its there if someone else wants to do those changes in parallel whilst i'm focussing on geany.

There is a lot of complexity in the D lexer which should not be needed for Rust and this makes the code more difficult to work with. For example, D has nested comments but most languages, including Rust, do not. The first thing that should be done when converting a lexer is to remove all features that will not be needed.

Another problem is the relationship between the generic and D-specific settings with, for example, both fold.at.else and lexer.d.fold.at.else being used. This only occurs because of the history of the lexer and should not be continued. Apart from the basic 'fold' setting, all settings should be namespaced to the lexer.

Post by d***@gmail.com
thinking about it more, perhaps its better if the C lexer in scintilla got additional options to handle rust

This depends on the amount of change needed to allow the C lexer to handle Rust.

Post by d***@gmail.com
In order of importance, the issues I have are:-
[1]'lifetimes vs 'strings' [2]keywords [3] :types
[1] Need to disable Single quoted 'literals'/ 'string literals'
unless i hack the color coding, i get rust pointers showing up highlighted as errors
eg fn foo<'a,'b,A>(ptr:&'a A ptr2:&'a A, ptr3:&'a Aptr4:&'b A)->&'a A ...
// it thinks its an unterminated string :( so highlights the background
[2] different keywords - easy enough, but
[2.1] Keywords++ i want more keyword contexts. declarations vs modifiers vs structural.

At this point, it looks like a separate lexer is needed.

Neil