[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rename, delete and move current buffer and file

From: Jarosław Rzeszótko
Subject: Re: Rename, delete and move current buffer and file
Date: Thu, 10 May 2018 07:37:53 +0200

On Thu, May 10, 2018 at 1:50 AM, Van L <address@hidden> wrote:

> On 9 May 2018, at 22:28, Stefan Monnier <address@hidden> wrote:
>> I do not understand what you have in mind with write-file. This creates a
>> copy, which is natural given the name. Do you envision some changes to it?
> Not sure what happened, but my first answer said:
>    so maybe we could instead have `C-x C-w` prompt the user
>    "delete the old file (y or n)?"

Is there a channel for demand driven development? like:


I believe in the longer term it is better for the Emacs devotee to learn enough of Dired to `type R’ for renaming a file or use the shell command in that context `! mv ? delete-me’.

This might be a personal thing, but Dired for a quick rename is a bit like killing a fly with a cannon. I find anything involving additional buffers distracting when I am focused on changing a set of files - I am typically refactoring a program, which already involves keeping some items in working memory.

It always seemed to me rename-this-file-and-buffer (or however it might be called) is one of .emacs perennial "greatest hits". It also seems like a natural extension of existing set of functions involving buffers and files. Given this, I find the response here so far rather surprising. Personally I hoped Emacs could incorporate more of the most common customizations (the ones that do not involve breaking any compatibility or preexisting behavior) into core, the amount of additional packages you have to install in Emacs to make it competitive with a modern editor is huge, and involves changing nearly everything, e.g. how page scrolling behaves, how copy/paste behaves, ... If you look at something like prelude, some of it is very opinionated, but some of it just plugs what are IMO obvious gaps in Emacs, like this one, that could be patched without breaking anything. 

Jarosław Rzeszótkot

reply via email to

[Prev in Thread] Current Thread [Next in Thread]