[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ease-dev] GSoC code competion commits
|
HI Martin,
extending the language scheme is the right way to go. Waiting for your
commit containing those changes.
While reviewing code from Vidura today I saw that he exchanged the
completion provider instantiated from the shell view:
https://git.eclipse.org/r/#/c/53069/
Are you both aligned on this topic?
further please move all code completion relevant classes to a subpackage
'codecompletion' so we can see more easily where those classes belong to.
best regards
Christian
On 03.08.2015 12:34, Martin Kloesch wrote:
Hi,
I understand that GSOC is JavaScript only but to write code that will
need to be changed immediately once another scripting language wants
autcompletion may not be the best option.
The syntax parsers will not be completely different in other languages
but e.g. Python does not have the "new" keyword for constructors. I
know it is only a minor thing but I guess having a simple interface
with a base implementation would be the most clean solution to avoid
future problems. All ICompletionAnalyzers can inherit from the base
class and will only need to define the language specific syntax
analysis they need. I already implemented the interface and the base
class and it looks good so far with the implementations for JavaScript
and Python.
I extended the schema for the "language" extension point with a new
element completionAnalyzer and query for it basically the same way as
for ModuleWrappers. Since the schema is not used to perform any
runtime-checks this will not break other script engines and offer a
clean solution to query for it.
One thing I noticed is that the latest upstream changes seem somewhat
wrong. You added the ContentProposalAdapter class to the
org.eclipse.ui.view package without changing the package declaration
in the file. If i change the package declaration to the view package
the class will not match given interfaces so it would be necessary to
move it to the declared org.eclipse.jface.fieldassist package. Did
that slip through or am I missing something here? If it's just a
problem for me then it's okay, otherwise I will also post it in a new
thread to make others aware of this...
Best regards,
Martin
Am 2015-08-03 um 00:32 schrieb Christian Pontesegger:
Hi Martin,
Having a new interface for ICompletionAnalyzer would be a better
option. The scripting service is actually a singleton, hidden behind
an eclipse service. So it is a single point we need to change here.
Yet I am not sure, why you would need different analyzers for
different languages. First your GSoC target is javascript only, but I
am glad that you already think about other languages. still I guess
the relevant syntax to be parsed does not look different for eg.
python. Still if you need that interface, make a new one and do not
merge it with the ModuleWrapper.
_______________________________________________
ease-dev mailing list
ease-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ease-dev
