bug#23871: 25.1.50; Undo unexpectedly leads to blank buffer

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> One issue I noticed with the current undo system is that it behaves
>> differently if the command that inserts text is invoked via a keyboard
>> shortcut instead of via M-x ... RET.
>
> This is probably because of the
>
>     buffer_before_last_command_or_undo == current_buffer
>
> test, which is a naive/conservative test that just punts if there's
> a buffer switch (in which case point_before_last_command_or_undo is
> simply meaningless).  And in this case there is, since the last command
> was in another buffer (the last command was the RET you executed in the
> minibuffer).

It's going to be the buffer switch for sure, and yes, I'd guess it's
this part. Bit surprised this is a regression though. This check is
different from before, but the old system also used a global buffer
which should have been affected by the minibuffer changes.


> We could probably make it work by saving&restoring
> buffer_before_last_command_or_undo and
> point_before_last_command_or_undo around the minibuffer thingy.

Or just not set buffer_before_last_command_or_undo to the minibuffer.

> Or, making point_before_last_command_or_undo into a buffer-local
> variable and get rid of buffer_before_last_command_or_undo.

This seems the nicest to me. It should also cope with command completion
frameworks for like helm which use buffers as well as the minibuffer.

Phil