Re: [CEDET-devel] semantic-grammar & semantic-edit patch proposal

[David P. <da...@dp...>]

Hi Eric,

 >   It looks as though you have been busy. ;)  Comments below.

Fortunately there are week-ends and nights ;-)

[...]
 > This last change you mention is interesting.  It is similar to the
 > old `dirty-token' mechanism semantic used to use.  I had switched to
 > tracking individual changes for two reasons:
 >
 > 1) Make the change-function faster.  (Don't do lots of semantic token
 >    stuff)

The overhead of my change is negligible.  It only query for a parent
token when the change overlay is created.  While you do changes in
the scope of that parent token `semantic-edits-new-change-hooks' is
not called again.

 > 2) Handle changes between tokens.
 >
 > A side effect of your change is that if `semantic-highlight-edits-mode'
 > were on, it would have an interesting visual effect. ;)

I like it because it clearly shows the actual scope of changes!

 > What I like about your change, however, is that it puts the knowledge
 > of the token bounds issue into the .wy or .by mode, AND it is a
 > functional knowledge, not a state setup.

It was my goal ;-)

 > Perhaps when semantic-edit
 > requests bounds of a token (currently via semantic-token-start/end) it
 > could instead use an override function
 > `semantic-token-reparse-start/end'.  Modes would then override this to
 > help the incremental parser make intelligent decisions.  I think we
 > had talked about the relative merits of a reparse parent type state
 > added to all tokens who cared and were not convinced.  I think using
 > override functions would be spiffy since the question asked by
 > semantic-edit is exactly what it wants, and the flexibility is there
 > for any strange state a mode may need.
 >
 > Do you like that idea?

[As the incremental parser actually ask for change bounds, I would
prefer to name these functions `semantic-edits-change-start/end'.  I
personally wouldn't like a token-start/end function that don't return
the actual bounds of a token ;-)]

I don't see any fundamental difference between the two approaches.  In
both cases the mode gives to the incremental parser the correct change
bounds to take into account.

I prefer my solution which take advantage of the various nice hooks
the incremental parser provide to handle changes.  IMO, it is the
natural way to handle buffer changes.  A big advantage is that only
the modes who need to handle "strange" states will pay for that.  The
incremental parser continues to receive the list of changes to handle
and knows nothing on how they have been produced.

On the contrary the override function approach adds part of this
knowledge to the incremental parser.  The main consequence is that all
buffers are affected, even if they don't need to handle special cases.
A side effect is that the functions `semantic-token-reparse-start/end'
would no more be inlined and that could slow down the incremental
parser.

Thanks!
David

P.S.: What about the other changes in semantic-edit?