GNU bug report logs - #76769
31.0.50; marking inconsistency between VC-Dir and dired-vc-next-action

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: dmitry <at> gutov.dev, 76769 <at> debbugs.gnu.org, sbaugh <at> janestreet.com
Subject: bug#76769: 31.0.50; marking inconsistency between VC-Dir and dired-vc-next-action
Date: Thu, 06 Mar 2025 09:49:53 +0200

> So my proposal to make things more consistent would be:
>
> - a new defcustom, which when non-nil, allows freely marking both files
>   in directories, and those directories themselves, in VC-Dir
>
>   (I think we should default it to non-nil)

So this defcustom will permit an inconsistent state in VC-Dir?

> - fix dired-vc-next-action to respect that defcustom, i.e., when it is
>   nil, dired-vc-next-action shouldn't generate a VC-Dir buffer with
>   both src/ and src/emacs.c marked, in the example above

I think that dired-vc-next-action should be fixed to handle the current
default behavior in any case, even without adding the above defcustom.
Maybe it should raise an error for an inconsistent state instead of
trying to guess the user's intention.

> - change vc-dir-deduce-fileset to filter out individual files when the
>   directory containing them is marked.  E.g.
>
>   --8<---------------cut here---------------start------------->8---
>                            ./
>     *                      src/
>     *  edited              src/emacs.c
>   --8<---------------cut here---------------end--------------->8---
>   Currently vc-dir-deduce-fileset returns ("src/" "src/emacs.c"),
>   it should return just ("src/").

Not sure how this would affect various VCSes.  It would be better
to leave the decision to the user what should be selected
unless such a selected state causes ambiguity to a VCS.

> I think that for all the operations VC supports, passing a whole
> directory along with some of the files in it is semantically equivalent
> to just passing the whole directory.  If would have to be an esoteric,
> highly VCS-specific operation to do anything other than that, I think?
>
> For a case like this:
>
>                          ./
>    *                     src/
>    * edited              src/cm.c
>      edited              src/emacs.c
>
>
> the UI is a little confusing, because any operation will also act on
> emacs.c, but it is not marked.  I would propose that we add another
> symbol next to src/emacs.c, say '-', in a less prominently coloured
> face, indicating that despite not having been explictly marked, it is
> still effectively part of the fileset:
>
>                          ./
>    *                     src/
>    * edited              src/cm.c
>    - edited              src/emacs.c
>
> (imagine the '-' is in a different colour).

It seems this UI still doesn't resolve the ambiguity for a VCS.

> How does this design look?

This looks like handling a group of checkbox selections in some UI
where the group checkbox has the third state [-]:

                           ./
     -                     src/
     * edited              src/cm.c
       edited              src/emacs.c

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.