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

[Milian Wolff]

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

> b) Contra, because it would lead to strange bugs when code that
> expects a sorted list of ranges suddenly encounteres 'invalid' ranges.
> You discard information that might still be useful, namely the
> position where the range has been. It would need additional logic
> where we currently don't need any logic, thus I don't see an advantage
> in doing this.

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?

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/cadcb6ee/attachment.sig>