bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41097: 28.0.50; (dired-toggle-marks) not working after copy


From: Drew Adams
Subject: bug#41097: 28.0.50; (dired-toggle-marks) not working after copy
Date: Sun, 10 May 2020 09:26:01 -0700 (PDT)

> > 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]