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

[David Nolden]

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

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

Greetings, David