Auto edits

14 views
Skip to first unread message

Simon Schäfer

unread,
Feb 10, 2015, 10:07:08 AM2/10/15
to scala-...@googlegroups.com
There is the pending auto edits PR available, which I would like to get
through: https://github.com/scala-ide/scala-ide/pull/886

Iulian asked for some more information about its goals, therefore in the
following my thoughts:

The main design goal is to have an Eclipse/JDT independent and pure
Scala based implementation for auto edits. In the long term, I expect
that this increases maintainability and extensibility of our codebase.

Maintainability:
Because the Scala editor extends the Java editor, there are two places
where key events are handled, where they should only be handled only in
one place. In fact, at the moment, there are at least four places where
key events are handled (which seems to be grown due to historic
reasons), which leads to some limitations in our current implementation.
For example it is not possible to create linked models (the green bars,
which are known from the Java editor and which allow to edit multiple
regions simultaneously) with classes that extend `IAutoEditStrategy`.
This is why the Java editor doesn't use `IAutoEditStrategy` as
extensively as the Scala editor does. When I created most of the auto
edit strategies, I didn't know about this limitation. With auto edits
these problems are all gone and we only have a single point where key
events are handled (acutally, the key event is still forwarded to the
Java editor when it is not handled by the Scala editor. The Java/Eclipse
editor still provides some useful functionality, which I didn't want to
recreate. But I can't remember right now which functionality this is).

Extensibility:
I don't like the design of the Eclipse editor or of Eclipse based IDEs
in general. They are monolithic kernels, as most operating systems are.
Editors like vim and emacs aren't designed in this way. They provide a
small kernel and a plugin system which allows users to add their own
functionality. In contrast to Eclipse bundles which contain binaries,
these plugins are distributed by source (because they are implemented by
interpreted languages) and therefore can easily be updated. I believe
that Scala IDE also needs to follow that direction. In future I would
like to move all auto edits, save actions, refactorings etc. out of the
main scala-ide bundle and provide them separately. This way we can
easily update them without the need to update the major/minor versions
of the IDE. Another chance I see by this design is that users can more
easily create and ship their own functionality. Especially vim was
extremely successful with this model - its users created thousands of
plugins, where none of the most used plugins were created by the
designers of vim by themselves (and I guess all other available editors
are similar successful with this model). An IDE makes such a model more
challenging for users to handle it correctly, but I think it is still
worth it (and Scala already has macros and users can handle them too).

Auto edits are created with these design goals in mind. They are not yet
fully there but mostly because of minor issues. For example, the auto
edit API is not yet as powerful as the one of Eclipse - mainly because
making it more powerful would result in just wrapping the Eclipse API,
which doesn't buy us much for now. But in future it should be possible
to update the API, without the need to reimplement everything, as it was
partly done for the above pull request. Also, some of the old auto edit
strategies are not yet moved to the new API, mainly because it is boring
work to do. But this is nothing, which should block the PR.

If someone has some spare time to give it would be nice if they could
test the PR and report back problems. The build bot even provides update
sites for the pull requests to easily test them, but I forgot at which
URLs they are available. If you have further questions, just ask.
Reply all
Reply to author
Forward
0 new messages