Here's another, simple alternative that doesn't require recentf. Hooking the first function into kill-buffer-hook will push the filename associated with the buffer onto a list. (Note that, if you kill a buffer that's not visiting a file, it's gone for good.) The latter function pops that file off of the list and visits it:
(defvar killed-file-list nil
This is standard Emacs functionality (since 1998 / 20.3).
Assuming you have transient mark mode enabled, just mark the region, and use undo as normal, and Emacs will perform undo operations relevant to the (active) region only.
With transient mark mode off, or if the marked region is not active, use a C-u prefix argument to the undo command.
See: C-hf ...
Interestingly enough, there appears to be no built-in function to do that.
The following code works by inserting a unique marker on the buffer-undo-list at the beginning of a collapsible block, and removing all boundaries (nil elements) at the end of a block, then removing the marker. In case something goes wrong, the marker is of the form (apply identity ...
Use M-x revert-buffer. A buffer only visits a file. The revert-buffer function reloads the current buffer's source file from disk. So long as the file hasn't changed since you last saved it, as might happen if another process writes to it, revert-buffer will restore the buffer to point b, removing all text inserted after b.
As a bonus, you don't need ...
I recommend you do C-h f replace-string RET and read it:
This function is for interactive use only;
in Lisp code use `search-forward' and `replace-match' instead.
So, as suggested replace that call with something like
(while (search-backward "'" beginning t)
(replace-match "\\'" t t)
(goto-char (match-beginning 0)))
Some functions do "...
The author of undo-tree.el, Toby Cubitt, is presently too busy to fix this particular bug. If he has time in the future, he may look into the issue further. The author has indicated that he has difficulty reproducing the error reliably, and was recently unable to reproduce it using the master branch. It only occurs when using undo/redo-in-region. The ...
I like to do two things with undo. I turn off the amalgamation stuff (which by doing so permits undo one keystroke at at time); and, I get rid of the timer (because timers affect performance and drive me absolutely bonkers, unless they are idle-timers.
Alternatively, you can modify undo-auto-amalgamate which is hard coded at 20 and set it to a lesser/...
@stsquad's answer got me on the right path. Basically, the steps are:
do your thing
re-enable undo and restore the buffer-undo-list
So here's a sketch of such a function:
(defun disable-undo-one-off ()
(let ((undo buffer-undo-list)) ; save the undo list
(buffer-disable-undo) ; disable undo
I want to simplify the kill-ring so that it behaves like a simple clipboard. I find it complex that the kill-ring contains multiple items.
You can completely ignore the fact that the kill ring contains multiple items if you want. If you only ever use yank (C-y) to paste, then you will only ever paste the most recently-killed text.
Unless you actively tell ...
Non-nil while performing an undo.
Some change-hooks test this variable to do something different.
Bearing in mind that "redoing" is really still "undoing" in Emacs, this ought to cover all cases.
ediff-mode has built-in bindings to apply and revert diff hunks.
Let's say you are running ediff between files/buffers A and B.
To copy A's region to B, press a
To undo that, i.e. to restore the original region in buffer B, do rb
To copy B's region to A, press b
To undo that, i.e. to restore the original region in buffer A, do ra
While the ...
I would like to ask you: “Do you really want to kill it?”. Indeed, killing a
buffer is such a common thing in Emacs world, but once killed, buffer is
gone, and as your question demonstrates, it's not always desirable.
However we can choose another way, so that you never need to restore killed
buffer — just prefer burying to killing. Take a look at
Kill or ...
From the various comments so far, it sounds like you are in the process of learning about Emacs (welcome!). There are many things in Emacs that are unlike other editors, and as you go through the tutorials and read about things you might come across concepts like the kill ring that seem confusing and/or unnecessary.
Emacs is endlessly configurable so you ...
IIUC buffer-undo-list is missing from buffer-local-variables by accident. The accident is that some code clean up ended up making buffer-local-variables use the same loop over some of the buffer's local variables, as the loop used when the garbage collector looks for references in a buffer object.
As it turns out, buffer-undo-list needs to be handled ...
I use this solution from this SO post and it works fine.
The solution is elegant but not perfect; it stores a list of active buffers and returns the first file from the the recentf-list that doesn't belong to the list of active buffers.
;; Reopen the last killed buffer
;; Source: https://stackoverflow.com/questions/10394213/emacs-reopen-previous-killed-...
Turns out that it seems to be related to me still having a (cua-mode t) line in my ~/.emacs file. After I removed this line, the line:
(global-set-key (kbd "C-z") 'undo)
in my ~/.emacs file worked just fine.
I see this in the Elisp manual, node Undo:
All buffer modifications add a boundary whenever the previous
undoable change was made in some other buffer. This is to ensure
that each command makes a boundary in each buffer where it makes
I'm guessing that that design is responsible for the behavior you see here.
Adding what ...
Here is an with-undo-collapse macro that uses Emacs-26 change-groups feature.
This is atomic-change-group with a one line change, adding undo-amalgamate-change-group.
It has the advantages that:
It doesn't need to manipulate the undo data directly.
It ensures undo data isn't truncated.
(defmacro with-undo-collapse (&rest body)
"Like `progn' but ...
Some changes to the undo machinery "recently" broke some hack viper-mode was using to do this kind of collapsing (for the curious, it's used in the following case: when you press ESC to finish an insertion/replacement/edition, Viper wants to collapse the whole change into a single undo step).
To fix it cleanly, we introduced a new function undo-amalgamate-...
An undo operation combines several elements from the undo list. A nil entry in the list marks the boundary between two change groups. By removing the nil at the start of the list which is automatically inserted by the toplevel loop¹, you can group the timestamp update with the last buffer change, which technically doesn't match your request but practically ...
You need to turn on recentf-mode. To do that, run M-x recentf-mode. Then, the function might not work until you open or kill some new buffers; I don't think you'll have recentf-list filled out.
If you want this to be enabled when Emacs starts up, put this in your init file:
You can then put the defun you found in there, and bind it to a key,...
You can clear the undo history with this:
(setq buffer-undo-list nil) ; discard undo history
(set-buffer-modified-p nil) ; mark the buffer as unmodified
I have the following functions in my config for this use case. If the buffer is associated with a file then you can set the "undo point" and go back to it with the undo-all command. For buffers without a ...
There is undo-amalgamate-change-group nowadays. Used for instance in the function viper-adjust-undo in the file lisp/emulators/viper-cmd.el:
(defun test-collapse ()
(let ((cg (prepare-change-group)))
EDIT: I didn't pay attention when answering, and answered something else the OP didn't ask. Once again, I'm sorry. Thank you for
your words, @CodyChan.
Well, I'm no Emacs veteran, and maybe this possibly has became available just on recent versions. I know I'm coming some years later, but maybe it can be helpful for others, since my search got me here.
The problem with what you suggest is that the undo-tree is a list of deltas to get from where you are to where you want to be. While it is perfectly possible to disable undo tracking on a buffer I'm not sure what the effect of not actively recording changes would be. I currently have a toggle to turn undo on/off on a particular buffer as it doesn't make ...
When running undo, there are two possibilities. Either you're undoing something, or redoing something. You can tell the difference by what gets echoed to the minibuffer.
On my Emacs (24.3.1), after explicitly setting the modified status of the buffer to nil, any "undo" results in setting the buffer status to edited, but "redo" does not change the buffer ...
Select the buffer that was changed by the last modification (e.g. put the cursor there), and then hit C-_ (undo).
Undo is per buffer. Each Ediff change affects one buffer. Go to that buffer and use undo.
This works on the latest develop, (fresh installation). open undo-tree-visualise with SPC a u. be sure that you have the minimum emacs version:
(defconst spacemacs-emacs-min-version "24.3" "Minimal version of Emacs.")
This behaviour has changed now for Emacs 25.1.
The original behaviour was to ensure that every buffer got an undo boundary, but it has negative side effects. Emacs 25.1 uses a new heuristic -- changes are lot more limited now and should only be to those buffers where changes have happened as a result of the command, not just by side effect.
So, in more ...