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

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

Kate already has it. It's implemented and I don't see it
being reworked any 
time soon, unless a volunteer steps up to the plate. Calling
it a parsing 
engine is buzzowordiness to me. It's a simple state machine
coupled to a 
pattern matcher. Simplicity is the key word here.

It works pretty well considered how simple it is. It *is*
langauge aware. Have 
you seen how many languages Kate's highlighter supports?
All of those 
highlight fine in KDevelop as well. I have projects where
the test harness 
has quite a bit of Octave and Common Lisp code in them, and
Kdevelop (via 
KatePart (?)) hightlights those sources just fine. Have you
actually tried 
what you're talking about?

The only thing, I gather, that KDevelop may potentially do
is override the 
highlighting for files it knows how to highlight better than
what Kate does. 
That more powerful highlighting functionality could be
potentially put into a 
separate framework and made useable by Kate (and other
applications), but 
again -- someone has to design it and code it first. I
suggest you give it a 
try if you place such a high value on that feature (as you
claim).

Cheers, Kuba

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Kuba Ober wrote:
>>> 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.
> 
> Kate already has it. It's implemented and I don't see
it being reworked any 
> time soon, unless a volunteer steps up to the plate.
Calling it a parsing 
> engine is buzzowordiness to me. It's a simple state
machine coupled to a 
> pattern matcher. Simplicity is the key word here.
>
> It works pretty well considered how simple it is. It
*is* langauge aware.
> [snip]

"Grammar" aware; KATE doesn't know about
grammars. The point would be to 
have MUCH better error detection, primarily, but I think it
would be 
useful in other ways as well. But as you say, SHTDI and it
isn't likely 
to happen any time soon. However, since it no longer sounds
like 
KDevelop is implementing a full-fledged grammar-based
highlighter 
(instead they are doing something that works /with/ KATE,
not /instead/ 
of KATE), there is no urgency.

> Have you actually tried what you're talking about?

I know it works *now*... it was sounding like it was going
to *stop* 
working, which is what I was worried about. 

> The only thing, I gather, that KDevelop may potentially
do is override the 
> highlighting for files it knows how to highlight better
than what Kate does. 
> That more powerful highlighting functionality could be
potentially put into a 
> separate framework and made useable by Kate (and other
applications), but 
> again -- someone has to design it and code it first. I
suggest you give it a 
> try if you place such a high value on that feature (as
you claim).

If you read the further posts, it sounds like this is NOT
what KDevelop 
is doing. And what I place high value on is not reinventing
the wheel 
somewhere that it can only benefit a subset of users. But
this is not 
what is happening. Please go back and read the rest of the
thread.

-- 
Matthew
'$ time make world' -> real 5d:14h:37m:5.291s  user
0m:0.000s  sys 
4d:2h:14m:43.712s


_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Kuba Ober wrote:
>>> 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.
> 
> Kate already has it. It's implemented and I don't see
it being reworked any 
> time soon, unless a volunteer steps up to the plate.
Calling it a parsing 
> engine is buzzowordiness to me. It's a simple state
machine coupled to a 
> pattern matcher. Simplicity is the key word here.
>
> It works pretty well considered how simple it is. It
*is* langauge aware.
> [snip]

"Grammar" aware; KATE doesn't know about
grammars. The point would be to 
have MUCH better error detection, primarily, but I think it
would be 
useful in other ways as well. But as you say, SHTDI and it
isn't likely 
to happen any time soon. However, since it no longer sounds
like 
KDevelop is implementing a full-fledged grammar-based
highlighter 
(instead they are doing something that works /with/ KATE,
not /instead/ 
of KATE), there is no urgency.

> Have you actually tried what you're talking about?

I know it works *now*... it was sounding like it was going
to *stop* 
working, which is what I was worried about. 

> The only thing, I gather, that KDevelop may potentially
do is override the 
> highlighting for files it knows how to highlight better
than what Kate does. 
> That more powerful highlighting functionality could be
potentially put into a 
> separate framework and made useable by Kate (and other
applications), but 
> again -- someone has to design it and code it first. I
suggest you give it a 
> try if you place such a high value on that feature (as
you claim).

If you read the further posts, it sounds like this is NOT
what KDevelop 
is doing. And what I place high value on is not reinventing
the wheel 
somewhere that it can only benefit a subset of users. But
this is not 
what is happening. Please go back and read the rest of the
thread.

-- 
Matthew
'$ time make world' -> real 5d:14h:37m:5.291s  user
0m:0.000s  sys 
4d:2h:14m:43.712s


_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel