C++ parser

[Hamish Rodda]

Hi Robe,

On Wed, 1 Jun 2005 03:55 am, Roberto Raggi wrote:
> Hi!
>
> I've started to play with the _new_ C++ parser. Please, take a look at
> http://websvn.kde.org/branches/work/kdevelop4-parser/include/?rev=420247&vi
>ew=log
>
> The code is in the /branches/work/kdevelop4-parser. btw I want to change
> a couple of things in the AST(the AST for the expression is pretty broken
> :-) and I want to add a multi-pass parsing mode to parser.cpp. So expect a
> lot of changes in the API.

Nice :)  You're planning on implementing incremental parsing / parsing only of 
changed text, correct?  The internals in Kate are certainly ready to handle 
providing this information.  It will be easy to associate ASTs with ranges in 
the text, and then when the text changes, the most specific changed region 
(smallest which encapsulates all of the changes) could inform either the AST 
or the parser of the change, eg. via a signal.  The parser can then attempt 
to quickly determine what change has occurred, and the vast majority of the 
time, it should be a simple matter for the parser to account for this in 
realtime (or near-realtime if we decide to use threads).  It might require 
the use of an equivalent LocationTable class which uses smart cursors to stay 
up to date... I'm not too familiar with the code yet.

It would even be possible to provide this sort of tracking for non-kate text 
editors within a new ktexteditor interface, if they implemented a few simple 
signals (such as which region of text was changed).  If that could be 
accomplished, then most editors would be able to use this without major work.

Would it make sense to do parsing in the background, ie. for cases where a 
small change triggers a large amount parsing?  Do you think making the kate 
text buffer reentrant would make sense?  I'm just wary of avoiding occasional 
interference to the ui if we decide to switch to realtime parsing.

I guess the idea of multi-pass parsing is to shorten the time the parser holds 
things up, at the expense of increased latency of AST data?  Or is it for 
accuracy / speed of parsing?

I can't wait to see kdevelop4 with (and I'm imagining :) in-place code 
refactoring, code logic navigation, much improved highlighting, etc etc...

Hope what I've written makes sense :)

Cheers,
Hamish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20050601/8b4f8a82/attachment.sig>