Re: A ton of marker entry in buffer-und-list

[Stefan Monnier]

>>> Hmmm, I just tried again and alas, I get the markers even without
>>> winner-mode. For some reason disabling winner-mode solved it when I
>>> last tested it. How strange.
>> 
>> Ok.
>> 
>> Now I used this:
>> 
>> #+begin_src emacs-lisp
>> (defun count-markers-in-buffer-undo-list ()
>>  "Message number of (different) markers in `buffer-undo-list'."
>>  (interactive)
>>  (require 'cl-lib)
>>  (message "%d" (length
>>                 (cl-delete-duplicates
>>                  (seq-filter #'markerp (flatten-tree (copy-tree 
>> buffer-undo-list)))
>>                  :test #'eq))))
>> #+end_src
>> 
>> to get the number of different markers in `buffer-undo-list', after
>> reproducing the recipe.  The answer was always "1".  Just a bunch of
>> entries referring to one and the same marker.  That seems sane.
>> 
>> Are you able to provide a more pathological recipe?
>> 
>
> Using the same recipe, I got 18, the number of marker entries in each undo
> step. Also, even if the answer is 1, it is not ok because that shortens the
> number of undo a buffer can record by a factor of n (e.g., 18 in my case).

IIUC this is the `window-point` marker being moved each time.  We could
try and avoid this by not recording it for the `window-point` of the
current `selected-window` (since its point is temporarily kept
elsewhere, really), but I'm not sure it's worth the trouble.

It's not as bad as it looks: this factor 18 is simply because those 18
insertions were collapsed into a single undo entry by
`undo-auto-amalgamate`, so it only applies when the only thing you do is
`self-insert-command`.  In "real life" the impact should be
significantly lower than that.

Of course, another way to reduce the problem is to improve the
amalgamation code so it not only amalgamate the entries for the actual
insertion but also the associated 18 entries that move that one marker.


        Stefan