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.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76769 in the body.
You can then email your comments to 76769 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
juri <at> linkov.net, dmitry <at> gutov.dev, sbaugh <at> janestreet.com, bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Thu, 06 Mar 2025 03:58:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Sean Whitton <spwhitton <at> spwhitton.name>:
New bug report received and forwarded. Copy sent to
juri <at> linkov.net, dmitry <at> gutov.dev, sbaugh <at> janestreet.com, bug-gnu-emacs <at> gnu.org.
(Thu, 06 Mar 2025 03:58:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
X-debbugs-cc: juri <at> linkov.net, dmitry <at> gutov.dev, sbaugh <at> janestreet.com
Try this:
1. make a random edit to src/emacs.c
2. open Dired in the root of emacs.git
3. use 'm' to mark src
4. go back up one line, use 'i' to insert src
5. move down to emacs.c, use 'm' to mark that as well
6. C-x v v
This gets you a VC-Dir in which both src/ and src/emacs.c are marked.
--8<---------------cut here---------------start------------->8---
./
* src/
* edited src/emacs.c
--8<---------------cut here---------------end--------------->8---
But usually, you cannot get into this state. If you try to mark src/
when src/emacs.c is already marked, you can't, and vice-versa.
This is not just a display inconsistency, because it changes the list of
files that vc-dir-deduce-fileset returns.
I think that dired-vc-next-action has the more useful behaviour.
Freely marking and unmarking individual entries in VC-Dir would make it
easier to use. So I would like to make that possible. We can guard it
behind a defcustom so people can retain the old marking behaviour if
they prefer it.
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)
- 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
- 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/").
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:
--8<---------------cut here---------------start------------->8---
./
* src/
* edited src/cm.c
edited src/emacs.c
--8<---------------cut here---------------end--------------->8---
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:
--8<---------------cut here---------------start------------->8---
./
* src/
* edited src/cm.c
- edited src/emacs.c
--8<---------------cut here---------------end--------------->8---
(imagine the '-' is in a different colour).
How does this design look?
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Thu, 06 Mar 2025 07:57:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 76769 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Thu, 06 Mar 2025 08:02:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 76769 <at> debbugs.gnu.org (full text, mbox):
> Cc: juri <at> linkov.net, dmitry <at> gutov.dev, sbaugh <at> janestreet.com
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Thu, 06 Mar 2025 11:56:59 +0800
>
> 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?
Are you sure this is true for all the supported VCSes? AFAIR, some of
them considered directories in special ways, others ignored them. We
shouldn't design new VC features by looking at just one VCS.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Fri, 07 Mar 2025 03:14:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 76769 <at> debbugs.gnu.org (full text, mbox):
Hi!
On 06/03/2025 05:56, Sean Whitton wrote:
> --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/").
Could you give an example of when this is a problem in practice? If you
just pass this list to 'git diff' or 'git log', either command would
behave as if the fileset contained only a directory.
I suppose the list of files in log-edit would be more awkward. Is that all?
Speaking of interface changes, I wonder if marking (or unmarking) a
directory should select/unselect all of its files instead (those
displayed in the buffer). But that's a more drastic change.
People mentioned some VCS handling directories special - does there
exist a specific tracking of directories in commit history in some?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Fri, 07 Mar 2025 07:51:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 76769 <at> debbugs.gnu.org (full text, mbox):
> Cc: sbaugh <at> janestreet.com, juri <at> linkov.net
> Date: Fri, 7 Mar 2025 05:13:03 +0200
> From: Dmitry Gutov <dmitry <at> gutov.dev>
>
> People mentioned some VCS handling directories special - does there
> exist a specific tracking of directories in commit history in some?
I think svn does that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Fri, 07 Mar 2025 15:13:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 76769 <at> debbugs.gnu.org (full text, mbox):
On 07/03/2025 09:49, Eli Zaretskii wrote:
>> Cc:sbaugh <at> janestreet.com,juri <at> linkov.net
>> Date: Fri, 7 Mar 2025 05:13:03 +0200
>> From: Dmitry Gutov<dmitry <at> gutov.dev>
>>
>> People mentioned some VCS handling directories special - does there
>> exist a specific tracking of directories in commit history in some?
> I think svn does that.
Any chance someone could describe the scenario which behaves better with
SVN because of that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Sat, 08 Mar 2025 02:35:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 76769 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Thu 06 Mar 2025 at 10:01am +02, Eli Zaretskii wrote:
>> Cc: juri <at> linkov.net, dmitry <at> gutov.dev, sbaugh <at> janestreet.com
>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Date: Thu, 06 Mar 2025 11:56:59 +0800
>>
>> 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?
>
> Are you sure this is true for all the supported VCSes? AFAIR, some of
> them considered directories in special ways, others ignored them.
I'm not I'm expert in all of them, and so I'm not sure, no.
Can you remember anything more specific, or point me to a particular
VCS that you think might be different, that I could look into?
> We shouldn't design new VC features by looking at just one VCS.
Yes, very much agree.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Sat, 08 Mar 2025 02:41:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 76769 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Fri 07 Mar 2025 at 05:13am +02, Dmitry Gutov wrote:
> Hi!
>
> On 06/03/2025 05:56, Sean Whitton wrote:
>> --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/").
>
> Could you give an example of when this is a problem in practice? If you just
> pass this list to 'git diff' or 'git log', either command would behave as if
> the fileset contained only a directory.
>
> I suppose the list of files in log-edit would be more awkward. Is that all?
No, my thought here is that the VC-Dir abstraction is leaking through.
Modulo possible cases which I'm hoping to hear more about from Eli, if
the user has marked a directory, then the operation is on that directory
and everything in it, and passing through the information that the user
happened to have src/emacs.c marked as well is strange.
> Speaking of interface changes, I wonder if marking (or unmarking) a directory
> should select/unselect all of its files instead (those displayed in the
> buffer). But that's a more drastic change.
I hope that we can figure out something more subtle, but having the
ability to opt into that would be an improvement over what we have now,
I think.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Sat, 08 Mar 2025 02:45:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 76769 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Thu 06 Mar 2025 at 09:49am +02, Juri Linkov wrote:
> So this defcustom will permit an inconsistent state in VC-Dir?
I don't think it's an inconsistent state. VC-Dir has very strong
opinions on what is allowed to be marked, but it's not clear to me they
are justified and they are certainly not user friendly.
> 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.
Yes, that would be an improvement.
> 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
Yes, it's kind of an inverse of that.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Sat, 08 Mar 2025 02:51:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 76769 <at> debbugs.gnu.org (full text, mbox):
Hello,
Thanks for the feedback.
Here's an alternative proposal that sits only at the UI level.
A defcustom with values nil, 'ask, t. nil is the current behaviour.
'ask means to do the follow things after a y/n prompt, t means to do
them unconditionally:
- When you try to mark a file but you can't because the directory is
already marked, unmark the directory first.
- When you try to mark a directory but you can't because a file under it
is already marked, unmark all files under it and mark the directory,
instead.
Plus fixing dired-vc-next-action.
I still think it's worth discussing more thoroughgoing changes, but this
is a simpler proposal to fall back on.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Sat, 08 Mar 2025 10:47:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 76769 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 76769 <at> debbugs.gnu.org, sbaugh <at> janestreet.com,
> juri <at> linkov.net
> Date: Sat, 08 Mar 2025 10:34:29 +0800
>
> On Thu 06 Mar 2025 at 10:01am +02, Eli Zaretskii wrote:
>
> >> Cc: juri <at> linkov.net, dmitry <at> gutov.dev, sbaugh <at> janestreet.com
> >> From: Sean Whitton <spwhitton <at> spwhitton.name>
> >> Date: Thu, 06 Mar 2025 11:56:59 +0800
> >>
> >> 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?
> >
> > Are you sure this is true for all the supported VCSes? AFAIR, some of
> > them considered directories in special ways, others ignored them.
>
> I'm not I'm expert in all of them, and so I'm not sure, no.
>
> Can you remember anything more specific, or point me to a particular
> VCS that you think might be different, that I could look into?
I think SVN might be such a VCS.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Sat, 08 Mar 2025 10:49:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 76769 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Sat, 08 Mar 2025 10:50:01 +0800
>
> Here's an alternative proposal that sits only at the UI level.
>
> A defcustom with values nil, 'ask, t. nil is the current behaviour.
> 'ask means to do the follow things after a y/n prompt, t means to do
> them unconditionally:
>
> - When you try to mark a file but you can't because the directory is
> already marked, unmark the directory first.
>
> - When you try to mark a directory but you can't because a file under it
> is already marked, unmark all files under it and mark the directory,
> instead.
What about unmarking -- how will that work in your proposal?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Mon, 10 Mar 2025 05:02:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 76769 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sat 08 Mar 2025 at 12:48pm +02, Eli Zaretskii wrote:
>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Date: Sat, 08 Mar 2025 10:50:01 +0800
>>
>> Here's an alternative proposal that sits only at the UI level.
>>
>> A defcustom with values nil, 'ask, t. nil is the current behaviour.
>> 'ask means to do the follow things after a y/n prompt, t means to do
>> them unconditionally:
>>
>> - When you try to mark a file but you can't because the directory is
>> already marked, unmark the directory first.
>>
>> - When you try to mark a directory but you can't because a file under it
>> is already marked, unmark all files under it and mark the directory,
>> instead.
>
> What about unmarking -- how will that work in your proposal?
Just the same as it does now, I think.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Mon, 10 Mar 2025 15:49:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 76769 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 76769 <at> debbugs.gnu.org, sbaugh <at> janestreet.com,
> juri <at> linkov.net
> Date: Mon, 10 Mar 2025 13:01:46 +0800
>
> On Sat 08 Mar 2025 at 12:48pm +02, Eli Zaretskii wrote:
>
> >> From: Sean Whitton <spwhitton <at> spwhitton.name>
> >> Date: Sat, 08 Mar 2025 10:50:01 +0800
> >>
> >> Here's an alternative proposal that sits only at the UI level.
> >>
> >> A defcustom with values nil, 'ask, t. nil is the current behaviour.
> >> 'ask means to do the follow things after a y/n prompt, t means to do
> >> them unconditionally:
> >>
> >> - When you try to mark a file but you can't because the directory is
> >> already marked, unmark the directory first.
> >>
> >> - When you try to mark a directory but you can't because a file under it
> >> is already marked, unmark all files under it and mark the directory,
> >> instead.
> >
> > What about unmarking -- how will that work in your proposal?
>
> Just the same as it does now, I think.
So one will be able to mark files easily and conveniently, using these
new features, but will be unable to unmark files with the same
convenience?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Tue, 11 Mar 2025 01:59:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 76769 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Mon 10 Mar 2025 at 05:47pm +02, Eli Zaretskii wrote:
> So one will be able to mark files easily and conveniently, using these
> new features, but will be unable to unmark files with the same
> convenience?
No, unmarking is already perfectly convenient, I think?
Could you perhaps describe the ways in which you find unmarking
inconvenient, or you think our users do?
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Tue, 11 Mar 2025 12:46:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 76769 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 76769 <at> debbugs.gnu.org, juri <at> linkov.net,
> sbaugh <at> janestreet.com
> Date: Tue, 11 Mar 2025 09:58:44 +0800
>
> Hello,
>
> On Mon 10 Mar 2025 at 05:47pm +02, Eli Zaretskii wrote:
>
> > So one will be able to mark files easily and conveniently, using these
> > new features, but will be unable to unmark files with the same
> > convenience?
>
> No, unmarking is already perfectly convenient, I think?
>
> Could you perhaps describe the ways in which you find unmarking
> inconvenient, or you think our users do?
The toggle part is usually very handy.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Wed, 12 Mar 2025 07:20:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 76769 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Tue 11 Mar 2025 at 02:44pm +02, Eli Zaretskii wrote:
> The toggle part is usually very handy.
I'm not sure what you mean here. Do you mean these two features:
--8<---------------cut here---------------start------------->8---
U - if the cursor is on a file: unmark all the files with the same state
as the current file
- if the cursor is on a directory: unmark all child files
--8<---------------cut here---------------end--------------->8---
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Wed, 12 Mar 2025 14:30:04 GMT)
Full text and
rfc822 format available.
Message #56 received at 76769 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev, 76769 <at> debbugs.gnu.org, sbaugh <at> janestreet.com,
> juri <at> linkov.net
> Date: Wed, 12 Mar 2025 15:19:34 +0800
>
> Hello,
>
> On Tue 11 Mar 2025 at 02:44pm +02, Eli Zaretskii wrote:
>
> > The toggle part is usually very handy.
>
> I'm not sure what you mean here. Do you mean these two features:
>
> --8<---------------cut here---------------start------------->8---
> U - if the cursor is on a file: unmark all the files with the same state
> as the current file
> - if the cursor is on a directory: unmark all child files
> --8<---------------cut here---------------end--------------->8---
No. You said:
> - When you try to mark a file but you can't because the directory is
> already marked, unmark the directory first.
I'm asking: what if I want to unmark a file whose directory is already
unmarked?
You said:
> - When you try to mark a directory but you can't because a file under it
> is already marked, unmark all files under it and mark the directory,
> instead.
I'm asking: what if I want to unmark a directory which has a file
under it already unmarked?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Fri, 14 Mar 2025 03:42:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 76769 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Wed 12 Mar 2025 at 04:29pm +02, Eli Zaretskii wrote:
>> - When you try to mark a file but you can't because the directory is
>> already marked, unmark the directory first.
>
> I'm asking: what if I want to unmark a file whose directory is already
> unmarked?
> [...]
>
>> - When you try to mark a directory but you can't because a file under it
>> is already marked, unmark all files under it and mark the directory,
>> instead.
>
> I'm asking: what if I want to unmark a directory which has a file
> under it already unmarked?
Ah, these are good questions. Here is a revised proposal:
A defcustom with values nil, 'ask, t. nil is the current behaviour.
'ask means to do the follow things after a y/n prompt, t means to do
them unconditionally:
- When you try to mark a file but you can't because the directory is
already marked, unmark the directory first.
- When you use unmark on a file that is not explicitly marked but its
directory is marked, unmark the directory and mark all files under it
except the current one.
- When you try to mark a directory but you can't because a file under it
is already marked, unmark all files under it and mark the directory,
instead.
- When you use unmark on a directory that is not marked but has some
files under it marked, unmark all of those.
Plus fixing dired-vc-next-action.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Fri, 14 Mar 2025 08:25:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 76769 <at> debbugs.gnu.org (full text, mbox):
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Fri, 14 Mar 2025 11:41:34 +0800
>
> Ah, these are good questions. Here is a revised proposal:
>
> A defcustom with values nil, 'ask, t. nil is the current behaviour.
> 'ask means to do the follow things after a y/n prompt, t means to do
> them unconditionally:
>
> - When you try to mark a file but you can't because the directory is
> already marked, unmark the directory first.
>
> - When you use unmark on a file that is not explicitly marked but its
> directory is marked, unmark the directory and mark all files under it
> except the current one.
>
> - When you try to mark a directory but you can't because a file under it
> is already marked, unmark all files under it and mark the directory,
> instead.
>
> - When you use unmark on a directory that is not marked but has some
> files under it marked, unmark all of those.
>
> Plus fixing dired-vc-next-action.
SGTM, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Sat, 15 Mar 2025 01:19:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 76769 <at> debbugs.gnu.org (full text, mbox):
On 14/03/2025 05:41, Sean Whitton wrote:
> - When you try to mark a file but you can't because the directory is
> already marked, unmark the directory first.
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.
> - When you use unmark on a file that is not explicitly marked but its
> directory is marked, unmark the directory and mark all files under it
> except the current one.
>
> - When you try to mark a directory but you can't because a file under it
> is already marked, unmark all files under it and mark the directory,
> instead.
>
> - When you use unmark on a directory that is not marked but has some
> files under it marked, unmark all of those.
All these sound great.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Sat, 15 Mar 2025 07:31:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 76769 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sat 15 Mar 2025 at 03:18am +02, Dmitry Gutov wrote:
> On 14/03/2025 05:41, Sean Whitton wrote:
>
>> - When you try to mark a file but you can't because the directory is
>> already marked, unmark the directory first.
>
> 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?"
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.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Sat, 15 Mar 2025 20:09:03 GMT)
Full text and
rfc822 format available.
Message #71 received at 76769 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Sun, 16 Mar 2025 03:40:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 76769 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sat 15 Mar 2025 at 10:08pm +02, Dmitry Gutov wrote:
> The rest of the scenarios you described seem to make sense unconditionally,
> without extra prompt. Or might anyway.
> [...]
> 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.
These are good points. I now think perhaps only the more surprising
ones ought to be behind the defcustom, possibly only just this one.
> 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.
Yes, there's a good chance we'll want to change which ones are behind
the defcustom after trying to use it for a while.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Tue, 01 Apr 2025 07:35:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 76769 <at> debbugs.gnu.org (full text, mbox):
Hello,
I discovered another inconsistency in current VC-Dir which must be
resolved first. Suppose you have:
--8<---------------cut here---------------start------------->8---
./
* admin/
edited admin/emake
admin/notes/
edited admin/notes/www
--8<---------------cut here---------------end--------------->8---
and then you move point to admin/notes/ and type 'm'.
This is allowed. The marks become:
--8<---------------cut here---------------start------------->8---
./
* admin/
edited admin/emake
* admin/notes/
edited admin/notes/www
--8<---------------cut here---------------end--------------->8---
However, if you instead start with this:
--8<---------------cut here---------------start------------->8---
./
admin/
edited admin/emake
* admin/notes/
edited admin/notes/www
--8<---------------cut here---------------end--------------->8---
and then you move point to admin/ and type 'm', it's an error.
It won't let you mark admin/.
*If* it is allowed to have both admin/ and admin/notes/ marked,
then it shouldn't matter which order you mark them in.
I think I should change it to *not* allow admin/notes/ to be marked at
the same time as admin/. Does that sound right to others?
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Tue, 01 Apr 2025 21:03:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 76769 <at> debbugs.gnu.org (full text, mbox):
On 01/04/2025 10:33, Sean Whitton wrote:
> I think I should change it to*not* allow admin/notes/ to be marked at
> the same time as admin/. Does that sound right to others?
Yes for me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Tue, 01 Apr 2025 21:45:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 76769 <at> debbugs.gnu.org (full text, mbox):
Sean Whitton <spwhitton <at> spwhitton.name> writes:
> Hello,
>
> I discovered another inconsistency in current VC-Dir which must be
> resolved first. Suppose you have:
>
> ./
> * admin/
> edited admin/emake
> admin/notes/
> edited admin/notes/www
>
>
> and then you move point to admin/notes/ and type 'm'.
> This is allowed. The marks become:
>
> ./
> * admin/
> edited admin/emake
> * admin/notes/
> edited admin/notes/www
>
>
> However, if you instead start with this:
>
> ./
> admin/
> edited admin/emake
> * admin/notes/
> edited admin/notes/www
>
> and then you move point to admin/ and type 'm', it's an error.
> It won't let you mark admin/.
>
> *If* it is allowed to have both admin/ and admin/notes/ marked,
> then it shouldn't matter which order you mark them in.
>
> I think I should change it to *not* allow admin/notes/ to be marked at
> the same time as admin/. Does that sound right to others?
So it's already possible to have a directory and its subdirectory in the
same fileset? So vc backends already need to support filesets which
contain both a directory and an entry in that directory?
Isn't this good news? Because it means we could actually have vc-dir
allow "filesets which contain a directory and a file in that directory"
more generally, as in your original proposal on this bug. Since, after
all, it seems to already be supported.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76769; Package
emacs.
(Wed, 02 Apr 2025 02:50:08 GMT)
Full text and
rfc822 format available.
Message #86 received at 76769 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Tue 01 Apr 2025 at 05:44pm -04, Spencer Baugh:
> So it's already possible to have a directory and its subdirectory in the
> same fileset? So vc backends already need to support filesets which
> contain both a directory and an entry in that directory?
>
> Isn't this good news? Because it means we could actually have vc-dir
> allow "filesets which contain a directory and a file in that directory"
> more generally, as in your original proposal on this bug. Since, after
> all, it seems to already be supported.
Unfortunately we're doing a lot of guessing since we haven't got someone
with lots of svn experience available to comment. I think you are right
though that the fact this behaviour has long been allowed can make us
feel a bit more confident about making more significant changes.
One thing that we know is still definitely unsupported is marking an
entry that's a non-directory file. It's only a subdirectory that I
discovered can be marked in some circumstances, at present.
--
Sean Whitton
Reply sent
to
Sean Whitton <spwhitton <at> spwhitton.name>:
You have taken responsibility.
(Sun, 06 Apr 2025 03:20:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Sean Whitton <spwhitton <at> spwhitton.name>:
bug acknowledged by developer.
(Sun, 06 Apr 2025 03:20:02 GMT)
Full text and
rfc822 format available.
Message #91 received at 76769-done <at> debbugs.gnu.org (full text, mbox):
Hello,
This is all implemented now on master. Please test, and let me know if
you think there could be some useful tweaks to some of the behaviours.
--
Sean Whitton
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 04 May 2025 11:24:24 GMT)
Full text and
rfc822 format available.
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.