From: Dmitry Gutov <dgutov@yandex.ru>
To: Ashwin Kafle <ashwin@ashwink.com.np>
Cc: 52507@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
Subject: bug#52507: [PATCH] Option for vc-delete-file to keep file on disk
Date: Tue, 28 Dec 2021 02:53:19 +0200 [thread overview]
Message-ID: <a6cbfcab-1faf-a7db-905a-443bd31cce81@yandex.ru> (raw)
In-Reply-To: <85v8zay9il.fsf@ashwink.com.np>
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.
next prev parent reply other threads:[~2021-12-28 0:53 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-15 9:53 bug#52507: [PATCH] Option for vc-delete-file to keep file on disk Ashwin Kafle
2021-12-15 16:53 ` Juri Linkov
2021-12-15 17:41 ` Ashwin Kafle
2021-12-15 18:06 ` Juri Linkov
2021-12-15 18:26 ` Ashwin Kafle
2021-12-15 18:34 ` Ashwin Kafle
2021-12-16 17:01 ` Juri Linkov
2021-12-19 23:46 ` Dmitry Gutov
2021-12-23 17:20 ` Juri Linkov
2021-12-24 0:48 ` Dmitry Gutov
2021-12-26 17:43 ` Juri Linkov
2021-12-26 19:12 ` Dmitry Gutov
2021-12-26 14:31 ` Ashwin Kafle
2021-12-26 14:23 ` Ashwin Kafle
2021-12-26 15:38 ` Dmitry Gutov
2021-12-26 15:51 ` Ashwin Kafle
2021-12-26 15:57 ` Dmitry Gutov
2021-12-26 16:12 ` Ashwin Kafle
2021-12-26 16:28 ` Dmitry Gutov
2021-12-26 17:03 ` Ashwin Kafle
2021-12-27 0:03 ` Dmitry Gutov
2021-12-27 4:08 ` Ashwin Kafle
2021-12-28 0:53 ` Dmitry Gutov [this message]
2022-09-08 14:17 ` bug#52508: " Lars Ingebrigtsen
2021-12-26 17:41 ` bug#52507: " Juri Linkov
2021-12-27 17:58 ` Juri Linkov
2021-12-15 22:59 ` Dmitry Gutov
2021-12-16 7:12 ` Ashwin Kafle
2021-12-16 10:03 ` Dmitry Gutov
2021-12-16 11:26 ` Ashwin Kafle
2021-12-16 11:27 ` Dmitry Gutov
2021-12-16 14:07 ` bug#52507: [PATCH v3] " Ashwin Kafle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a6cbfcab-1faf-a7db-905a-443bd31cce81@yandex.ru \
--to=dgutov@yandex.ru \
--cc=52507@debbugs.gnu.org \
--cc=ashwin@ashwink.com.np \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.