I am hopeful that you will be able to continue your streak and maybe
set something up for EclipseCon. I'm thinking that an EclipseCon
"extended hackathon" (maybe we need a better term) might be a good
opportunity to connect with those individuals who are interested in
extending and improving the Launch Bar, but maybe let's not hijack
this thread for that discussion.
Google Hangouts would be cool too!
Wayne
On 06/07/15 02:11 PM, Doug Schaefer
wrote:
I think it would be hard to fund travel for a meeting like
this (unless for me it’s in Ottawa ;). It would be nice to find
a way for those who are interested to work together, maybe over
Google Hangout or something similar, to come up with a plan.
Some of this, though, is differences in philosophy or maybe
just terminology. I would find it hard to differentiate a
“smart” editor from an IDE if the IDE is done right. Not sure
we’ve ever sat down and defined what an IDE was other than a
development environment that integrates the tools you use for
development, like build and debug and analysis tools, into a
seamless flow.
A “smart” editor is a good editor that integrates the tools
you use for development. Once you add support for debugging is
it really an editor anymore or has it morphed into an IDE.
Emacs, IMHO, is an IDE that way with build integration and error
markers.
Doug.
Are there any discrete
tasks that would benefit from having a group of us in the
same place we can extract from this discussion? i.e. are
there potential "Hackathon" topics [1] here?
What level of priority is this work in terms of potential
for funding by the EF? [2]
Wayne
[1]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=471463
[2]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=471462
On 06/07/15 12:45 PM, Michael
Scharf wrote:
On 2015-07-04 18:05, Max Rydahl Andersen
wrote:
On 1 Jul 2015, at 20:56,
Oberhuber, Martin wrote:
With tern claiming support for
Eclipse/Java , I'm wondering how much of a parser
JSDT even needs ?
Perhaps syntax highlighting would be sufficient,
with the rest offloaded to tern ?
http://ternjs.net/doc/manual.html#tern_java
You guys should come to our talks and discussions on
this ;)
You just described what we are trying to get to. Allow
us to use external tools (like tern etc.) since
the _javascript_ world moves way faster than we can
currently efficiently implement it in eclipse/java.
I really think this is an interesting eclipse
architectural issue. The
level at which the eclipse platform supports language
integration
great to build something like JDK. The building blocks
are very low
level and many projects started by copying JDK or some
similar project
The platform has no mechanisms to simply contribute any
kind of
external (or even internal) tools. Each *DK creates its
own editors,
views, index and extension points. They are not
interoperable.
There seem to be a few attempts to solve the problem,
like
- Xtext https://eclipse.org/Xtext/
(which is extreme, because it generates a *DK for
each language)
- DLTK https://www.eclipse.org/dltk/
or
http://www.ibm.com/developerworks/opensource/tutorials/os-eclipse-octave/
- LangEclipseIDE: https://github.com/bruno-medeiros/LangEclipseIDE/blob/master/README-LangEclipseIDE.md
- LiCLipse
http://www.liclipse.com/supported_languages.html
- AntLng
https://github.com/dschaefer/antlng
- ... (I am sure that there 5-10 more attempts to solve
the problem)
There is not clear winner. It is the beauty of the
bazaar.
The eclipse platform does not provide anything that
allows to easily
add external tools and language support the way the
popular editors
allow it (like Emacs, vim, Sublime, Atom, TextMate,
Notepad++)...
Erich Gamma and his team believe the pendulum is
swinging
from IDEs to (smart) editors:
https://channel9.msdn.com/Events/Build/2015/3-680
Therefore VS Code takes the approach to integrate with
external
tools. He also talks about progressive support for
languages, starting
form simple syntax highlighting...
The really interesting thing is, that Walter
Bischofberger
(he was on Erichs team in the early 90ies) wrote an
interesting
paper on a lightweight IDE architecture for a tool
called
sniff:
"Sniff—A Pragmatic Approach to a C++ Programming
Environment."
http://www.ubilab.org/publications/print_versions/pdf/sniff_usenix_92.pdf
This paper is 23 years old, but I think the ideas
described in the
paper are still very valid. I can see, how some of those
(old) ideas
enter into VS Code. I have been working on the
commercial version of
sniff for many years, and that my cause a bias in my
thinking into
direction of that kind of architecture. (sorry Doug for
repeating
myself for many years...)
I am not sure if a "council" can do anything about
architecture, but I
believe that all the knowledge to do something is within
the architecture
council. The question is how to execute to turn the
bazaar a little
bit more into a cathedral. A cathedral needs
architecture a bazaar only
needs a bit of coordination.
I hope eclipse is not one of the cathedrals that was
created by great
architects, but the architects are gone, and the walls
are still there
and although they provide nice places for the bazaar,
the cathedral
slowly falls apart...
Michael
/max
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development
Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
-----Original Message-----
From:
eclipse.org-architecture-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx]
On Behalf Of Michael Scharf
Sent: Wednesday, July 01, 2015 3:01 PM
To: Max Rydahl Andersen;
eclipse.org-architecture-council
Subject: Re: [eclipse.org-architecture-council]
_javascript_: a bug that makes me really sad....
Thus you at least don't get
these bogus warnings/error markers.
+1 excellent. Not having some warnings is way better
than
polluting the workspace with wrong error messages...
Does the parser work in that case correctly. I think
the change in _javascript_ that causes lots of
problems is that keywords can be used as keys of
objects and when there is a `.` before the word.
Classical lexer/parsers handle language keywords
special.
I guess the PR solves this problem....
Michael
On 2015-07-01 13:45, Max Rydahl Andersen wrote:
wtp-dev is where you should raise this.
We have a PR for SR1 that will go in an disable
this 1998 crappy validation.
Thus you at least don't get these bogus
warnings/error markers.
/max
I am excited about mars being out. But there is
a bug, that makes me
really really sad. The most popular eclipse
package is JavaEE and it
contains _javascript_. But eclipse supports only
_javascript_ 1998.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=223131
The most annoying problem is that modern
versions of _javascript_ allow
keywords if they are part of a data structure:
promise.catch(function(){...});
var foo {
default: 42
}
Many libraries use `throw` and `catch` as
methods on objects and this
causes a lot of errors and the rest of the file
cannot be parsed.
I know there are a lot of different _javascript_
solutions out there
that work better than this. But, the out of box
experience with
eclipse is, well suboptimal.
Is there anything the architecture council can
do about this?
Michael
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-cou
ncil
IMPORTANT: Membership in this list is generated
by processes internal to the Eclipse
Foundation. To be permanently removed from this
list, you must contact
emo@xxxxxxxxxxx
to request removal.
/max
http://about.me/maxandersen
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by
processes internal to the Eclipse Foundation. To be
permanently removed from this list, you must contact
emo@xxxxxxxxxxx
to request removal.
/max
http://about.me/maxandersen
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by
processes internal to the Eclipse Foundation. To be
permanently removed from this list, you must contact
emo@xxxxxxxxxxx to
request removal.
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
![EclipseCon France 2015]()
---------------------------------------------------------------------
This transmission (including any attachments) may contain
confidential information, privileged material (including material
protected by the solicitor-client or other applicable privileges),
or constitute non-public information. Any use of this information
by anyone other than the intended recipient is prohibited. If you
have received this transmission in error, please immediately reply
to the sender and delete this information from your system. Use,
dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
|
