Ok, great to hear. I'll have a look if there is something we could
use.
So yeah, for example: content assist, code snippets
("Templates" in JDT lingo), preference pages for all that,
outline and quick-outline (no hierarchical outline support
though).
However, no Junit view, nor package explorer support. Well not
for displaying Java-like flat packages at least, but there is
some support for other Project Explorer extensions: stuff like
project dependencies and (in an upcoming version) build
targets. I dunno how well that applies to Scala though.
No code folding support either (DDT has that functionality,
but it's crappy code copied from DLTK that hasn't yet been
cleaned-up/refactored, and put into LangEclipseIDE).
One interesting thing that LangEclipseIDE has, that doesn't
come from JDT or JDT-like IDEs, is functionality to help you
integrate external, command-line tools to provide IDE
functionality. For example in Goclipse, the outline is
provided by an external parser (updated on the fly as the user
types in the editor). Again dunno if that would apply well to
Scala.
Calling command line tools is not necessary in Scala IDE, since all
the tools are already written in Scala and therefore can simply
added as a library to the IDE.
Sidenote: Funny enough, unlike JDT, the Goclipse outline is
updated almost instantly as the user types, because there is
no artificial delay to start the reconciler (I dunno why that
delay is in JDT in the first place). Not that it matter much
anyways - personally I haven't used the Outline view in ages,
Quick-Outline is much more handy.
We use the reconciliation time because the Scala compiler is slow as
hell and takes enormous resources during compilation. It can't be
aborted during compilation of a single file either. Therefore,
calling it on every keystroke would more or less be impossible.
Given that the Scala compiler is so slow a lot of APIs can't be used
or make some features difficult to implement. Code completion for
example can take some seconds before completion. Because the JDT API
just takes a list of completions we have to block users until the
compiler is finished. If the API would take a potentially infinite
stream of completions, we wouldn't have to block but could show new
completions once they appear. This forces us more or less to
re-implement all APIs in a non-blocking/reactive way and makes it
more difficult to use work from others because for most languages
one does not need to think about the compiler being to slow.
Scala IDE dev
here. A few years ago I would have welcomed such a
project, nowadays I lost faith in the Eclipse
platform. There are too many internal issues and
limitations that make using the eclipse.core and
especially the jdt.core API a pain. This means that
over the years we reduced dependencies to these APIs
as much as possible and replaced them with our own
implementations.
We still depend on JDT because that is how we started
and while our core is ready in moving away from JDT
our UI is not. JDT provides some useful stuff like the
package explorer, the outline view, the junit
integration etc. and we don't have the resources to
replace them by ourselves. Do you have any plans to
provide programming language independent UI
components? This could make your project useful to us,
for core API we probably don't have a need anymore.
On 07/03/2015 03:34 PM, Bruno Medeiros wrote:
Hi guys. Doug pointed me to this
mailing list, so I wanted to let you know
about a project I've been working on:
LangEclipseIDE.
LangEclipseIDE is a framework/library for
building language IDEs on top of Eclipse. It
aims to provide common functionality that is
present in IDEs like JDT or CDT but is not
refactored out into an externally reusable
component. So the aim here is similar to DLTK,
but the overall design is different in some
ways (even though we reuse bits of code from
JDT and DLTK).
LangEclipseIDE is currently used by 3 IDEs:
DDT, RustDT, and Goclipse. It's still a young
project so there is much more that could be
done. It would be nice to get some
collaboration going with other IDE projects as
there is a lot of potential for that.