MovingRanges: Should we expand on edits? Should we invalidate on empty?

[Milian Wolff]

On Saturday 13 November 2010 19:12:30 David Nolden wrote:
> 2010/11/13 Milian Wolff <mail at milianw.de>:
> > On Saturday 13 November 2010 16:18:24 David Nolden wrote:
> >> a) Contra, because the highlighting also shows the current state of
> >> the "code understanding", and the user might get a completely wrong
> >> impression of what's going on if the ranges are always extended. For
> >> example, you reference an existing variable "a", but you change it to
> >> "ab". Now until the next parse has finished, the highlighting would
> >> look like "ab" exists, even if there is no such declaration. Apart
> >> from that, "ab" might also get a completely different highlighting, in
> >> which case we would only add more UI flickering by intermediately
> >> extending the highlighting of "a" to "ab".
> > 
> > if you think so...
> 
> We had a temporary state, due to a bug in kate, where all
> highlighting-ranges used to expand. I remember that it was really
> annoying. Consider for example:
> You write "MyClass myMember;" Now you start extending it with
> constructor-arguments. You extend it to "MyClass myMember(arg1, arg2,
> arg3);", and the parser isn't fast enough to update. Then you will
> have the wole "myMember(arg1, arg2, arg3)" highlighted in bold like a
> declaration, which is really ugly. There were many similar annoyances.
> Consider for example pasting a large text next to something
> highlighted..

Very good point. I expected it to not grow the range on whitespace or special 
chars. So count me convinced.

> > I'm curious, what do you do with that information?
> > 
> > void foo() {
> >  int bar = 1;
> > }
> > 
> > select it all and remove it, both ranges with be empty and at the same
> > place. Why should you keep and transform them?
> 
> The ranges in the code-highlighter are stored sorted by
> start-position, and that sorting will be broken by invalidating
> ranges. It completely depends on the code that uses the ranges. If you
> think there's a really good reason to invalidate them, we could do it,
> after all it should be only the highlighter who is affected.

The highlighter would/should be using a MovingRangeFeedback and delete 
directly when a range gets invalid. There is no point in it staying around and 
getting transformed across revisions...

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20101113/3ba168d5/attachment.sig>