Re: undo refactoring

[phillip.lord@russet.org.uk (Phillip Lord)]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> IIUC, the reason for this was so as to avoid an inf-loop when malloc
> fails (for lack of memory).
>
> The particular issue was that it was OK for a command to fail because of
> malloc failure, but it was not OK for the read-eval-loop itself to fail
> before having the opportunity to run another command.

Found the documentation (near the variable rather than the method), and
yes, it's about memory allocation.


/* The first time a command records something for undo.
   it also allocates the undo-boundary object
   which will be added to the list at the end of the command.
   This ensures we can't run out of space while trying to make
   an undo-boundary.  */

That comment was from Richard, and hasn't changed since 1994; I guess
the chance of memory issues from a cons or two are less of a problem
now.

>
> My impression is that this design goal has been ignored for much too
> long, so I don't think Emacs behaves this way any more.  And instead we
> have now other ways to handle the memory-full situation (such as the
> extra memory that's pre-allocated and then released in case the memory
> is full).
>
> IOW, I'd be surprised if getting rid of this quirk would ever lead to
> a visible change in Emacs's behavior nowadays.

I've experimented with this and, at least, all the tests work. I'll try
it out in actual use, then if you are happy make the change on master.


Phil