Experimental change bar feature
Neil Hodgson
http://scintilla.sourceforge.net/scitecb.zip
It provides change bar functionality similar to other editors. It
is modeled most closely on Visual Studio including limitations. The
implementation uses a significant amount of memory - up to 16 bytes
per line changed per undo step. That is all the lines changed before
that undo step, not just the lines changed in that undo step. And its
each individual step even when a group of steps is undone as a single
command. The feature can only be turned on when undo is turned on -
coping with undoing beyond the beginning of the change bar history was
too complex. The current code turns it on SCI_EMPTYUNDOBUFFER but that
will have a collectChangeHistory parameter in the future. The change
bar can be shown using any marker in a margin but the new
SC_MARK_LEFTRECT gives a similar appearance to Visual Studio. These
markers should be set for SC_MARKNUM_CHANGEUNSAVED and
SC_MARKNUM_CHANGESAVED (23 and 24) which are similar to the
SC_MARKNUM_FOLDER* in that they will be used for the change bar if the
change bar history is turned on but are otherwise available for
application markers.
An earlier version stored just an original/changed/saved state for
each line but this was unable to handle undo/redo like Visual Studio.
Now an undo step number is saved for each line so if a 4 line file is
loaded and line 2 then line 0 are changed, the current state looks
like [2, 0, 1, 0]. Since history is stored so that this can be
restored when undo is performed the history contains [[0,0,0,0],
[0,0,1,0]]. Each step's state is run-length encoded which reduces
storage a bit (it was a much better strategy when the enumeration was
used). It would be better to reduce storage further by only storing
the changes from the previous step: often this is just [update line 3
to step 5] or [insert line 16 as step 24] but for multi-line deletions
it has to keep a list of previous values.
After spending all that memory, you'd hope for some accuracy but
there are still limitations. My understanding of the change bar
concept was that when the bar is clear, no changes have been performed
to the line; yellow means that it has been changed but not saved;
green means it has been changed but has been saved so is the same as
on-disk. Green actually (both in VS and this implementation) means the
line was saved at some stage and has either not been changed after
that save or we have undone to before the save point but not to the
line's original state. The save point in this context is actually the
effective save point: if you undo to before the save point and then
perform a modification, the redo history after that point is no longer
accessible (as its context has been destroyed) so that save point is
now unreachable. For the purposes of the change history, the effective
save point is the last surviving step from the original history that
led to the save point.
I have been unable to find a reasonable data structure to include
sufficient information to determine when the line is the same as
on-disk. Compressing the change bar history further looks doable but
its tedious and looks error-prone so I may not work on it. The hefty
memory use should only be a problem for large files or where many
lines are modified and there are many actions performed. Since this
means there may be failures under intensive use, it is unlikely I'll
add a setting to enable this in a SciTE release.
Neil
Iago Rubio
> An experimental version of Scintilla/SciTE source can be downloaded
> from http://scintilla.sourceforge.net/scitecb.zip
I've been testing it so far, and looks quite accurate for me.
I don't see a problem with minor failures as it's simply a visual
helper to track what you've been editing lately. If it just points to
the editing "zone" - say a couple of lines up and another couple down
- It will be accurate enough for me.
Even a single marker instead of the saved-unsaved pair, would be
great.
Is this feature going to do it into the main scintilla ?
Neil Hodgson
> Is this feature going to do it into the main scintilla ?
Probably not while it may use so much memory. I think there will be
too many bug reports with the current implementation. It should be
possible to reduce memory use to a reasonable level but it requires
some effort and will make the code more complex so its unlikely I'll
work on it soon. Much of the implementation is reasonable for anyone
that wants to continue work or merge it into their own version of
Scintilla.
Neil