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

[Adam Treat]

On Tuesday 15 August 2006 1:29 pm, mwoehlke wrote:
> Adam Treat wrote:
> > On Tuesday 15 August 2006 12:09 pm, mwoehlke wrote:
> >> Adam Treat wrote:
> >>> On Tuesday 15 August 2006 11:09 am, mwoehlke wrote:
> >>>> Hamish Rodda wrote:
> >>>>> On Tuesday 15 August 2006 03:59, Jakob Petsovits wrote:
> >>>>>> 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.
> >>>>>
> >>>>> Exactly.  What Erik wants (or almost, seeing as we don't use ANTLR
> >>>>> but kdevelop-pg for kdevelop4) will be present in kdevelop4.  For
> >>>>> c++/c#/java (and possibly others) we will be doing the highlighting
> >>>>> solely in kdevelop.
> >>>>
> >>>> Hmm, so what is going to happen to KATE? As I pointed out, one of the
> >>>> advantages to the current system is consistency both inside and
> >>>> outside of KDevelop. Loosing that will be most unfortunate, or do you
> >>>> plan on porting this stuff out to KATE? (Or more accurately, will
> >>>> their be a text editor part with these features plus everything KATE
> >>>> does, that can be used in KWrite?)
> >>>
> >>> Nothing will happen to Kate.  Kate will remain as is, doing it's own
> >>> highlighting how it currently does it.  KDevelop will have enhanced
> >>> highlighting for the languages that it supports.  That is all.
> >>>
> >>> It is ludicrous to say this shouldn't be allowed because it
> >>> breaks 'consistency'.  IDE users want more involved highlighting.  Of
> >>> course, I suppose we could provide an option in KDevelop 4 allowing you
> >>> to turn off this feature.
> >>
> >> But it will. :-)
> >>
> >> What I'm saying is not that we shouldn't do it, but that KWrite should
> >> see the benefit too. KDevelop is too heavy-weight for one-source
> >> applications (i.e. most test programs). The fact is I do not - now, nor
> >> am I likely to in the future - use KDevelop exclusively for ALL coding.
> >> There are and will continue to be times that KWrite is much more
> >> efficient.
> >
> > Ok, so you are talking about putting the heavy-weight kdevelop-pg parsers
> > into Kate, thus making KWrite to heavy for your 'once-source
> > application/test program' needs.  How does that help you again?
>
> Not necessarily into KATE (I apologize for not making that distinction
> earlier), but at least accessible in a Part that could be used in
> KWrite. And you still don't have the user-side overhead of the KDevelop
> UI, which is the interface, project-scheme, etc. We're talking about
> something that is just a text editor. Yes, it is a very *sophisticated*
> text editor. Yes it is heavy for "just a text editor". But it wouldn't
> carry the additional overhead of a project-centric architecture, which
> is what makes the usability "weight" difference between KDevelop and
> KWrite. Creating a project, Makefile, etc, for every one-off 100-line
> program I have to write to test some feature or bug is ridiculous.
>
> Does that make sense?

KDevelop 4 won't have a new editor.  It is using the KTextEditor interfaces.  
Those interfaces allow KDevelop 4 to choose to do its own highlighting.  The 
only way this could be re-used for KWrite is for the default KTextEditor 
implementation -- katepart -- to use kdevelop-pg parsers for its 
highlighting.  Who knows, perhaps the Kate devels will eventually do this, 
but the place to talk about that is on kwrite-devel as you yourself noted.

> >> I'm also trying to point out that you're violating the fundamental
> >> tenant of UNIX; make small, reusable tools. You're talking about making
> >
> > See all of KDE.
>
> "All"? KParts and KIOSlaves are exactly the way this is *supposed* to
> work. :-) Ideally I would like to see this newfangled editor be a Part
> that can be used in KWrite (or anything else that allows choosing a text
> editor part). Oh, and this would have the added benefit that you get the
> 'turn it off' option "for free"; just pick KATE as your editor.

There is no newfangled editor.  We are using katepart through the KTextEditor 
interfaces, just as we do for KDevelop 3.x.

We are just modifying the part using those very same KTextEditor interfaces 
and a more advanced parser to produce the enhanced highlighting.  I hope this 
clears this up.

> >>>> Will I be able to add new highlighting rules to KDevelop's C
> >>>> highlighting? Right now I have a custom .xml that 'IncludeRule ##C's
> >>>> and adds a bunch of project-specific keywords with their own
> >>>> highlighting style. Will I be able to do this in KDevelop4 without
> >>>> having to recompile? (Recompiling would absolutely unacceptable; what
> >>>> if I have multiple projects I want to do this for?)
> >>>
> >>> I'll let Hamish answer this, but my instinct says this is more trouble
> >>> than it is worth.  If you really need this, then you can just use
> >>> Kate's highlighting.
> >>
> >> IOW KDevelop will be "better" but less flexible? For as many problems as
> >> I have with KATE's highlighting (that is, almost none), that sounds like
> >> a poor trade-off. I think I'll be watching for that 'just use KATE'
> >> option... or writing the patch myself.
> >
> > Yes, KDevelop will probably have enhanced, but less flexible
> > highlighting. Sorry if you don't like the trade-off, but many people are
> > looking forward to this.
>
> As I said, it sounds like something that has a lot of benefits that do
> not *yet* outweigh the drawbacks. Or maybe this newfangled highlighter
> *does* highlight user-defined types that are defined in the project?
> That would be even better, since it would do what I am doing right now,
> *without* needing custom .xml's per-project. Of course, there should be
> a way to specify what highlighting group a particular entity falls into,
> so that groups can be broken up.

This is up to Hamish as he is the one who is doing the work.

> > I love all the complaints for something that isn't even released yet.
> >
> > *sigh*
>
> I know, but isn't this the best time to make them? Before things are
> committed to going a certain way, and while the direction can be more
> easily changed?

Feedback is great, but saying something is 'unacceptable' for something you 
haven't tried and is not finished and someone is working on heavily is not so 
helpful.

Adam