On Sun, May 2, 2010 at 01:30, Neil Hodgson <
nyama...@gmail.com> wrote:
> Jiří TechetÖ
>
>> I was wondering - wouldn't it be better to merge the changebar into
>> the mainline? There are already a few projects using it and I think
>> it's a bit unfortunate that each of them has to maintain their own
>> branch of scintilla just to have the changebar feature.
>
> If there is a variant that works well I'd like to consider it but I
> don't currently have time to look closely at implementations.
>
The codeblocks changebar implementation seems to work. I've already
ported it to geany without any major problems. But I think the
codeblocks people just took your implementation without improving
anything so there will be the same limitations as in the original
implementation. I will happily provide a patch on top of mainline if
you agree merging it - just let me know. I would make a few changes
though - e.g. remove SC_MARKNUM_CHANGEUNSAVED and
SC_MARKNUM_CHANGESAVED from SC_MASK_FOLDERS so the behaviour of
SC_MASK_FOLDERS remains unchanged. On the other hand I don't have much
time myself either so I won't spend time fixing the problems.
>> I know that
>> you are dissatisfied with the memory consumption and precision of the
>> current implementation (even though from my practical experience I
>> haven't seen any disastrous effects of it
>
> It was always seen as optional. It really is not good enough to use.
But in order to have an overview of what has been changed in a file
it's much better than good enough. Actually, even one-colour changebar
(that doesn't distinguish between saved/unsaved changes) would already
be a great help. Just wondering - would such a simplified changebar
suffer from high memory consumption too? (You don't describe how you
mark the save point so I don't know what's needed for it.)
Side note: I'm not sure I completely understand your description of
the changebar implementation (and I haven't studied the implementation
itself):
"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]]."
Why is it stored like this? I don't get it, but maybe I'm overlooking
something. Just intuitively what I would store for each line is the
number of undo's needed to return to the unmodified state. That is, in
your example the current state would be (written vertically - easier
for my brain to grasp):
1
0
2
0
With this encoding you don't need to keep the list of history states
because the history is stored implicitly - doing one undo step means
subtracting
1
1
1
1
from the non-zero fields. So the previous undo step would be
0 - gets unmodified, yellow disappears
0
1
0
and after subtracting once again you get
0
0
0 - yellow disappears
0
Of course with this implementation you would have to keep the redo
history, but memory-wise this is much better as redo steps are
discarded once the file is modified and people usually do only several
undo steps so there won't be so many redo steps stored (contrary to
the full file's undo history in your implementation). So if you
support say 2^16 undo steps, this implementation will consume
2*linenumber bytes.
Now it would be nice if it worked like that, but I don't expect you
haven't considered this possibility. So please tell me what I overlook
here :-).
Jiri