[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-architecture-council] Javascript: a bug that makes me really sad....
|
On 2015-07-06 21:47, Doug Schaefer wrote:
For what it¹s worth, I think Michael was talking about *DT not *DK. JDT,
not JDK.
Thank you Doug, for clarifying that. This is exactly what I meant: *DT
A common AST, at least partial to model symbol references and definitions,
is indeed necessary for inter-language features. We have had that in CDT
to handle things between C++ and C (and, yes, they are two different
languages). We all have lots of experience building IDEs and editors and
probably different philosophies on how to do it. It¹ll be interesting to
see if we can find common ground.
In addition to a common AST, we should also think about a *very* simple
API that allows external tools to contribute to any editor highlights
based on the position in the file (line:column data). Most "smart editors"
have have APIs to run external tools, once a file is saved and they parse
the output of stdout. The output is simple position information with
some data to be visualized. With such an interface you can
- run lint tools to find all kinds of errors
- run build tools to visualize build errors and warnings
- run code coverage
- run profile tools
- run unit test
- run tool to get syntax and semantic highlights
- run something like http://ctags.sourceforge.net for code navigation
- run an external tool for code completion or use a generic
code completion tool based on codetrails
- run tools, that automatically format code
- follow standards like editorconfig.org
Depending on the configuration, the external tools should
be able to
- set font, color, background color of text
- add icons, colors etc to the gutter (with additional
information in tooltips)
- in the file/project exprorer(s), add color, font face, label text,
overlay icons etc
- provide data for generic code coverage views, profiler views
and test-runner views. The interface here would be some data
and not a Java API. There could be a Java API as well, but
one implementation would be to read the data from external
tools.
The point is that it is often easier to use existing command-line
tools (or tools that continuously run in the background like
gulp and grunt) and parse the output than to write everything
in JAVA.
Instead of implementing a more or less complicated Java API,
all you do is transform the output of those tools into a
"canonical" form. Instead of a single canonical form, there
could be parsers for common output formats and the could
choose the format that is most convenient to support with
the existing command line tool.
If there would be a generic (declarative) interface to setup
the command line tools, then eclipse could really well compete
with "smart editors".
And even for Xtext generated *DT, integration of external tools
like linters, test, coverage and profile tools should be simple.
The vision is, that integrating a new external tool to any
existing eclipse editor or *DT should be possible without
special preparation of the *DT provider. Ideally, the external
tool extensions would work with with *any* (text) editor in any *DT
and *any* file/project explorer.
Michael
Doug.
On 2015-07-06, 1:28 PM,
"eclipse.org-architecture-council-bounces@xxxxxxxxxxx on behalf of Sven
Efftinge" <eclipse.org-architecture-council-bounces@xxxxxxxxxxx on behalf
of sven.efftinge@xxxxxxxxx> wrote:
On 06 Jul 2015, at 18:45, Michael Scharf <eclipse@xxxxxxxxx> wrote:
- Xtext https://eclipse.org/Xtext/ (which is extreme, because it
generates a *DK for
each language)
Allow me to comment on this :-)
Xtext doesn¹t generate an SDK or similar but it generates a parser and an
AST.
Having a common notion of what ASTs look like is key to let languages
integrate with each other and is also the basis
for many services that are offered by Xtext and which are important for
advanced language-specific tool support.
If you just want lexical coloring, and maybe run an external linter than
you don¹t need anything like that. But if you expect content assist,
incremental
builds and refactoring (even cross-language) than this is not going to
happen without something like that.
Note that IntellIj has its common notion of ASTs (called PSI) as well, so
in that regard it is similar to Xtext.
Sven
