GNU bug report logs -
#79200
31.0.50; Duplicated elements for '#<marker at' in buffer-undo-list
Previous Next
Full log
View this message in rfc822 format
Óscar Fuentes <oscarfv <at> eclipso.eu> writes:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
> Hi Gerd.
>
>>> The above produces an undo list with length 80000.
>>>
>>> I think it might make sense to limit that to some reasonable number.
>>
>> @Oscar: the patch below adds such a variable. My gut feeling is that
>> might well resolve the whole problem, without the other stuff, i.e.
>> applied directly to feature/igc. Sorry for the back and forth.
>
> Is this really addresset at me?
Yes please, that would be very nice, because you seem to do something in
the real world that produces the problem with markers+igc, while I
apparently don't encounter that normally.
> Do you want me to try your patch? This patch alone or on top of the
> previous ones?
On top of the original feature/igc with no other changes. The maximum
depth of undo is then 200, which is an arbitrary number.
> Your discussion with Alan is way beyond my knowledge, but if the patch
> just keeps the list under a certain length, as it seems, I don't see how
> it can be a fix, as AFAIK the problem consists on the size of the new
> undo info increasing as a function of the size of the previous one, so
> at some point recording a new undo just overflows the capacity.
Let me try to explain what I'm seeing, conjecturing, have learned etc.:
The whole problem occurs because we have lots and lots of
marker-adjustment records in undo lists. The old GC gets rid of them by
cleaning them up during GC, That's compact_undo_list. IGC can't do that
in the same way because it's completely different, so the marker entries
basically pile up and up and up.
Secondly, we have undo-limit and undo-strong-limit which is fine, but we
don't have something that limits the number of possible undos
themselves. As long as the size limits aren't reaches, undo lists
happily grow into the thousands of undo-boundaries, i.e. individually
undoable operations. So much that I think it makes no sense any more. No
one would do 1000 undos. That's why I think limiting that to some number
makes sense. I'm using 100 in my Emacs ATM. That is the change in
truncate_undo_list.
Thirdly, by discarding undo entries after the nth undo-boundary, we of
course reduce the marker-adjustment entries which are part of text
entries of the discarded list elements. This should reduce the whole
problem to something that's fine, at least my gut feeling is that it
does.
And fourth, igc already calls compact_buffer, which calls
truncate_undo_list in igc_on_Idle. That's why this should work in the
end.
And fifth, if that is "good enough" in the real world it is of course
much less complex and whatnot than everything else.
Something like that. Hope it's more or less understandable.
This bug report was last modified 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.