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

[mwoehlke]

Adam Treat wrote:
> On Tuesday 15 August 2006 1:29 pm, mwoehlke wrote:
>> Adam Treat wrote:
>>> 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.

True. Well... since obviously the decision is made, I guess I'll wait 
and see. I still think it would be good if KATE's highlighting was more 
language aware. It will be unfortunate if KATE winds up implementing a 
different language-aware parsing engine that competes with KDevelop's. 
That's a big part of what I'm worried about. But... maybe a: kdevelop-pg 
can be used as-is (or "in its finished form", anyway), b: it will 
evolve into something more generalized that will work for KATE, or c: it 
will spin off something as a subcomponent that will work for both 
KDevelop and KATE.

Right now, KATE + KDevelop are an awesome combination. I don't want to 
see that broken up, ok? :-)

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

Then I apologize for my wording. What I am trying to say is "I am used 
to feature X. If Y does not provide X, then I will not use Y, because I 
value X over the other features that Y provides." I don't know how else 
to communicate that; I would *like* to use it, and therefore be able to 
contribute to its improvement, but if it doesn't fill my needs 
(Simplified IDEAl is in this category ATM), then I'm not going to use it.

Guess I'll go file bug reports on Simplified IDEAl.

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