[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta-devel
Subject:    Re: [quanta-devel] Class autocompletion - a new era
From:       Eric Laffoon <sequitur () easystreet ! com>
Date:       2005-02-22 10:25:58
Message-ID: 200502220225.58196.sequitur () easystreet ! com
[Download RAW message or body]

On Monday 21 February 2005 11:06 pm, Andras Mantia wrote:
> On Tuesday 22 February 2005 00:29, Eric Laffoon wrote:
> > I tried this without reading the above with one of my files and
> > obviously it's a no go.
>
> What is the problem with it?

I have to write more XML than PHP to use it? ;-)
>
> > What is interesting is that this does
> > generate the autocompletion after $this-> in the class file. So what
> > we have here seems like a real good start that lacks the final step
> > to make it really useful. Originally I suggested the option that the
> > private DTEP could be generated/used as a possible solution and also
> > as it might be a benefit for caching in large projects. If it is
> > required for external use then we need a solution to make it
> > functional, one of the following...
>
> Don't you think that I tried that already? ;-) The problem is that in
> this case the parser needs to be modified so it can parse from
> non-KTextEditor strings and at least it must be made completely
> independent, so you can start several parsers without problem. Why this
> is needed? Because in order to generate project DTEPs you need a *full*
> parse of the included files as well. What we have now is a quick
> parsing which doesn't generate a node tree, just looks for the
> structure groups. So it has limited information about the document.
>
> > 1) auto generate on open of class files
> > 2) some scripting ability to create these
> >
> > Ideally any indication that the file has been updated would trigger a
> > reparse either from the file or if it happened in a repository
> > update, from the calling file. At the very least we should have some
> > way to request DTEP files be generated as opposed to having to create
> > them. The main reason I bring this up as before I write a script for
> > this it seems that the parser is generating these in the file. The
> > real question is how do we make this work for users in a practical
> > way that is not more work that it's worth to use it?
>
> What you say surely makes sense, just that it is too dangerous to
> implement now. As I said I tried it, but my changes to the parser
> messed up the behavior, and you know, we don't want a badly behaving
> parser just before the final release.
>
> Andras

No, let's whack the parser! :-O

Okay... this leaves an obvious question. What supplemental tools could we 
offer? The irony here is that I'm sure you could come up with something 
faster than I could write a supplemental parser from scratch using PHP which 
I'm most familiar with.

So everything aside, silly question... any idea how we might address this? 
Could we take the parser code after the release and try a small stand alone 
app from it and then re-integrate this functionality into the parser for 
another release? We did talk about adding this... The alternative is to 
evaluate the specific syntax for objects and create a mini parser for that 
which would not be too terrible to do as a script. The question is what 
compromise could we offer that is better than requiring a manual XML edit? 
Any?

Eric
_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel
[prev in list] [next in list] [prev in thread] [next in thread]