Hmmm, I don’t exactly understand your problem. From what I recall you can undo in the scratch buffer. Are you using vanilla emacs?
this post was submitted on 16 Jul 2023
5 points (85.7% liked)
Emacs
2194 readers
1 users here now
Our infinitely powerful editor.
founded 4 years ago
MODERATORS
Hi @ouigol@beehaw.org.
I'm using vanilla emacs with my own configuration. And replying to Sunoc made me remember that the scratch buffer starts as read-only and not in org-mode.
So it seems it comes from there...
I'll have to bissect it?
Thanks a lot... :)
By default undo does work in the scratch buffer so it is something in your configuration that is keeping this from working. As a quick way to check, try running emacs -q, which skips loading your configuration, and see if you have undo in the scratch buffer there; if so, it's definitely something you have in you configuration.
You can bisect your configuration to figure out how you are deactivating undo. You can do this manually or with the help of the bug-hunter package.
Hi,
That's a surprising issue, especially if the scratch buffer is the only text buffer in which the undo doesn't work.
Here is what I'm thinking right now:
- Just to be sure, isn't your scratch buffer in read-only ? You can toggle that with
C-x C-q. - Is the keybinding you are using to undo set properly ? You can check it with
C-h k C-/(for example, for checkingC-/). - If it's none of these, I'd try to run the
undofunction directly withM-x undoto see if you can get some meaningful error messages.
I confirmed with both my personal config that uses undo-tree (great tool btw) and also in a default configuration of Emacs; both cases work fine to undo in scratch.
Hope any of that can help!
Cheers
Hello Sunoc.
- the buffer is not in
read-only, but it always start as so. - the keybinding is ok since it works in all the rest of the buffers.
- Upon calling
undo, emacs says "no undo information in this buffer" (searching for this didn't seem to give relevant information except something from 2006 and then something about specific of a table-spreadsheet that I don't use).
From this and @ouigol@beehaw.org (I will relpy after this one) it looks that it may be my configuration, since I'm using vanilla emacs with my own configuration.
Anyway, thanks a lot for your time! :)
After checking the source, it looks like this error is triggered when the buffer-undo-list variable is equal to t, which means the buffer is unmodified, or at least that this variable is not modified from the scratch buffer.
There is something else in the documentation of this variable: <If the value of the variable is t, undo information is not recorded.>
Maybe you can try to fix your issue by forcing the buffer-undo-list variable to nil for the elisp mode, as follow:
(add-hook 'elisp-mode (lambda () (setq-local buffer-undo-list nil)))
Maybe you can try to fix your issue by forcing the buffer-undo-list variable to nil for the elisp mode, as follow: (add-hook 'elisp-mode (lambda () (setq-local buffer-undo-list nil)))
I tried it but still no joy...
Looking at this issue I noticed 3 things that may help to pinpoint the origin...:
- I have 2 variables set that affect the scratch buffer in my config (without yours, that it's the 3rd):
(setq initial-major-mode 'org-mode)
(setq-default major-mode 'org-mode)
- Before this reply,
(setq-default major-mode 'org-mode)was(setq default-major-mode 'org-mode). Both expressions seems indistinguishable in the resulted behavior. - The scratch buffer starts in
org-roammode (andread-onlymode), which is very strange, but can obviously be related and/or part of the problem. The org-roam section (my config is literate in org-mode) comes before this variables being set.
What does this info may imply?
Okay, I could reproduce your situation by evaluating
(setq initial-major-mode 'org-mode)
(setq-default major-mode 'org-mode)
This setup forces the scratch buffer to be in org-mode, apparently breaking most of the available keybindings for it, including the undo.
The value for the initial-major-mode should be kept as lisp-interaction-mode, if your configuration requires to set it.
Otherwise I would remove both of these lines all together and see if the default behavior brings back the scratch buffer to be in the expected lisp-interaction-mode again.
The additional hook I provided in my previous post shouldn't be needed either.