Re: [ease-dev] GSoC code competion commits

[Martin Kloesch <martin.kloesch@xxxxxxxxx>]

Hi,

I have all changes handily waiting to be committed (one or two at a time 
to avoid problems).

We haven't really aligned on this topic yet. I wrote today with a 
suggestion on how we could easily combine our work and if he also thinks 
this would be a good idea we can put our code together hopefully very soon.

I will try to push the commits regarding the actual interfaces and 
extension points first because it would be good if they were upstream 
before you go on vacation. Then we can independently work on code 
analysis / representation and only feed the already defined interfaces. 
To me this would be the best solution, not sure how you two see this.

As I said earlier I can already re-use some of the script shell 
completion providers for the JS editor. The mechanism works very fine 
and looks promising to be easily extendable with different 
ICompletionProviders. If Vidura is satisfied with the information he 
gets (basically a list of ICompletionSource) I think this would be the 
way to go.

Best regards,
Martin

Am 2015-08-04 um 21:10 schrieb Christian Pontesegger:
> 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
>
> _______________________________________________
> 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