GNU bug report logs -
#76769
31.0.50; marking inconsistency between VC-Dir and dired-vc-next-action
Previous Next
Reported by: Sean Whitton <spwhitton <at> spwhitton.name>
Date: Thu, 6 Mar 2025 03:58:02 UTC
Severity: normal
Found in version 31.0.50
Done: Sean Whitton <spwhitton <at> spwhitton.name>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On 15/03/2025 09:30, Sean Whitton wrote:
>> That one sounds a little odd, doesn't it? Marking something would be expected
>> to extend the set of files acted upon, and here it the opposite.
>
> I see what you mean, but I'd argue it's still the most useful behaviour,
> especially after a confirmation prompt -- I'll make it clear what's
> going to happen in the prompt, e.g. "Unmark this directory in order to
> mark this single file?"
I've based my response expecting to set the new defcustom to t if the
behavior makes sense.
Perhaps you have a point that with an extra prompt there's not much
downside. And the upside, I suppose, is in saving time not having to go
to the directory node (to "unmark"), or unmarking all the other entries
under that directory. If the user intent is indeed to keep only some of
the entries marked, not the whole dir.
The rest of the scenarios you described seem to make sense
unconditionally, without extra prompt. Or might anyway.
> To put it another way, why would you want to mark that file if the
> directory is already marked? Either it's an error, and you can just say
> 'n' to the prompt, or it's deliberate and it's because you want to mark
> that file for your next operation, whether or not you've noticed that
> you need to unmark the directory first.
Yeah, IME it might be an error because I would just be going through the
items in VC-Dir, pressing 'm' to mark one after another - right now it
ends at the first element after a dir, and it would start to work
differently.
Anyway, I just wanted to voice a concern. Probably not a big deal, and
it might help to test the changes in practice for a while.
This bug report was last modified 49 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.