unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Arthur Miller <arthur.miller@live.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: michael_heerdegen@web.de, 41097@debbugs.gnu.org,
	tomasn@posteo.net, Jean Louis <bugs@gnu.support>
Subject: bug#41097: 28.0.50; (dired-toggle-marks) not working after copy
Date: Mon, 11 May 2020 15:15:57 +0200	[thread overview]
Message-ID: <VI1PR06MB4526DA5422AD163FF28588D296A10@VI1PR06MB4526.eurprd06.prod.outlook.com> (raw)
In-Reply-To: <7979fef4-5df8-4997-95fd-c5be5887ab44@default> (Drew Adams's message of "Sun, 10 May 2020 09:26:01 -0700 (PDT)")

Drew Adams <drew.adams@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.





  parent reply	other threads:[~2020-05-11 13:15 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-05 15:01 bug#41097: 28.0.50; (dired-toggle-marks) not working after copy Jean Louis
2020-05-06 14:05 ` Arthur Miller
2020-05-06 14:44   ` Jean Louis
2020-05-08  9:05     ` Arthur Miller
2020-05-08 13:29       ` Jean Louis
2020-05-09  0:25         ` Michael Heerdegen
2020-05-09  1:50           ` Drew Adams
2020-05-09  5:22             ` Michael Heerdegen
2020-05-09  4:23           ` Jean Louis
2020-05-10  1:11             ` Michael Heerdegen
2020-05-10  5:00               ` Jean Louis
2020-05-10  9:25             ` Tomas Nordin
2020-05-10  9:56               ` Jean Louis
2020-05-10 14:07                 ` Eli Zaretskii
2020-05-10 14:55                   ` Jean Louis
2020-05-10 15:11                     ` Eli Zaretskii
2020-05-10 15:33                       ` Jean Louis
2020-05-10 16:05                         ` Eli Zaretskii
2020-05-10 16:29                           ` Drew Adams
2020-05-10 16:40                             ` Eli Zaretskii
2020-05-10 17:17                           ` Jean Louis
2020-05-10 17:19                             ` Eli Zaretskii
2020-05-10 16:26                       ` Drew Adams
2020-05-10 17:32                         ` Jean Louis
2020-05-11  0:36                         ` Michael Heerdegen
2020-05-11  2:33                           ` Drew Adams
2020-05-11  5:34                             ` Michael Heerdegen
2020-05-11 16:18                               ` Drew Adams
2020-05-11 13:15                         ` Arthur Miller [this message]
2020-05-11 16:41                           ` Drew Adams
     [not found] <<20200506144423.GW24998@protected.rcdrun.com>
     [not found] ` <<VI1PR06MB452640273F3311C283C50B5F96A20@VI1PR06MB4526.eurprd06.prod.outlook.com>
     [not found]   ` <<20200508132924.GI14650@protected.rcdrun.com>
     [not found]     ` <<87r1vukl86.fsf@web.de>
     [not found]       ` <<20200509042353.GA15309@protected.rcdrun.com>
     [not found]         ` <<87h7wonnuh.fsf@fliptop.i-did-not-set--mail-host-address--so-tickle-me>
     [not found]           ` <<20200510095646.GA22962@protected.rcdrun.com>
     [not found]             ` <<83y2pzdgt7.fsf@gnu.org>
     [not found]               ` <<20200510145503.GE28606@protected.rcdrun.com>
     [not found]                 ` <<83sgg7ddtz.fsf@gnu.org>
     [not found]                   ` <<20200510153311.GH28606@protected.rcdrun.com>
     [not found]                     ` <<83r1vrdbc0.fsf@gnu.org>
     [not found]                       ` <<6bc132d3-2d2d-4eb3-86dd-b818c1b856a2@default>
     [not found]                         ` <<83mu6fd9q6.fsf@gnu.org>
2020-05-10 16:46                           ` Drew Adams
2020-05-10 17:10                             ` Eli Zaretskii
     [not found] <<<20200506144423.GW24998@protected.rcdrun.com>
     [not found] ` <<<VI1PR06MB452640273F3311C283C50B5F96A20@VI1PR06MB4526.eurprd06.prod.outlook.com>
     [not found]   ` <<<20200508132924.GI14650@protected.rcdrun.com>
     [not found]     ` <<<87r1vukl86.fsf@web.de>
     [not found]       ` <<<20200509042353.GA15309@protected.rcdrun.com>
     [not found]         ` <<<87h7wonnuh.fsf@fliptop.i-did-not-set--mail-host-address--so-tickle-me>
     [not found]           ` <<<20200510095646.GA22962@protected.rcdrun.com>
     [not found]             ` <<<83y2pzdgt7.fsf@gnu.org>
     [not found]               ` <<<20200510145503.GE28606@protected.rcdrun.com>
     [not found]                 ` <<<83sgg7ddtz.fsf@gnu.org>
     [not found]                   ` <<<20200510153311.GH28606@protected.rcdrun.com>
     [not found]                     ` <<<83r1vrdbc0.fsf@gnu.org>
     [not found]                       ` <<<6bc132d3-2d2d-4eb3-86dd-b818c1b856a2@default>
     [not found]                         ` <<<83mu6fd9q6.fsf@gnu.org>
     [not found]                           ` <<af1d7797-47c1-4330-a767-7b4a2773fbac@default>
     [not found]                             ` <<83k11jd8bs.fsf@gnu.org>
2020-05-10 19:18                               ` Drew Adams
2020-05-10 19:54                                 ` Jean Louis
2020-05-10 21:13                                   ` Drew Adams
2020-05-11  5:26                                     ` Jean Louis
2020-05-11 16:03                                       ` Drew Adams
2020-05-11 16:58                                         ` Jean Louis
2020-05-11 17:45                                           ` Drew Adams
2020-05-20  6:37                                             ` Jean Louis
2020-05-20 16:52                                               ` Drew Adams
2020-05-20 17:08                                                 ` Robert Pluim
2020-05-12  3:21                                       ` Richard Stallman

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=VI1PR06MB4526DA5422AD163FF28588D296A10@VI1PR06MB4526.eurprd06.prod.outlook.com \
    --to=arthur.miller@live.com \
    --cc=41097@debbugs.gnu.org \
    --cc=bugs@gnu.support \
    --cc=drew.adams@oracle.com \
    --cc=michael_heerdegen@web.de \
    --cc=tomasn@posteo.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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).