bug#52507: [PATCH] Option for vc-delete-file to keep file on disk

[Dmitry Gutov]

On 27.12.2021 07:08, Ashwin Kafle wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> > > > But the file would stay around, right? That would be different.
> > > Only if you give vc-delete-file a prefix argument, otherwise it'll
> > > be
> > > exactly the same.  It will delete even if we use git rm --cached (because
> > > it is checked later if the file exists anymore or not)
> >
> > OK, that seems to make sense. But how would we convey to the user that
> > that "removed" (followed by "unregistered") refers to the staging
> > area?
>
> By mentioning it in the manual or perhaps in the docstring of
> vc-delete-file?  It should be intuitive enough once you do it.

Ideally the user interface would convey that information without 
requiring the user to read the manual.

> > Patch which would implement this in VC-Dir/Git is welcome.
>
> Can you please explain to me briefly how vc-dir gets this info?  I will
> try at it but if you don't hear from me in a week then you know what
> happened ;-)

It's fairly involved. There is the vc-git-dir-status-files which fetches 
the status information asynchronously. But it is also updates for the 
individual files when a buffer is saved, if a VC-Dir buffer is already 
open (then the status comes from vc-git-state).

There is also vc-git-dir-printer which renders individual entries.

And finally, there is the ewoc.el package which stores the information 
about the statuses of files which are displayed inside the VC-Dir 
buffer. One should probably verify that it can show different statuses 
for one file name (might be non-trivial to change, or not).

> On a related note, how do you test patches?  Last time i had to manually
> C-M-x each and every function that was changed.

I either use 'M-x eval-buffer' (bound to a key, 'C-c v' in my config) to 
re-evaluate the whole buffer which contains the changed code, or in some 
other cases I run 'make' in the checkout which updates the .elc files, 
and then restart Emacs (or rather launch a second instance for testing, 
while keeping the first one running for editing).

> Is there a way to tell
> emacs to ignore byte compiled files so as a simple restart will apply
> new changes?

  (setq load-prefer-newer t)

should tell Emacs to do exactly that. Though I suppose this will depend 
on the order the packages are loaded -- if the edited file is loaded 
before the part of your init script where this line resides, or -- even 
worse -- is preloaded, this won't have the desired effect.

But otherwise this setting is very handy, and I recommend people turn it 
on. Especially when developing their own packages.

> > And the next step would be to ensure that such deletions (which keep
> > the file on disk) can be committed by vc-next-action.
>
> If it shows the two files, then you can mark the one saying removed and
> vc-next-action can commit it.

I mean verify that this actually works. As a UI, it sounds workable.