hippie-expand relies on the values of this-command and last-command in
order to determine what argument it should pass to try-expand
functions, in order to signal whether it's the "first" time they are
being called.
However, undo (even when called interactively) sets itself as
this-command, which breaks hippie-expand. This has the following
concrete effect: suppose there are two dabbrevs for "ab" in the
buffer, "abc" and "abcd" (occurring in that order, before point).
Also, suppose there is a yasnippet whose key is "ab", and yasnippet
comes before dabbrev in the hippie-expand-try-functions-list.
If a user presses "a b" and then M-/ (hippie-expand), repeatedly, what
happens on each M-/ is:
The yasnippet with key "ab" is expanded
The yasnippet is undone, and dabbrev is tried (and succeeds).
Dabbrev inserts "abcd". However, yasnippet-hippie-try-expand also
caused this-command to be set to undo.
hippie-expand sees that this-command (hippie-expand) !=
last-command (undo), and so the search string is set to "abcd"
instead of "ab". There are no further occurrences of "abcd" in the
buffer, and if the user was trying to expand "abc" (or any other
string beginning with "ab" but not "abcd"), this fails.
This PR fixes the above bug by resetting this-command to the value
it had before undo was called. Since we do not care about chaining
consecutive undos in this context, this doesn't break undo, and it
fixes the above issue with hippie-expand.
hippie-expand relies on the values of this-command and last-command in order to determine what argument it should pass to try-expand functions, in order to signal whether it's the "first" time they are being called.
However, undo (even when called interactively) sets itself as this-command, which breaks hippie-expand. This has the following concrete effect: suppose there are two dabbrevs for "ab" in the buffer, "abc" and "abcd" (occurring in that order, before point). Also, suppose there is a yasnippet whose key is "ab", and yasnippet comes before dabbrev in the hippie-expand-try-functions-list.
If a user presses "a b" and then M-/ (hippie-expand), repeatedly, what happens on each M-/ is:
This PR fixes the above bug by resetting this-command to the value it had before undo was called. Since we do not care about chaining consecutive undos in this context, this doesn't break undo, and it fixes the above issue with hippie-expand.