Issue with KDevelop: Is it using different parsers in parallell for different puropuses?

[Jakob Petsovits]

On Monday, 14. August 2006 19:17, Andreas Pakulat wrote:
> On 14.08.06 17:00:15, Erik Sigra wrote:
> > On 14.08.06 13:30:19, Erik Sigra wrote:
> > > 1. We don't really like HTML mails here.
> >
> > Sorry, I am away from my computer/connection and have to use the this
> > crappy webmail, which defaults to HTML mail. Will try to do better.
>
> You have my sympathy. That thing also breaks any threading.

I think he broke threading himself by not deleting that "Erik Sigra wrote" 
header, or even replacing it with a proper "Andreas Pakulat wrote" one.

> > > 2. kate is an editor it's not part of kdevelop and the kdevelop
> > > developers have only partial influence on what the kate developers use
> > > for parsing files.
> >
> > Kate is part of KDevelop when I am using KDevelop
>
> No it's not. KDevelop using Kate as the only implementation of the
> KTextEditor interface doesn't make it a part of kdevelop, especially not
> in terms of development changes. Kate is it's own project.

There is a connection between KDevelop and Kate, and that's Hamish Rodda
who is hacking both. For KDevelop 4, there have been some extensions in the 
KTextEditor interface which allow to integrate KDevelop's own parsers to a 
certain level, including highlighting. Hamish is working on that for the C++ 
parser.

> > > 3. Kate probably doesn't need all the extra information ANTLR has
> >
> > I am not so sure about that. I have seen suboptimal
> > highlighting/folding/indenting/linewrapping because Kate's primitive
> > parsers do not understand the languages well enough.

I don't think that's because of the lack of language understanding.
It's rather a suboptimal indenting algorithm, and believe it or not, it is 
being worked on in Kate for KDE 4 :)

> > I estimate that using an ANTLR-generated parser for highlighting will be
> > faster than using a parser, with the same level of code understanding,
> > defined in XML.

That's not up to me to judge, because I don't really know Kate's XML parsers, 
but
1. ey, the parsers don't have to be used as XML, it's just a description on 
disk and converted to something more efficient when Kate is running.
2. Simplicity in most cases more important for performance than code 
optimizations.
3. I think you're overestimating the performance losses. Kate's parsers are so 
fast that almost everything else has a bigger impact than its parsers.

> > > Much faster than parsing to build a tree of classes/methods, code
> > > completion or anything else.
> >
> > I think code completion also has to be fast, because it is supposed to
> > work as you type, just like highlighting.

Code completion doesn't need to be just as fast as Kate's editor parsers need 
to be. If you wait half a second for your code completion popup you'll hardly 
notice the delay, but if the editor is lagging behind while you're typing, it 
gets extremely annoying. Kate has to do highlighting and indentation on every 
typed character, whereas it's no problem for the code completion thingie to 
skip a word or two, it's mostly not important anyways.

And yes, "real" language parsers come with a great deal of more complexity in 
terms of coding effort, memory consumption and understanding.

> > > 4. Kate supports much more languages than kdevelop does (for parsing
> > > matter)
> >
> > Good. Just keep using Kates XML-defined parsers for the languages that do
> > not have ANTLR parsers.
>
> That's probably not going to happen, why should they provide another
> parser when they don't want to replace all.

I don't see any reason for Kate to change their ways. The only thing they 
could provide was an interface for apps like KDevelop, and that one is coming 
up for KDE 4.

> > > the support for new languages doesn't always come from the
> > > developers themselves. Thus the people writing parsers for kate do not
> > > necessarily know antlr or what a language grammar is.
> >
> > I would rather not use a parser written by someone who does not even know
> > what a language grammar is. I am afraid it would just be too shoddy.

You can trust the Open Source ecosystem that the important parts are being 
taken care of by people with good skills, and that the mediocre parsers would 
not be there at all because they're not important enough for the core 
developers to take on, because they're quite busy already. Besides, 
everything is buggy, and can also be fixed, that's what Bugzilla is here for.

> > > If you think kate should use an antlr parser please write to
> > > kwrite-devel and start the discussion there.
> >
> > I was not thingking along those lines. For the time being I just wanted
> > to know if the more advanced parsers that KDevelop already has could take
> > over some tasks that the Katepart does, and do them better.

As I said above, it will be possible for KDE 4, and it's worked on for C++ at 
the moment. I believe it's not for performance reasons though, but rather for 
correctness also in corner cases. Hamish?

Don't take it more seriously than it is,
  Jakob