The article praises the decision to expose buffers to the end-user, and I agree that it’s powerful to be able to use the same commands in basically every context… but it leads to a lot of confusion and awkwardness that I think needs to be addressed as well. My case in point: Several times a week, I need to rename a file I’m editing. Here’s what it looks like:
M-x rename-file
Choose the file I want to rename
Type in the new name and confirm
M-x rename-buffer
Enter the new name
In a different text editor, it looks like this:
(some keybinding or sequence)
Enter the new name
It could look like that in Emacs as well, but if you go looking around you find that it’s not in the core command set, and you have to dig up some script someone has already put together and then shove that into your init.el. Only then can you have workflow #2.
Emacs knows which buffers are file-backed, and could very well offer a command like rename-file-buffer. I don’t know why it doesn’t, in the Year of Our Lord 2022. Maybe some bikeshedding over what counts as a file-backed buffer, or naming the function, or some internals thing I don’t know about. But it probably has something to do with “everything’s a buffer” and not trying too hard to smooth over that.
While I agree with you about frustrations on awkward interfaces surrounding buffers, I’m not sure that I follow your example. For your example, I’d normally do
C-x C-w (or M-x write-file)
Enter the new name
It seems like it follows your desired path, accomplishes your objectives, and only uses built-in commands and default keybindings? Is there something that I’m missing?
This was my first thought. I gave saturn the benefit of the doubt here because C-x C-wcopies the file. It doesn’t rename it. But both dired-rename-file and write-file accomplish what you want: changing the name of both the file and the buffer.
The abundance of options is not necessarily a good thing. It hampers discoverability. I realize that saying things like that arguably makes me a bad emacs user, but we do exist.
True but in this is a case where the functionality is all of obvious, easy to code, and absent from the core product. I figure that the reason this reature is absent is because core emacs already has two better ways to get the workflow done. I don’t remember when I discovered the write-file method. I’d bet that it was early on in my use of emacs though so we’re talking early ’90s. I came to dired mode pretty late but learned very quickly how powerful it was.
I agree. I used write-file for years before I discovered dired mode. I have to admit that in my case, the extra file hanging aroung is usually not a problem for me but I use emacs as a IDE/code editor. Emacs is not a lifestyle for me.
That’s absolutely true and it’s interesting that they haven’t done this already.
How much do you want to bet there there aren’t a million and one “rename-buffer-and-file” functions floating around in an equal number of .emacs files? :)
For me, while I really truly do appreciate the power and wisdom of having my editor also be an capable programming environment unto itself, I think exactly this kind of lack of polish is going to continue to erode emacs adoption over the long haul.
Emacs not only knows when a buffer is attached to a file, it also does the right thing when it performs operations on the file from dired mode. I have a file I want to rename. I open the directory that it’s in with dired mode by pressing: c-x c-f enter from the buffer visiting the file. I press 'R' then fill out the new_filename in dialog. After the rename is finished, i press 'F' and I’m taken back to the buffer visiting the file. Emacs renames the file and automatically renames the buffer as you intended. Also note that the buffer never changes. Your new position is exactly the same as the old.
Ah! It sounds like dired is the thing I should have been using. I always wrote it off as a “power tool” for when you need to do heavier rearranging of files and directories – multi-renames, whatever – but maybe that’s what all the experience users are actually doing for renames?
This doesn’t address the larger point, but it does the pain in your workflow. You can achieve the same in one logical step by using dired’s write mode (Wdired) to do the rename in the dired buffer.
C-x C-j (opens dired in the directory the current buffer)
C-x C-q
The file in question inside the dired buffer
C-c C-c
As to why rename-file-buffer doesn’t also rename the buffers that are visiting that file, I’m guessing it is because it is written in C, and the code is already hairy enough to complicate it further with additional responsibilities.
Especially as there are edge cases. Buffers don’t have to have the same name as the file they are visiting. For example when you use clone-indirect-buffer-other-window, which some people use heavily in conjunction with narrowing. Should we rename all buffers visiting the file only where there is an exact match between the buffer and file name? what about when the file is part of the buffer name ej. foo.txt<3> or foo.txt/fun-name<2>? I think it is a reasonable choice to have rename-file do only one thing and let users implement a more dwim version by themselves.
I wrote a function to do that (“some script someone has already put together”). Once my work signs Emacs’s employer disclaimer of rights, I’m going to try to get this into Emacs proper.
Reading this made me realize that I can add a little function to my .emacs to do this (my strategy has tended to be to do it in a vterm session and then re-open the file when I need to do this once every blue moon).
I do think there should be “a thing” (though stuff like editing of remote files have to be answered). I do wonder how open GNU Emacs is to simple QoL improvements like that.
No thanks, I live it daily when using VSCode instead of emacs. While most on my team are sufficiently comfortable with VSCode and so I use it professionally, I always keep emacs around for “serious work” or whatever that means.
The article praises the decision to expose buffers to the end-user, and I agree that it’s powerful to be able to use the same commands in basically every context… but it leads to a lot of confusion and awkwardness that I think needs to be addressed as well. My case in point: Several times a week, I need to rename a file I’m editing. Here’s what it looks like:
M-x rename-fileM-x rename-bufferIn a different text editor, it looks like this:
It could look like that in Emacs as well, but if you go looking around you find that it’s not in the core command set, and you have to dig up some script someone has already put together and then shove that into your
init.el. Only then can you have workflow #2.Emacs knows which buffers are file-backed, and could very well offer a command like
rename-file-buffer. I don’t know why it doesn’t, in the Year of Our Lord 2022. Maybe some bikeshedding over what counts as a file-backed buffer, or naming the function, or some internals thing I don’t know about. But it probably has something to do with “everything’s a buffer” and not trying too hard to smooth over that.While I agree with you about frustrations on awkward interfaces surrounding buffers, I’m not sure that I follow your example. For your example, I’d normally do
C-x C-w(orM-x write-file)It seems like it follows your desired path, accomplishes your objectives, and only uses built-in commands and default keybindings? Is there something that I’m missing?
This was my first thought. I gave saturn the benefit of the doubt here because
C-x C-wcopies the file. It doesn’t rename it. But bothdired-rename-fileandwrite-fileaccomplish what you want: changing the name of both the file and the buffer.The abundance of options is not necessarily a good thing. It hampers discoverability. I realize that saying things like that arguably makes me a bad emacs user, but we do exist.
True but in this is a case where the functionality is all of obvious, easy to code, and absent from the core product. I figure that the reason this reature is absent is because core emacs already has two better ways to get the workflow done. I don’t remember when I discovered the
write-filemethod. I’d bet that it was early on in my use of emacs though so we’re talking early ’90s. I came todired modepretty late but learned very quickly how powerful it was.write-fileis good to know about! I still have to then usedelete-file, but it is shorter.I agree. I used
write-filefor years before I discovereddiredmode. I have to admit that in my case, the extra file hanging aroung is usually not a problem for me but I use emacs as a IDE/code editor. Emacs is not a lifestyle for me.I always keep dired buffers of my working directories and clean up from there. Best dired key command might be ~ (flag all backup files).
That’s absolutely true and it’s interesting that they haven’t done this already.
How much do you want to bet there there aren’t a million and one “rename-buffer-and-file” functions floating around in an equal number of .emacs files? :)
For me, while I really truly do appreciate the power and wisdom of having my editor also be an capable programming environment unto itself, I think exactly this kind of lack of polish is going to continue to erode emacs adoption over the long haul.
Emacs not only knows when a buffer is attached to a file, it also does the right thing when it performs operations on the file from dired mode. I have a file I want to rename. I open the directory that it’s in with dired mode by pressing:
c-x c-f enterfrom the buffer visiting the file. I press'R'then fill out the new_filename in dialog. After the rename is finished, i press'F'and I’m taken back to the buffer visiting the file. Emacs renames the file and automatically renames the buffer as you intended. Also note that the buffer never changes. Your new position is exactly the same as the old.That got me thinking. I use dired to rename files (with the
rkeybinding) and that does update the buffer names.ris bound todired-do-renamewhich callsdired-rename-filewhich callsset-visited-file-nameon buffers that are visiting the file.Ah! It sounds like
diredis the thing I should have been using. I always wrote it off as a “power tool” for when you need to do heavier rearranging of files and directories – multi-renames, whatever – but maybe that’s what all the experience users are actually doing for renames?dired is how I browse the filesystem to see what’s there.
This doesn’t address the larger point, but it does the pain in your workflow. You can achieve the same in one logical step by using dired’s write mode (Wdired) to do the rename in the dired buffer.
As to why rename-file-buffer doesn’t also rename the buffers that are visiting that file, I’m guessing it is because it is written in C, and the code is already hairy enough to complicate it further with additional responsibilities.
Especially as there are edge cases. Buffers don’t have to have the same name as the file they are visiting. For example when you use
clone-indirect-buffer-other-window, which some people use heavily in conjunction with narrowing. Should we rename all buffers visiting the file only where there is an exact match between the buffer and file name? what about when the file is part of the buffer name ej.foo.txt<3>orfoo.txt/fun-name<2>? I think it is a reasonable choice to have rename-file do only one thing and let users implement a more dwim version by themselves.I wrote a function to do that (“some script someone has already put together”). Once my work signs Emacs’s employer disclaimer of rights, I’m going to try to get this into Emacs proper.
This doesn’t address your actual point, but adding just in case it’s useful to someone. Pretty sure I stole this from Steve Yegge years ago
Reading this made me realize that I can add a little function to my
.emacsto do this (my strategy has tended to be to do it in avtermsession and then re-open the file when I need to do this once every blue moon).I do think there should be “a thing” (though stuff like editing of remote files have to be answered). I do wonder how open GNU Emacs is to simple QoL improvements like that.
imagine life without emacs buffers?
No thanks, I live it daily when using VSCode instead of emacs. While most on my team are sufficiently comfortable with VSCode and so I use it professionally, I always keep emacs around for “serious work” or whatever that means.