Re: [ide-dev] Code editors in the Eclipse (IDE)

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

On 16.06.16 17:01, Fabio Zadrozny wrote:
> 
> 
> On Thu, Jun 16, 2016 at 6:15 AM, Sven Efftinge (sven@xxxxxxxxxxx
> <mailto:sven@xxxxxxxxxxx>) <sven@xxxxxxxxxxx <mailto:sven@xxxxxxxxxxx>>
> wrote:
> 
>     Hi Tom,
> 
>     comments inline...
> 
>     2016-06-15 13:42 GMT+02:00 Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx
>     <mailto:tom.schindl@xxxxxxxxxxxxxxx>>:
> 
>         The first and most important things needed are:
>         - syntax highlight (lexical!)
>         - block detection (for curly brace language this means matching
>           {},[],() pairs) used for highlighting and code-folding (although I
>           don't really see code-folding as an important feature at all)
> 
> 
>     I like to separate this between 
>      - services that can be done generically / based on "simple"
>     configuration and
>      - services that need an AST and workspace/project information
>      
>     The first are executed directly in the editor while the latter need
>     requests to some language engine (or server).
> 
>     For editor features there are more that come to mind like e.g. auto
>     editing and toggle comment.
> 
>         There are solutions available for that already:
>         - Angelo has TextMate support
>         - LiClipse has TextMate support & its custom spec format
>         - e(fx)clipse has its own format (who misses code folding as of
>         today)
> 
>         Although I'm not against having TextMate I repeat that the most
>         important thing for lexical highlighting is speed hence I'm not
>         sure the
>         TextMate route is the best way.
> 
> 
>     Could you elaborate on the performance issues you expect or have
>     faced with interpreting the TextMate grammars in Eclipse?
> 
> 
> ​I can elaborate a bit (explaining how it was done in LiClipse):
> 
> In LiClipse/LiClipseText, what I've done is mostly based on the Eclipse
> way of doing things, which supports the mechanism of partitioning and
> scanning (so, the document is split into partitions and later changes to
> a partition don't need to rescan the whole document).
> 
> In TextMate, the grammar is done by specifying a bunch of regexps which
> may be nested and reference other regexps... So, in LiClipse what was
> done was mostly by adding custom rules which deal with the TextMate
> format, but with those rules, it ends up having to reparse much more
> because of the way they are defined. So, this is a less performant
> because: 1. it relies on how well the author of the grammar did the
> regexps as the regexp itself may be a major slowdown and 2. much more
> needs to be reparsed (LiClipse is actually able to turn some cases into
> partitions, but that's not always possible and depends a lot on the
> grammar -- which didn't have this in mind when it was done -- on a
> number of times, it's possible that the whole document is reparsed).
> 

Thanks Fabio! This summaries my gut feeling on TextMate inside Eclipse.
I still think it is feasable to use it as a fallback strategy (which is
it for your as well if I got it right) but we should certainly have a
more Eclipse Text friendly declarative format.

Tom

-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck