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

On Wednesday 16 August 2006 01:09, 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?)

As has been discussed, it is not within the scope of
katepart to provide 
advanced highlighting such as this.  You simply need to know
all of that 
stuff about your build system etc. in order to perform the
parsing.  Kate app 
could decide to use our parser, and if they decided to do
that we could make 
it a shared library.  However I'd consider this unlikely,
whenever it is 
raised on kwrite-devel to introduce a parser, the response
is usually (and I 
believe correctly) 'use kdevelop'.

> Also, what happens to files other than C/C++/Java? How
will these be
> highlighted? Can I tell KDevelop to highlight any
arbitrary file as e.g. C?

By katepart as previously.

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

As you guessed later on, kdevelop will be able to highlight
custom types as 
you like them, so an equivalent functionality is being
provided.

> Failing all that, will there be an option to let KATE
do the
> highlighting for C/C++/Java anyway?

Sure.  In fact, I'm thinking about using the current
katepart highlighting, 
and just overlaying the kdevelop highlighting on top. 
That's how it works 
currently, and it would be a fair bit more work for me to
fully replace 
katepart's highlighting.  I don't think there is a
performance issue either 
then, and in the case of parsing failure, not all
highlighting will be lost.

> I like the idea of better highlighting... but not if it
breaks
> consistency between KDevelop and KWrite, or is less
flexible.

If I design it as above (which I'm leaning towards now),
then kdevelop will 
only add to the experience 

Cheers,
Hamish.
_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

Hamish Rodda wrote:
> On Wednesday 16 August 2006 01:09, mwoehlke wrote:
>> 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?)
> 
> As you guessed later on, kdevelop will be able to
highlight custom types as 
> you like them, so an equivalent functionality is being
provided.

Sounds great! Just to forewarn you, I will probably want to
be able to 
create multiple sets of lists, so I can pick different
colors for them, 
but that's obviously RFE material (of the kind I might
tinker with 
myself). I'm just warning you in case it's really easy to
"do right the 
first time".

As an example (using Windoze; sorry ), I might
want TRUE, FALSE and 
NULL to be keywords (I think these are #define's), but
other macros to 
be 'normal text'. I might want __int64, etc, to show up as
regular data 
types, DWORD, PVOID, etc to be a different color, and size_t
to be yet a 
third color. I think all of *these* are typedefs. Anyway,
that's a 
sample of how I am probably going to want to split
project-defined 
keywords into different highlighting groups. I think this
would be a 
great feature, especially for separating library keywords
(types, etc) 
from application-defined keywords.

But, like I say, just a thought... feel free to not
implement it (with 
the warning that I'll probably request it later ).

>> Failing all that, will there be an option to let
KATE do the
>> highlighting for C/C++/Java anyway?
> 
> Sure.  In fact, I'm thinking about using the current
katepart highlighting, 
> and just overlaying the kdevelop highlighting on top. 
That's how it works 
> currently, and it would be a fair bit more work for me
to fully replace 
> katepart's highlighting.  I don't think there is a
performance issue either 
> then, and in the case of parsing failure, not all
highlighting will be lost.

Sigh. Why didn't someone SAY so in the first place! 

I like that idea about 1000% better than total replacement,
which was 
the feeling I was getting. Now it sounds like we're still
getting KATE's 
highlighting plus a few project-dependent extras, in which
case it is 
infinitely more reasonable for these to only be available in
KDevelop. 
(Now... does this means I could also *still* use a custom
.xml, and get 
the KDevelop features on top of that? )

Thanks for the clarifications, Hamish!

>> I like the idea of better highlighting... but not
if it breaks
>> consistency between KDevelop and KWrite, or is less
flexible.
> 
> If I design it as above (which I'm leaning towards
now), then kdevelop will 
> only add to the experience 

Sounds wonderful! 

-- 
Matthew
vIMprove your life! Now on version 7!


_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

On Wednesday 16 August 2006 05:57, Hamish Rodda wrote:
> As has been discussed, it is not within the scope of
katepart to provide
> advanced highlighting such as this.  You simply need to
know all of that
> stuff about your build system etc. in order to perform
the parsing.  Kate
> app could decide to use our parser, and if they decided
to do that we could
> make it a shared library.  However I'd consider this
unlikely, whenever it
> is raised on kwrite-devel to introduce a parser, the
response is usually
> (and I believe correctly) 'use kdevelop'.
Yes ;=) I think the current way is the right one to go. You
have enriched 
KatePart/KTextEditor with methods to allow external apps
like KDevelop to 
customize the highlighting of the document.

The KatePart internal "parser" should really
stay the stackmachine it is atm, 
it may get some more tuning for KDE 4, but since KDE 3.4/5
it is 
alreadystackmachine  really fast, compared to older
incarnations. It gives 
enough power to the user to write hl's even for stuff like
perl, which is 
complex, but still provides a xml-syntax format which is
much easier to write 
than other known parser generator inputs like yacc.

For indentation: yes, first of all, we suck ;) I know this,
Kate team works on 
this ;) The problem atm is, that unlike the highlighting,
which are external 
xml file where we get many many many contributions by users,
which is really 
great ;), the indenters are atm hardcoded in C++ in
katepart, which makes the 
barrier to write own ones much too high. First we though
about making C++ 
plugins for this, but again, this would be dead-hard for
users, to setup a 
development environment for KDE stuff just to write
indenters. In KDE 4 we 
will support indentation javascripts. Therefor we already
integrage kjs. It 
will be as easy to write indenters as highlighting, just
fill some stubs in 
a  .js file, move it to the right place and Kate will be
able to use it. This 
is still in it's early stages, atm only one indentation
script is in work, 
for C/C++, by Dominik. We are fighting with some speed
problems, as kjs is 
not that blazing fast, and yes, you notice that even for the
small scripts 
needed for indenation. Therefor we will provide a rich js
API for 
document/view to allow to outsource many loops/calculations
to the C++ core 
of the katepart (which will mean additional work, as more
interface functions 
to come up with...) This indenters may use internal
knowledge of the hl, too, 
but this is not there atm I guess...

cu
Christoph

_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel

Christoph Cullmann wrote:
> On Wednesday 16 August 2006 05:57, Hamish Rodda wrote:
>> As has been discussed, it is not within the scope
of katepart to provide
>> advanced highlighting such as this.  You simply
need to know all of that
>> stuff about your build system etc. in order to
perform the parsing.  Kate
>> app could decide to use our parser, and if they
decided to do that we could
>> make it a shared library.  However I'd consider
this unlikely, whenever it
>> is raised on kwrite-devel to introduce a parser,
the response is usually
>> (and I believe correctly) 'use kdevelop'.
> Yes ;=) I think the current way is the right one to go.
You have enriched 
> KatePart/KTextEditor with methods to allow external
apps like KDevelop to 
> customize the highlighting of the document.

Right. Emphasis on "customize", as in,
"not 'replace'". 

> The KatePart internal "parser" should
really stay the stackmachine it is atm, 
> it may get some more tuning for KDE 4,

Since we're on the subject, is "ability to pop at the
same time as push" 
part of that "tuning"? (I know, wrong list, but
I think I already asked 
there with no reply.)

> For indentation: yes, first of all, we suck ;) I know
this, Kate team works on 
> this ;)
> [snip]

...and indentation is something else I'd not like to see in
KDevelop but 
not KATE, but it sounds like that won't be a problem. 

-- 
Matthew
vIMprove your life! Now on version 7!


_______________________________________________
KDevelop-devel mailing list
KDevelop-develbarney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/
kdevelop-devel