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 checking C-/).
If it’s none of these, I’d try to run the undo function directly with M-x undo to 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.
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 (I will relpy after this one) it looks that it may be my configuration, since I’m using vanilla emacs with my own configuration.
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:
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):
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-roam mode (and read-only mode), 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.
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.
Yes, I have been using eshell exclusively for the last 7 years. It does have a few drawbacks, but for me it’s definitely a win overall due to a) everything being in a buffer, b) being able to run both elisp functions and executables from the command line, and c) tramp.
P.s. I chuckled a bit when you mentioned sixel graphics support as modern. :) Jokes aside, I have my own toy implementation of sixel graphics in elisp, so decent emacs support is probably out there already.
@AusatKeyboardPremi@kelvie If you use doom-Emacs, you just hit C-z to go to Emacs-state and hit it back again to go back to Evil-mode after working in a mode you think Emacs-state is more productive...
I haven’t fully moved my terminal needs to Emacs (though I’d like to) for the same little niggles you mentioned. Just wanted to recommend another option amongst the good ones already suggested here.
Eat has its own major mode which is used when you open a standalone buffer via the eat function.
When it’s embedded in Eshell it mostly just does the right thing whenever you invoke a command that uses terminal control codes (e.g. htop) – and many of those can be closed with q, yes.
I assume Eat is activated for any program listed in the eshell-visual-commands variable (but I’ll admit I don’t really understand how that works). The notable new minor modes present when I run htop in eshell are Eat–Eshell-Local and Eat–Eshell-Process-Running.
Yeah i was just asking if you close your eat buffer with q. I really like having one button to open and close my terminal so thats why i asked. Thanks for the extensive awnser tho
Thanks for the rec, my first impression is that it doesn’t really work well with evil-mode, but that may be my configuration error (as it is with emacs).
Vterm not working well with evil was actually my motivation to drop evil completely and embrace emacs key bindings.
It was the best decision I made. I don’t perceive a any measurable impact on my ability to efficiently write code or edit text, but I’ve seen a significant improvement on my ability to use emacs in general
As far as I remember it was working fine like a year ago when I was trying to make my own config (just vterm and evil packages were required). At the time the Doom people were saying it was impossible due to how terminal emulation works. Now it’s mostly working in Doom unless you go over 1 line. If you do, you’re not in a good place since you can’t use ESC to jump between words.
Interesting post given auto placement is something I still haven’t got to grips with after 30 years. Definitely some good techniques to follow up on, along with motivation to up my embark and ace-window/avy game.
OK, more than wow! Probably the most helpful, in-depth and up to date coverage of this topic I’ve seen in 40 years of barely scratching the surface of emacs. Thank you!
emacs
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.