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

[mwoehlke]

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

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 
something that I think should be generally accessible only available in 
KDevelop. Again, the point is not "don't do it", it's "share with the 
rest of us". :-)

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

Unfortunately, this is sounding like it will be another "Simplified 
IDEAl"; something worse than its predecessor in its initial form, that 
*might* be an improvement after a few major versions. Too bad that's how 
things seem to work. :-(

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