GNU bug report logs - #41097
28.0.50; (dired-toggle-marks) not working after copy

Previous Next

Package: emacs;

Reported by: Jean Louis <bugs <at> gnu.support>

Date: Tue, 5 May 2020 15:35:01 UTC

Severity: minor

Found in version 28.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #106 received at 41097 <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: michael_heerdegen <at> web.de, Eli Zaretskii <eliz <at> gnu.org>,
 41097 <at> debbugs.gnu.org, tomasn <at> posteo.net, Jean Louis <bugs <at> gnu.support>
Subject: Re: bug#41097: 28.0.50; (dired-toggle-marks) not working after copy
Date: Mon, 11 May 2020 15:15:57 +0200
Drew Adams <drew.adams <at> oracle.com> writes:

>> > If m is for marking then (dired-toggle-marks) should work with
>> > success, because why it should not work if the file is flagged with
>> > C, because it is not a file for deletion.
>> >
>> > If is is for marking and d for flaging means to prepare for deletion,
>> > then "m" does not flag, it marks, so there are no "other flags" but
>> > there is just one mark and other flags. If menu separates marks from
>> > flags, then the function should separate marks from flags too, maybe
>> > except for flagged files.
>> >
>> > Confusing, but I don't see a logic why I should not be able to toggle
>> > marks on files that have been recently copied or renamed.
>> 
>> Because t toggles marks, and C is not a mark, it's a flag.
>
> This is not true.  Let's please not go there.
>
> The doc has always spoken of "flagging" only for the
> deletion mark, `D', and that mark is also called a
> "flag" (_the_ flag).  It is the only mark that has
> ever been called a "flag".  It flags a possible
> danger -- "Hey! Over here. Watch out."
>
> But `D', `C', and any others are all marks.  You can
> create any marks you like - use any char.
>
> It's true that, for simplicity, the operation of
> "marking" generally refers to marking with `*'.
>
> Command `* c' (`dired-change-marks') is specifically
> about changing marks - substituting one char for
> another.
>
> As for the general question from Jean-Louis, I (and
> Michael) already answered it:
>
> * If you want `t' to UNmark files that have a mark
>   (e.g. `C') other than `*' then you need to first
>   change those `C' marks to `*' (`* c C *' does
>   that for `C' marks).
>
> * If you want `t' to _mark_ the files marked `C'
>   then you need to first unmark them.  You can do
>   that in two ways, depending on what you really
>   want:
>
>   1. Unmark ALL marks, of any kind. `U' or `M-DEL
>      RET' does this.
>
>   2. Change just the `C' marks to ` ' (space char).
>      `* c C SPC' or `M-DEL SPC' does this.
>      ("Marking" with a space char = unmarking.)
>
> Why/when would you ever want to use `* c C *'
> instead of `U'?  When you also had some other marks
> (`D', `E' or whatever), which you did _not_ want to
> change to `*'.
>
> And yes, unmarking applies also to `D' marks (aka
> flags).  Unmarking (unflagging) is not something
> dangerous or noteworthy.  Flagging (`D') is.
>
> Dired copy-file commands mark with `C' in the target
> directory listing.  This is a feature, not a bug.
>
> And `t' toggles only files marked `*' and unmarked
> files.  This is also a feature.  The most common,
> most active, use of marks is with the `*' mark.
>
> The general "marking" commands use `*', by default.
> It is the default mark character, the default value
> of `dired-marker-char'.  Its doc tells you that is
> is "what the do-commands look for, and what the
> mark-commands store".
>
> I think the doc is pretty clear, but yes, it might
> require some careful reading.
>
>> If the doc string which you quoted several times said this:
>> 
>>   Toggle marks: marked files become unmarked, and vice versa.
>>   Flagged files (indicated with flags such as ‘C’ and ‘D’, not
>>   with ‘*’) are not affected, and ‘.’ and ‘..’ are never toggled.
>> 
>> would that prevent the confusion?
>
> No, that's worse.  It introduces `C' as a "flag".
> "Flag" and "flagging" need to be reserved for `D'.
>
> It should always be about "flagging for deletion".
> This is important because deletion is consequential.
> That's presumably the reason for having always used
> a special term for `D' marks.
>
> "Flag", in the Dired context, is like a red flag --
> a warning, of sorts: "Pay attention! This marking
> is particularly important."  That's also the reason
> we font-lock `D'-marked lines specially (red!).
>
> It would probably help if the first line of the
> doc string explicitly called out `*' marks.
> Maybe something like this:
>
>   Toggle `*' marks: unmark marked files, and vice versa.
So people are supposed to keep in their mind all this distinction when
it is a flag and when it is a mark? So we are supposed to "flag" for
deletion, but "mark" for copy. Is it really necessary? Does it really
need to be that complicated, I mean, cognitively speaking? Does it
really add anything in quality if you distinct between "marking" and
"flagging" for deletion? What is wrong to just simply "mark" files
with different "flags"? 

I am not native english speaker, but it feels I could equally "flag"
and "mark" my files for deletion.




This bug report was last modified 5 years and 86 days ago.

Previous Next


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