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

[mwoehlke]

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?

>> 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.

>>>> 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.

> 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?

-- 
Matthew
Only Joe suffers from schizophrenia. The rest of us enjoy it.