[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ide-dev] Code editors in the Eclipse (IDE)
|
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