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

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

[Drew Adams]

> > > Thanks, I installed this on the release branch.
> > > OK to close the bug now?
> >
> > That "fix" is a real step backward, not forward.
> 
> I disagree.

Please reconsider.

Can you point to any other occurrence of referring
to some mark other than `D' as a "flag" - anywhere
in the Dired doc or code?  All marks, including
`D', are marks.  Only `D' is called "flag".

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

[Eli Zaretskii]

> Date: Sun, 10 May 2020 09:46:56 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: bugs@gnu.support, michael_heerdegen@web.de, tomasn@posteo.net,
>         41097@debbugs.gnu.org, arthur.miller@live.com
> 
> > > That "fix" is a real step backward, not forward.
> > 
> > I disagree.
> 
> Please reconsider.

Done.

> Can you point to any other occurrence of referring
> to some mark other than `D' as a "flag" - anywhere
> in the Dired doc or code?  All marks, including
> `D', are marks.  Only `D' is called "flag".

"Flag" is just a word.

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

[Drew Adams]

> > Please reconsider.
> 
> Done.
> 
> > Can you point to any other occurrence of referring
> > to some mark other than `D' as a "flag" - anywhere
> > in the Dired doc or code?  All marks, including
> > `D', are marks.  Only `D' is called "flag".
> 
> "Flag" is just a word.

So is "mark".  What is your point?  Only `D' has
been called a flag by Emacs, until now.

Dired actions affect marks differently, depending
on the mark.  There are 3 kinds of actions - 3
groups of marks:

1. Actions that affect only mark `*'.
2. Actions that affect only mark `D'.
3. Actions that affect all marks (including
   `*' and `D').

By "affect" I mean either act on a file line that
has such a mark or add such a mark to a file line.

How to refer to these actions, these groups
of marks?  Up until your change:

1. Emacs has always referred to #1 as "mark",
   not making specific mention that only `*'
   is affected.  This is the most common kind of
   action and the most common kind of mark used.

2. Emacs has always, everywhere, referred ONLY
   to #2 as "flag", including the specific action
   of UNflagging as "unflag".  That said, see #3.

3. Emacs has always, for actions that affect ALL
   marks or ANY mark (including `D' and `*'),
   referred to #3 as "mark".

Could Emacs have spoken differently?
Yes, here's a possibility (not taken by Emacs):

1. Refer ONLY to #1 (`*') as "mark".

2. Refer to #2 as "flag `D'", "flag for deletion".

3. Refer to #3 as "marks and flags" and "mark
   or flag", and point out specifically that `C',
   `D', etc. are "flags", whereas `*' is the only
   "mark".

Either of those approaches, the one Emacs has
used or the other, is doable, reasonable.

But what you've done is instead inconsistent.
In a single doc string you've changed the
terminology, to refer to `C' as a "flag".  No
such change for other non-`*' marks.

That means that doc for #3 is not only wrong
but self-contradictory, as it still talks about
the existence of multiple kinds of "mark" -
different characters.

You say you've reconsidered.  I'd ask that you
reconsider again.  And please elaborate on your
"'Flag' is just a word" response to my question:

  Can you point to any other occurrence of
  referring to some mark other than `D' as a
  "flag" - anywhere in the Dired doc or code?  

That's not a rhetorical question.  I know of
no such occurrence.  Do you?  I think what I've
said above is correct, regarding #1, #2, #3.

Words matter.  I gave a reason why I think
Emacs chose to use "flag" for `D' - and only
for `D': to flag something is to draw special
attention to it.

Your change works against that.  If `C' is now
referred to as a "flag" then `D' isn't special
in that regard. Users can conclude that all
marks except `*' are now "flags".

Note, BTW, that mark `R' is handled the way
mark `C' is handled.  It comes from rename
operations.  Likewise, `H' (new hard links)
and `Y' (new soft links).

And each of those cases (copy, rename, hard
link, soft link) has a user option that you
can set to `t' to cause the target to be
marked not with the default mark (`C' etc.)
but with whatever mark the source file had.

And the doc for each of those options talks
about "marks" and "marking", not "flags" and
"flagging".  The doc for `dired-del-marker',
on the other hand, says "flag", exceptionally.

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

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2020-05-10 22:23]:
> > > Please reconsider.
> > 
> > Done.
> > 
> > > Can you point to any other occurrence of referring
> > > to some mark other than `D' as a "flag" - anywhere
> > > in the Dired doc or code?  All marks, including
> > > `D', are marks.  Only `D' is called "flag".
> > 
> > "Flag" is just a word.
> 
> So is "mark".  What is your point?  Only `D' has
> been called a flag by Emacs, until now.
> 
> Dired actions affect marks differently, depending
> on the mark.  There are 3 kinds of actions - 3
> groups of marks:
> 
> 1. Actions that affect only mark `*'.
> 2. Actions that affect only mark `D'.
> 3. Actions that affect all marks (including
>    `*' and `D').
> 
> By "affect" I mean either act on a file line that
> has such a mark or add such a mark to a file line.
> 
> How to refer to these actions, these groups
> of marks?  Up until your change:
> 
> 1. Emacs has always referred to #1 as "mark",
>    not making specific mention that only `*'
>    is affected.  This is the most common kind of
>    action and the most common kind of mark used.
> 
> 2. Emacs has always, everywhere, referred ONLY
>    to #2 as "flag", including the specific action
>    of UNflagging as "unflag".  That said, see #3.
> 
> 3. Emacs has always, for actions that affect ALL
>    marks or ANY mark (including `D' and `*'),
>    referred to #3 as "mark".
> 
> Could Emacs have spoken differently?
> Yes, here's a possibility (not taken by Emacs):
> 
> 1. Refer ONLY to #1 (`*') as "mark".
> 
> 2. Refer to #2 as "flag `D'", "flag for deletion".
> 
> 3. Refer to #3 as "marks and flags" and "mark
>    or flag", and point out specifically that `C',
>    `D', etc. are "flags", whereas `*' is the only
>    "mark".
> 
> Either of those approaches, the one Emacs has
> used or the other, is doable, reasonable.
> 
> But what you've done is instead inconsistent.
> In a single doc string you've changed the
> terminology, to refer to `C' as a "flag".  No
> such change for other non-`*' marks.
> 
> That means that doc for #3 is not only wrong
> but self-contradictory, as it still talks about
> the existence of multiple kinds of "mark" -
> different characters.
> 
> You say you've reconsidered.  I'd ask that you
> reconsider again.  And please elaborate on your
> "'Flag' is just a word" response to my question:
> 
>   Can you point to any other occurrence of
>   referring to some mark other than `D' as a
>   "flag" - anywhere in the Dired doc or code?  
> 
> That's not a rhetorical question.  I know of
> no such occurrence.  Do you?  I think what I've
> said above is correct, regarding #1, #2, #3.
> 
> Words matter.  I gave a reason why I think
> Emacs chose to use "flag" for `D' - and only
> for `D': to flag something is to draw special
> attention to it.

Your are rights that word matters. Then if I may ask, why is then
"flag" introduced instead of "Delete mark"?

How "flag" makes the deleting action more clear? It does not, if you
ask me.

Definition of a mark is very clear.

Wordnet:

2. (4) marker, marking, mark -- (a distinguishing symbol; "the owner's
mark was on all the sheep")

flag on the other hand is not so clear. It does not provide definition
for your intended action to draw special attention to it.

In fact, marking something is drawing special attention to it
already.

So "flag" is for me less clear. Why should "flag" be used for
"delete", why not "Delete" or "Mark delete"?

Now note that the option "flag" is under the menu "Mark", so flag is a
mark, it is adding to confusion.

In my opinion, the Menu "Mark" should not have "flag", but rather
"Delete" or "Delete mark":

- Delete auto-save files
- Delete backup files
- Delete garbage files
- Delete by extension

or

- Mark to delete auto-save files
- Mark to delete backup files
- Mark to delete garbage files
- Mark to delete by extension

Those are clear to me in that sense.

Now these are not clear to me:

- Flag extension -- how that can be clear what it does? Sure that I
  will find after some time what is meant, but I am saying, it is
  confusing and not user friendly.

The Wordnet does not indicate that "flag" has the definition that you
want, in the manner to distinguish it from "mark". It says "provide
with a flag" and flag would be what?

I will just put those definitions here down that could apply for some
user. 

From WordNet (r) 3.0 (2006) [wn]:

  flag
      n 1: emblem usually consisting of a rectangular piece of cloth
           of distinctive design

4: a rectangular piece of fabric used as a signalling device
         [syn: {flag}, {signal flag}]
      2: provide with a flag; "Flag this file so that I can recognize
         it immediately"

      5: become less intense [syn: {ease up}, {ease off}, {slacken
         off}, {flag}]

So to flag in the meaning to provide with a flag, the Wordnet
definition gives me only that, thus definitions are missing. I
understand your point, I am just saying is not so easy to understand with
"flag".

With "mark" it is very easy to understand it:

mark

1 definition found

From WordNet (r) 3.0 (2006) [wn]:

  mark
      2: a distinguishing symbol; "the owner's mark was on all the
         sheep" [syn: {marker}, {marking}, {mark}]

    v 1: attach a tag or label to; "label these bottles" [syn:
           {tag}, {label}, {mark}]

      5: make or leave a mark on; "the scouts marked the trail"; "ash
         marked the believers' foreheads"


Now the definition you wanted to squeeze out of the "flag" to draw
special attention to it, is actually under "mark" -- I speak only for
Wordnet.

to flag vs. to mark, those are synonyms.

It is only in Emacs terminology that "flag" became something extra,
however, it does not help the user to understand by reading from the
menu that "flag" means "to mark for deletion".

Jean

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

[Drew Adams]

> > Words matter.  I gave a reason why I think
> > Emacs chose to use "flag" for `D' - and only
> > for `D':
> > to flag something is to draw special attention
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > to it.
> 
> Your are rights that word matters. Then if I may ask, why is then
> "flag" introduced instead of "Delete mark"?

I said what I _think_ is the reason "flag" was
used for `D' (and ONLY for `D') - see above.

https://en.wiktionary.org/wiki/flag#Verb:

 "To mark with a flag, especially to indicate the
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^
  importance of something."
  ^^^^^^^^^^

Not just to indicate something - to point it out -
but to point it out as being of special importance.

In this sense, and especially when used in contrast
to "mark", it means to mark _specially_, i.e., more
than the way other Dired marks mark.

Emacs has always treated `D' _uniquely_, by giving
it a different term ("flag").  And my _hypothesis_
(which I expressed) is that this is because `D' can
cause problems - data loss - if you don't pay
special attention to it.  

I can't speak authoritatively about the reason this
was done - I didn't decide it.  It was done decades
ago.

> How "flag" makes the deleting action more clear? It does not, if you
> ask me.

Ask whomever wrote Dired and maintained it for 35
years.

It may not make "the deleting action" more clear,
especially to someone for whom English is not the
first language.  Both "mark" and "flag" point
something out - that's true.

But the fact that ONLY `D' is referred to as a
"flag", and only it (not `C' or any other mark)
is referred to as "flagging" the file for the
given action, should draw _special_ attention to
it  - should flag it (!) as being of particular
importance or meriting special attention.

Maybe this will help a bit (maybe not): the
English verb "flag" translates to French as
"signaler".  The verb "mark" translates as
"indiquer" or "marquer".  Now do you see the
difference?

They're related, but signaler is generally more
active, more important, more urgent.  Signaler
means you're really trying to get someone's
attention; you're not just indicating something.

> 2. (4) marker, marking, mark -- (a distinguishing symbol; "the owner's
> mark was on all the sheep")
> 
> flag on the other hand is not so clear. It does not provide definition
> for your intended action to draw special attention to it.

Yes, it does.  See above, or try another dictionary.

> In fact, marking something is drawing special attention to it
> already.

Yes, it's true that marking and flagging both
draw attention to something.  But "flag" is a
bit stronger, especially if both are used in
the same context (e.g. Dired), but for different
things, and especially if the thing "flag" is
used for (file deletion) is more serious.

In any case, your argument is not with me.  It's
not I who chose "flag".  My point is only that
that's what Emacs does and has always done, and
Emacs is quite consistent about it.

See my previous mail.  If someone (e.g. you)
proposed to use only "mark" and never "flag", that
would be OK.

What's not OK, IMO, is to use both, but not use
them in a consistent way.  After Eli's change, we
now have 2, and only 2, marks (`D' and `C') which
we are calling "flags".

It could be argued that there's something special
about deleting.  It's hard to argue that there's
something special about copying and deleting (as
opposed to renaming/moving and linking).

> So "flag" is for me less clear. Why should "flag" be used for
> "delete", why not "Delete" or "Mark delete"?

See above.

> Now note that the option "flag" is under the menu "Mark", so flag is a
> mark, it is adding to confusion.

It's in menu `Mark' because it is about marking,
in general - flagging is a kind of marking.  But
`Flag' is a separate menu item from `Mark'.

That item could have been called `Mark for
Deletion'.  But it wasn't.  Emacs consistently
uses "flag" for deletion - and only for deletion.

In the case of the `Mark' menu, that makes each
of the `Flag' items stand out from the `Mark'
items.  And rightfully so, as they all use `D'.
They're all for deleting files - something to
pay attention to.

Would you have preferred this?

 Mark
 Unmark
 Mark for Deletion
 Mark Auto-save Files for Deletion
 Mark Backup Files for Deletion
 Mark Garbage Files for Deletion
 Mark Executables
 Mark Old Backups
 Mark Directories
 Mark Symlinks
 Unmark All
 Change Marks...

That would have been OK, if a bit noisier and
less readable.  Again, I'm not the one who
decided such things (long, long ago).

> In my opinion, the Menu "Mark" should not have "flag", but rather
> "Delete" or "Delete mark":
> 
> - Delete auto-save files
> - Delete backup files
> - Delete garbage files
> - Delete by extension

Not good.  The action is NOT to delete
anything.  That's part of the point.  This
menu is only about marking various things
in various ways.  It makes no changes to
files or the file system.  The "flag" items
are about deleting, but deleting is not
their action.

> or
> 
> - Mark to delete auto-save files
> - Mark to delete backup files
> - Mark to delete garbage files
> - Mark to delete by extension
> 
> Those are clear to me in that sense.

OK.  Maybe file an enhancement request for
that.  I disagree that that's better, but
I'm just one (other) user. 

> Now these are not clear to me:
> 
> - Flag extension -- how that can be clear what it does? Sure that I
>   will find after some time what is meant, but I am saying, it is
>   confusing and not user friendly.
> 
> The Wordnet does not indicate that "flag" has the definition that you
> want, in the manner to distinguish it from "mark". It says "provide
> with a flag" and flag would be what?

See above.  It's English.  If it's not
understandable to some people then that's
not great.  But keep in mind that it is a
common verb, and Dired has used it this way
for decades (and Emacs has had lots of users
for whom English is not the first language).

> I will just put those definitions here down that could apply for some
> user...

I know what "flag" means.

> So to flag in the meaning to provide with a flag, the Wordnet
> definition gives me only that

Try another dictionary.  Ask (another) native
English speaker.

But the point is not that "flag" means what I
pointed out.  It's important that users can
understand what's meant.  So maybe someone
(else) will agree to make a _wholesale_ change
to all of the Dired descriptions, to never use
"flag".

Unless/until that happens, with Eli's change
we have now moved from something consistent to
something inconsistent.

> I am just saying is not so easy to understand
> with "flag".
> With "mark" it is very easy to understand it:
> 
> Now the definition you wanted to squeeze out of the "flag" to draw
> special attention to it, is actually under "mark" -- I speak only for
> Wordnet. ...
> 
> to flag vs. to mark, those are synonyms.

They are synonyms to some extent, in some
contexts.

Two different words are never completely
synonymous. There are always some different
connotations - nuances.

> It is only in Emacs terminology that "flag" became something extra,

No, it is not only in Emacs.  Please look
beyond Wordnet or, as I say, talk to another
native English speaker about it.

> however, it does not help the user to understand by reading from the
> menu that "flag" means "to mark for deletion".

I hear you.  Someone else can decide whether to
remove all use of "flag" from Dired because this
was unclear to you.  I have no problem with that,
even though I think it would be ill-advised.

What is not good is the inconsistency that was
just introduced.  But that's not the end of the
world - it's just one small step backward.

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

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2020-05-11 00:16]:
> > > Words matter.  I gave a reason why I think
> > > Emacs chose to use "flag" for `D' - and only
> > > for `D':
> > > to flag something is to draw special attention
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > to it.
> > 
> > Your are rights that word matters. Then if I may ask, why is then
> > "flag" introduced instead of "Delete mark"?
> 
> I said what I _think_ is the reason "flag" was
> used for `D' (and ONLY for `D') - see above.
> 
> https://en.wiktionary.org/wiki/flag#Verb:
> 
>  "To mark with a flag, especially to indicate the
>                        ^^^^^^^^^^^^^^^^^^^^^^^^^^
>   importance of something."
>   ^^^^^^^^^^
> 
> Not just to indicate something - to point it out -
> but to point it out as being of special importance.
> 
> In this sense, and especially when used in contrast
> to "mark", it means to mark _specially_, i.e., more
> than the way other Dired marks mark.

I found the definition in the Merriam Webster, thank you, that is
right, to flag means to mark it to attract attention.

Attracting attention only relates to deletion in Emacs. But the logics
is individual in my opinion. For example I like to mark files so that
they are renamed or copied, and that is what matters to me, that is
where I need my attention.

On files marked for deletion, I have less attention, well, why?
Because the files are marked for deletion, they are less
important. Even if I by accident remove the D flag, it does not
matter, as those files are less important.

So to use "flag" for "Mark for deletion" in my individual case is not
same meaning and is not marking for attention.

> > How "flag" makes the deleting action more clear? It does not, if you
> > ask me.
> 
> Ask whomever wrote Dired and maintained it for 35
> years.
> 
> It may not make "the deleting action" more clear,
> especially to someone for whom English is not the
> first language.  Both "mark" and "flag" point
> something out - that's true.

The meaning of "to mark with special attention" is not synonym to "to
mark for deletion". The menu items like "Mark -> Flag" is
ambiguous.

You pointed out yourself to the definition of the "to flag" -- and
there is one good on Merriam-Webster too, so none of those definitons
are saying that "flagging" is equivalent to "marking for deletion",
they are saying that there is some special mark, not which one. 

> But the fact that ONLY `D' is referred to as a
> "flag", and only it (not `C' or any other mark)
> is referred to as "flagging" the file for the
> given action, should draw _special_ attention to
> it  - should flag it (!) as being of particular
> importance or meriting special attention.

From a viewpoint of user-friendly menus, I don't think that
introduction of a "flag" with special meaning only in Emacs is helping
users. 

> In any case, your argument is not with me.  It's
> not I who chose "flag".  My point is only that
> that's what Emacs does and has always done, and
> Emacs is quite consistent about it.

I am reading quote from the Emacs manual:

‘x’
     Delete files flagged for deletion (‘dired-do-flagged-delete’).

This could mean that there can be other flags, not only `D' because
`x' is deleting files flagged for deletion, and that could, from
viewpoint of a user, imply that there are other flags, not only for
deletion.

To summarize, for me, the manual is pretty clear, and user menu "Mark"
is not intuitively clear, as without reading the manual one cannot
know what means "Flag".

> What's not OK, IMO, is to use both, but not use
> them in a consistent way.  After Eli's change, we
> now have 2, and only 2, marks (`D' and `C') which
> we are calling "flags".

dired-toggle-marks is an interactive compiled Lisp function in
‘dired.el’.

(dired-toggle-marks)

Toggle marks: marked files become unmarked, and vice versa.
Files marked with other flags (such as ‘D’) are not affected.
‘.’ and ‘..’ are never toggled.
As always, hidden subdirs are not affected.

The inconsistency is already in that documentation:

- "marked with other flags (such as 'D')" implies that the C is also
  flag.

Isn't that already inconsistency?

> It could be argued that there's something special
> about deleting.  It's hard to argue that there's
> something special about copying and deleting (as
> opposed to renaming/moving and linking).

You look individually, for your own needs. For me the files marked for
deletion are not special, they are less special, well they go to
"trash", right?

Those files which have to be copied or marked for processing, are for
me special files. And I use * mark for that as it is offered so. So
most important marks, which require special attention are never "D"
files, but those marked with "m", the marked files with "*".

> Would you have preferred this?
> 
>  Mark
>  Unmark
>  Mark for Deletion
>  Mark Auto-save Files for Deletion
>  Mark Backup Files for Deletion
>  Mark Garbage Files for Deletion
>  Mark Executables
>  Mark Old Backups
>  Mark Directories
>  Mark Symlinks
>  Unmark All
>  Change Marks...
> 
> That would have been OK, if a bit noisier and
> less readable.  Again, I'm not the one who
> decided such things (long, long ago).

That looks logical and understandable, it removes the ambiguity from
the menu "Mark" and becomes user friendly. And I guess it would remove
manual sections that are trying to explain the difference between
flagging and marking too.

If there would be clear English definition of "to flag" that it means
"to mark for deletion", there would be no difference to introduce new
special Emacs definition to tell users what flagging means. I am not
against new definitions of words, I am just saying how I see that from
viewpoint of a user. User in the first place, is not reading the
manual, and what if manual is not distributed together with the emacs?

> > Now these are not clear to me:
> > 
> > - Flag extension -- how that can be clear what it does? Sure that I
> >   will find after some time what is meant, but I am saying, it is
> >   confusing and not user friendly.
> > 
> > The Wordnet does not indicate that "flag" has the definition that you
> > want, in the manner to distinguish it from "mark". It says "provide
> > with a flag" and flag would be what?
> 
> See above.  It's English.  If it's not
> understandable to some people then that's
> not great.  But keep in mind that it is a
> common verb, and Dired has used it this way
> for decades (and Emacs has had lots of users
> for whom English is not the first language).

I am saying it only from user friendly view point. Myself I have
marked extension many times.

The menu "Flag extension" is not clear because if all others become
clear that "to flag" means "to mark for deletion", then "mark
extension" would mean "to mark extension for deletion".

That menu item should be "Flag by extension" and not "Flag extension",
because rarely somebody wish to "mark extension for deletion". 

If Dired and Emacs used it for decades, that does not necessarily mean
that menu items are clear and user friendly. Menu item need not be
short, some probably less important menu items are very long like "Use
directory names in bufer names" is pretty long and is there all the time.

Jean

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

[Drew Adams]

> (dired-toggle-marks)
> 
> Toggle marks: marked files become unmarked, and vice versa.
> Files marked with other flags (such as ‘D’) are not affected.
> ‘.’ and ‘..’ are never toggled.
> As always, hidden subdirs are not affected.
> 
> The inconsistency is already in that documentation:
> 
> - "marked with other flags (such as 'D')" implies that the C is also
>   flag.
> 
> Isn't that already inconsistency?

Yes, agreed.  It should say something like "marked with
a character other than `*'".

> > It could be argued that there's something special
> > about deleting.  It's hard to argue that there's
> > something special about copying and deleting (as
> > opposed to renaming/moving and linking).
> 
> You look individually, for your own needs. For me the files marked for
> deletion are not special, they are less special, well they go to
> "trash", right?

When you delete files they go to trash only if option
`delete-by-moving-to-trash' is non-nil.  Its default
value is `nil'.

But yes, any individual can feel that something else
is more important or worrisome than file deletion.

The default behavior of Emacs, and the way Emacs
speaks about itself, is decided by the Emacs
developers, not you or I or any particular individual
user.  It's a judgment call.  And sometimes some users
don't agree with some of the judgment calls.  We can
file bug/enhancement reports or chime in on mailing
list discussions or speak up in other ways.

But ultimately someone has to decide/judge.  As
individuals we don't always get what we want.

In the case at hand, someone decided that marking
for file deletion is more worth signaling that other
marking for other operations.  I, for one, am fine
with that decision.  You apparently are not.  What's
important is that the doc and UI are clear about the
behavior, so all users know what to expect.

> Those files which have to be copied or marked for processing, are for
> me special files. And I use * mark for that as it is offered so. So
> most important marks, which require special attention are never "D"
> files, but those marked with "m", the marked files with "*".

OK.

> The menu "Flag extension" is not clear because if all others become
> clear that "to flag" means "to mark for deletion", then "mark
                                                           ^^^^
> extension" would mean "to mark extension for deletion".

Did you mean "flag", not "mark", after "then"?

> That menu item should be "Flag by extension" and not "Flag extension",
> because rarely somebody wish to "mark extension for deletion".

OK by me.  File a bug report.

> If Dired and Emacs used it for decades, that does not necessarily mean
> that menu items are clear and user friendly. Menu item need not be
> short, some probably less important menu items are very long like "Use
> directory names in bufer names" is pretty long and is there all the
> time.

Agreed.  Lots of Emacs menu items could use more love.

FWIW:

I've made quite a few changes to Dired menus in my own
code (Dired+).  For one thing, I've separated flagging
for deletion from marking otherwise, and I've separated
unmarking from both: menus `Flag', `Mark', and `Unmark'.
And each of those menus has more items.  And each of them
is a submenu of menu `Marks' (flags are marks).

https://www.emacswiki.org/emacs/DiredPlus#MarksMenu
___


You'll note, BTW, that some commands that act on marks
act on all marks, including `D' flags, whereas other
commands act only on `*' marks.  For example, `M-}'
(`dired-next-marked-file') moves to the next mark, of
any kind.

This is why, although it's OK for a command such as
`dired-toggle-marks' (`t') to be named as it is, its
doc should make clear that it acts only on `*' marks.
That's the fix needed for this bug: better doc for `t'.

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

[Jean Louis]

> In the case at hand, someone decided that marking
> for file deletion is more worth signaling that other
> marking for other operations.  I, for one, am fine
> with that decision.  You apparently are not.  What's
> important is that the doc and UI are clear about the
> behavior, so all users know what to expect.

I can adapt myself. I love how Emacs is created and many people
participated and participate in its creation and improvements. I am
myself alright, and I am also alright with many new things to learn
in Emacs. Just looking from a new user perspective, it is still my own
viewpoint with addition of my opinion how new user looks at it.

I have used Emacs since 1999. For many years I have not even been
aware of Dired. I have delivered computer courses back in
1990-1992. And I have delivered few GNU free software seminars in
Germany. And all the time I have been using mostly Rox file manager of
Midnight Commander, in the shell. I was not aware of dired, not at
all. Emacs was for editing.

If I open a file, where in the Tools says "File manager" -- but it
should in my opinion. It is just in recent years that I became heavy
user of dired, as I have extended my personal use to varieties that I
could not implement in any other file manager.

I am old but new user. So for me it was not easily accessible to
discover Dired in so many years. And I program myself all the last 21
years.

File menu has no such "File manager" menu. Of course I know today that
I can open directory and I am in dired, but I was opening directory
even before, and I did not know that I am in dired, all I knew is that
I can open file for editing, that is what I knew.

That is one example.

Unspoken from the fact that I can use Emacs similar to the shell, as
the main window to all of my computing needs. Nobody explained me
that, I had to discover it myself and understand what other people are
speaking about it. That I find so powerful. 

> FWIW:
> 
> I've made quite a few changes to Dired menus in my own
> code (Dired+).  For one thing, I've separated flagging
> for deletion from marking otherwise, and I've separated
> unmarking from both: menus `Flag', `Mark', and `Unmark'.
> And each of those menus has more items.  And each of them
> is a submenu of menu `Marks' (flags are marks).
> 
> https://www.emacswiki.org/emacs/DiredPlus#MarksMenu

I cannot find it in list-packages

Jean

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

[Drew Adams]

> [background info and some suggestions about menus]

> If I open a file, where in the Tools says "File manager" -- but it
> should in my opinion. ...
> 
> File menu has no such "File manager" menu. Of course I know today that
> I can open directory and I am in dired, but I was opening directory
> even before, and I did not know that I am in dired, all I knew is that
> I can open file for editing, that is what I knew.

I suggest that you use `M-x report-emacs-bug' for
such requests.  That's for enhancement requests as
well as for bug reports.  Saying it here instead
is OK for our info, but it won't be tracked, and
likely won't be followed up as an actual request.

> > I've made quite a few changes to Dired menus in my own
> > code (Dired+).  For one thing, I've separated flagging
> > for deletion from marking otherwise, and I've separated
> > unmarking from both: menus `Flag', `Mark', and `Unmark'.
> > And each of those menus has more items.  And each of them
> > is a submenu of menu `Marks' (flags are marks).
> >
> >
> https://urldefense.com/v3/__https://www.emacswiki.org/emacs/DiredPlus*M
> arksMenu__;Iw!!GqivPVa7Brio!MasXZpDxN0Aqh653P0X2J9UzdtMsJllJnv6FUOk4cNg
> jhclIcRl0zc9F-NvSkDT9$
> 
> I cannot find it in list-packages

There's no package for it.  It's a standalone
Lisp library.

If you want to try it:

At the top of that Dired+ web page you see a link
to the library, `dired+.el'.  Here's its URL:

https://www.emacswiki.org/emacs/dired%2b.el

The Download button there has this URL:

https://www.emacswiki.org/emacs/download/dired%2b.el

Just download it, byte-compile it (optional,
recommended), and load it.

To byte-compile it: `B' in Dired on its line.

To load it: `L' in Dired on its line (or the
dired+.elc line, after byte-compiling it).

To load it systematically, from your init file,
you can put the file's location in your `load-path'
and then put `(require 'dired+)' in your init file.

(Or you can build an autoloads file for it using
`update-file-autoloads', then load that from your
init file.)

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

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2020-05-11 20:46]:
> If you want to try it:
> 
> At the top of that Dired+ web page you see a link
> to the library, `dired+.el'.  Here's its URL:
> 
> https://www.emacswiki.org/emacs/dired%2b.el
> 
> The Download button there has this URL:
> 
> https://www.emacswiki.org/emacs/download/dired%2b.el

It is useful, thank you.

And why not include some of those functions in Emacs? Can you send it
to Emacs to be included?

Jean

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

[Drew Adams]

> And why not include some of those functions in Emacs? Can you send it
> to Emacs to be included?

I've offered all of its code to Emacs many times.
And in the past I've suggested certain parts in
particular, and sometimes submitted patches.

The only such change I recall being accepted was
to highlight `w' for writable permission in group
and other columns.  And the face for that by
default is `default', which means that to get the
highlighting you have to know that face exists
and customize it.

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

[Robert Pluim]

>>>>> On Wed, 20 May 2020 09:52:54 -0700 (PDT), Drew Adams <drew.adams@oracle.com> said:

    >> And why not include some of those functions in Emacs? Can you send it
    >> to Emacs to be included?

    Drew> I've offered all of its code to Emacs many times.
    Drew> And in the past I've suggested certain parts in
    Drew> particular, and sometimes submitted patches.

If you set things up so you have commit access, then the need to
offer patches is much reduced.

Robert

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I found the definition in the Merriam Webster, thank you, that is
  > right, to flag means to mark it to attract attention.

Since deleting a file is the most drastic thing Dired can do to it,
I think it is reasonable to use "flag" to mean "mark for deletion."

Since we are dicussing so many questions, let's leave this alone
so as to avoid the need to discuss it.



-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Jean Louis]

I have observed that after the copy of files from one window to another,
the `t' for (dired-toggle-marks) is not working in that other window,
where files are copied.

If I kill the window, and enter into the directory again, than `t' for
(dired-toggle-marks) starts working again.

However, it is a bug.


In GNU Emacs 28.0.50 (build 8, x86_64-pc-linux-gnu, X toolkit, cairo version 1.14.8, Xaw3d scroll bars)
 of 2020-04-23 built on protected.rcdrun.com
Repository revision: 7b15cc3ebb45e50ac5faf3bbc2a813afffdaa418
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11907000
System Description: Hyperbola GNU/Linux-libre

Recent messages:
Copy: 3 files done
Quit
Making completion list...
Quit
<s-down> is undefined
Mark set [2 times]
Quit
Type "q" in help window to restore its previous buffer.
<s-up> is undefined
Mark set

Configured using:
 'configure --prefix=/package/text/emacs-2020-04-23 --with-modules
 --without-gpm --with-x-toolkit=lucid'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS JSON PDUMPER
LCMS2 GMP

Important settings:
  value of $LC_ALL: de_DE.UTF-8
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Dired by name

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort hashcash mail-extr help-fns radix-tree help-mode emacsbug
message rmc puny format-spec rfc822 mml easymenu mml-sec password-cache
epa derived epg epg-config gnus-util rmail rmail-loaddefs
text-property-search time-date subr-x seq byte-opt gv bytecomp
byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils dired-aux cl-loaddefs cl-lib dired
dired-loaddefs tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 51342 8472)
 (symbols 48 6377 1)
 (strings 32 17879 1682)
 (string-bytes 1 572018)
 (vectors 16 10849)
 (vector-slots 8 141765 12582)
 (floats 8 30 128)
 (intervals 56 609 0)
 (buffers 992 17))

-- 
Thanks,
Jean Louis

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

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> I have observed that after the copy of files from one window to another,
> the `t' for (dired-toggle-marks) is not working in that other window,
> where files are copied.
>
> If I kill the window, and enter into the directory again, than `t' for
> (dired-toggle-marks) starts working again.
>
> However, it is a bug.

I have 28.0.50 built on 27. april, and it works just fine for me. I use
Dired every day as my only file-manager. I just tested, and toggle
worked fine after copying a file between two directories (same drive and
partition). Marks on files are also preserved in other window after the
copy operation. I don't know if it helps.

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

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-05-06 17:05]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > I have observed that after the copy of files from one window to another,
> > the `t' for (dired-toggle-marks) is not working in that other window,
> > where files are copied.
> >
> > If I kill the window, and enter into the directory again, than `t' for
> > (dired-toggle-marks) starts working again.
> >
> > However, it is a bug.
> 
> I have 28.0.50 built on 27. april, and it works just fine for me. I use
> Dired every day as my only file-manager. I just tested, and toggle
> worked fine after copying a file between two directories (same drive and
> partition). Marks on files are also preserved in other window after the
> copy operation. I don't know if it helps.

With emacs -Q open dired, make one empty directory in other window,
mark file in first one, use C to copy to other, in the other window t
does not work to toggle marked files.

Jean

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

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> * Arthur Miller <arthur.miller@live.com> [2020-05-06 17:05]:
>> Jean Louis <bugs@gnu.support> writes:
>> 
>> > I have observed that after the copy of files from one window to another,
>> > the `t' for (dired-toggle-marks) is not working in that other window,
>> > where files are copied.
>> >
>> > If I kill the window, and enter into the directory again, than `t' for
>> > (dired-toggle-marks) starts working again.
>> >
>> > However, it is a bug.
>> 
>> I have 28.0.50 built on 27. april, and it works just fine for me. I use
>> Dired every day as my only file-manager. I just tested, and toggle
>> worked fine after copying a file between two directories (same drive and
>> partition). Marks on files are also preserved in other window after the
>> copy operation. I don't know if it helps.
>
> With emacs -Q open dired, make one empty directory in other window,
> mark file in first one, use C to copy to other, in the other window t
> does not work to toggle marked files.
>
> Jean

I didn what you said, but it worked fine for me.

One remark is that I don't see any pre-configured shortcut to use with
C-x 4 (operations on other window), so I created directory and switched
to other window. Besides that, I did what you said and it worked fine in
my Emacs started with -Q flag.

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

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-05-08 12:06]:
> I didn what you said, but it worked fine for me.
> 
> One remark is that I don't see any pre-configured shortcut to use with
> C-x 4 (operations on other window), so I created directory and switched
> to other window. Besides that, I did what you said and it worked fine in
> my Emacs started with -Q flag.

Ask somebody else to try. I am using latest git version from Emacs.

emacs -Q

C-x C-f to /tmp directory
C-x 3 to make 2 windows vertical
in other directory, make new directory like /tmp/new
create file in /tmp or choose any file with m, marking it
use C to copy to /tmp/new
C-x o to other window where file is copied, it has C mark
press t to toggle, it is not working

Compare it maybe to my lossage. I cannot know why is it happening and
if you are doing something different.

My lossage;

 C-x C-f		;; find-file
 C-a			;; move-beginning-of-line
 C-d			;; delete-char
 <return>		;; minibuffer-complete-and-exit
 C-x 3			;; split-window-right
 C-x o			;; other-window
 C-n			;; dired-next-line
 C-n			;; dired-next-line
 C-n			;; dired-next-line
 C-n			;; dired-next-line
 C-n			;; dired-next-line
 C-n			;; dired-next-line
 <return>		;; dired-find-file
 C-x o			;; other-window
 C-x o			;; other-window
 d			;; dired-flag-file-deletion
 x			;; dired-do-flagged-delete
 y			;; self-insert-command
 e			;; self-insert-command
 s			;; self-insert-command
 <return>		;; exit-minibuffer
 C-x o			;; other-window
 n			;; dired-next-line
 n			;; dired-next-line
 n			;; dired-next-line
 n			;; dired-next-line
 n			;; dired-next-line
 n			;; dired-next-line
 n			;; dired-next-line
 m			;; dired-mark
 C			;; dired-do-copy
 <return>		;; exit-minibuffer
 C			;; dired-do-copy
 n			;; self-insert-command
 e			;; self-insert-command
 <tab>			;; minibuffer-complete
 <return>		;; exit-minibuffer
 C-x o			;; other-window
 t			;; dired-toggle-marks
 <tab>			;; indent-for-tab-command
 C-e			;; move-end-of-line
 t			;; dired-toggle-marks
 t			;; dired-toggle-marks
 t			;; dired-toggle-marks
 t			;; dired-toggle-marks
 t			;; dired-toggle-marks
 M-x			;; execute-extended-command
 v			;; self-insert-command
 i			;; self-insert-command
 e			;; self-insert-command
 w			;; self-insert-command
 l			;; self-insert-command
 <backspace>		;; delete-backward-char
 -			;; self-insert-command
 l			;; self-insert-command
 o			;; self-insert-command
 s			;; self-insert-command
 <tab>			;; minibuffer-complete
 <return>		;; minibuffer-complete-and-exit

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

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> emacs -Q
>
> C-x C-f to /tmp directory
> C-x 3 to make 2 windows vertical
> in other directory, make new directory like /tmp/new
> create file in /tmp or choose any file with m, marking it
> use C to copy to /tmp/new
> C-x o to other window where file is copied, it has C mark
> press t to toggle, it is not working

Note that (docstring):

  "Files marked with other flags (such as ‘D’) are not affected."

You must unmark the copied files (the C mark) for toggling to have an
effect on them.  Is that your problem?

Michael.

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

[Drew Adams]

>   "Files marked with other flags (such as ‘D’) are not affected."

Yes.  Files marked with `C' are not affected.

If you want the copies to be marked with `*'
(instead of `C') in the target directory then
set or bind `dired-keep-marker-copy' to `t'
for the copy operation.  Otherwise the mark
used is `C'.

> You must unmark the copied files (the C mark)
> for toggling to have an effect on them.

You can.  But you need not unmark files that
are marked with another mark, if you want them
marked normally (or in some other way).

You can instead use `* c' to change marks of
one kind (e.g. `C') to marks of another kind
(e.g. `*').

The prompts for this use `read-char', so it is
very quick (no need to hit `RET').

This is an important feature, usable for more
than one purpose.  You can use it, for example,
to save a set of marks and then restore them
later, or to merge (union) multiple sets of
marks.

To save and restore: change `*' marks to some
new (unused) char, e.g. `+', and later change
the `+' marks back to `*'.
___

Dired has lots of handy things like this, some
of which are not known too well.  Another
handy one is `M-DEL' (aka `M-<backspace>').
It unmarks a particular mark (for all files
listed in the buffer).  Just hit `RET' to
remove all marks, of any kind.

(`RET' is read by `read-char', just like any
other char.  In this case, the char is Control-M,
aka carriage return.)

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

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> >   "Files marked with other flags (such as ‘D’) are not affected."
>
> Yes.  Files marked with `C' are not affected.
>
> If you want the copies to be marked with `*'
> (instead of `C') in the target directory then
> set or bind `dired-keep-marker-copy' to `t'
> for the copy operation.  Otherwise the mark
> used is `C'.
>
> > You must unmark the copied files (the C mark)
> > for toggling to have an effect on them.
>
> You can.  But you need not unmark files that
> are marked with another mark, if you want them
> marked normally (or in some other way).
>
> You can instead use `* c' to change marks of
> one kind (e.g. `C') to marks of another kind
> (e.g. `*').
>
> The prompts for this use `read-char', so it is
> very quick (no need to hit `RET').

Yeah, I use this sometimes.  FWIW, personally, I hacked my t to a more
convenient behavior: if I hit t and there are marks, it asks me whether
any existing marks besides * shall be removed, when there are some.  I
like an explicit question in this case because I tended to expect
different behavior in different situations, and mainly because I often
missed that there were any other marks, especially if the buffer is not
completely displayed when it is large.  That is a bit of a pitfall, but
the default behavior may also be surprising to users because the C marks
are not very useful per se (they are sometimes, so I don't want to turn
them off, but when using t a lot, they often just get in the way).

> Dired has lots of handy things like this, some
> of which are not known too well.  Another
> handy one is `M-DEL' (aka `M-<backspace>').
> It unmarks a particular mark (for all files
> listed in the buffer).  Just hit `RET' to
> remove all marks, of any kind.

Didn't know that.  My replacements were * ! and * c SPC (marking with
SPC also unmarks).


Michael.

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

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2020-05-09 03:26]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > emacs -Q
> >
> > C-x C-f to /tmp directory
> > C-x 3 to make 2 windows vertical
> > in other directory, make new directory like /tmp/new
> > create file in /tmp or choose any file with m, marking it
> > use C to copy to /tmp/new
> > C-x o to other window where file is copied, it has C mark
> > press t to toggle, it is not working
> 
> Note that (docstring):
> 
>   "Files marked with other flags (such as ‘D’) are not affected."
> 
> You must unmark the copied files (the C mark) for toggling to have an
> effect on them.  Is that your problem?
> 
> Michael.

Problem is explained, after copy of marked files in the neighboring
window, the key `t' for `dired-toggle-marks' don't work, as `t' is not
marking those files in the neighboring window.

I have to kill the window and enter directory again to be able to mark
the files with `t'

Jean

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

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> Problem is explained, after copy of marked files in the neighboring
> window, the key `t' for `dired-toggle-marks' don't work, as `t' is not
> marking those files in the neighboring window.

Ok, you have that copied file in that other window you then switch to.
That file has the C mark.  It is the only file in that directory.  Now
you hit t to toggle.  Nothing changes.  Is that all correct?  Because
what you have described so far is the expected behavior, so either we
are missing something, or you must please elaborate what different
behavior you expected.

Thanks in advance,

Michael.

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

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2020-05-10 04:11]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > Problem is explained, after copy of marked files in the neighboring
> > window, the key `t' for `dired-toggle-marks' don't work, as `t' is not
> > marking those files in the neighboring window.
> 
> Ok, you have that copied file in that other window you then switch to.
> That file has the C mark.  It is the only file in that directory.  Now
> you hit t to toggle.  Nothing changes.  Is that all correct?  Because
> what you have described so far is the expected behavior, so either we
> are missing something, or you must please elaborate what different
> behavior you expected.

One file or many files, I cannot use `t' after copy of files.

You say it is expected behavior, where is it described?

The key `t' says:

It is bound to t, * t, <menu-bar> <mark> <toggle-marks>.

(dired-toggle-marks)

Why does `t' does not work on files flagged with C?

Do you know?

Jean

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

[Tomas Nordin]

Jean Louis <bugs@gnu.support> writes:

> * Michael Heerdegen <michael_heerdegen@web.de> [2020-05-09 03:26]:
>> Jean Louis <bugs@gnu.support> writes:
>> 
>> > emacs -Q
>> >
>> > C-x C-f to /tmp directory
>> > C-x 3 to make 2 windows vertical
>> > in other directory, make new directory like /tmp/new
>> > create file in /tmp or choose any file with m, marking it
>> > use C to copy to /tmp/new
>> > C-x o to other window where file is copied, it has C mark
>> > press t to toggle, it is not working
>> 
>> Note that (docstring):
>> 
>>   "Files marked with other flags (such as ‘D’) are not affected."
>> 
>> You must unmark the copied files (the C mark) for toggling to have an
>> effect on them.  Is that your problem?
>> 
>> Michael.
>
> Problem is explained, after copy of marked files in the neighboring
> window, the key `t' for `dired-toggle-marks' don't work, as `t' is not
> marking those files in the neighboring window.
>
> I have to kill the window and enter directory again to be able to mark
> the files with `t'

You could also try to hit `U' at this point instead of killing window
and enter directory again, to run dired-unmark-all-marks. After that the
toggling should do what you expect.

>
> Jean

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

[Jean Louis]

* Tomas Nordin <tomasn@posteo.net> [2020-05-10 12:25]:
> > Problem is explained, after copy of marked files in the neighboring
> > window, the key `t' for `dired-toggle-marks' don't work, as `t' is not
> > marking those files in the neighboring window.
> >
> > I have to kill the window and enter directory again to be able to mark
> > the files with `t'
> 
> You could also try to hit `U' at this point instead of killing window
> and enter directory again, to run dired-unmark-all-marks. After that the
> toggling should do what you expect.

Aaa, that it is.

So C flag is mark same as with t, that is good for me.

But that behavior is not described that I know. If that is intended to
be so, that marking and flagging is the same, then maybe description
should be changed for that function, that user knows that function
will not work if files have the flag C for being copied.

Toggle marks: marked files become unmarked, and vice versa.
Files marked with other flags (such as ‘D’) are not affected.
‘.’ and ‘..’ are never toggled.
As always, hidden subdirs are not affected.

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

[Eli Zaretskii]

> Date: Sun, 10 May 2020 12:56:46 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 41097@debbugs.gnu.org,
>  rthur Miller <arthur.miller@live.com>
> 
> So C flag is mark same as with t, that is good for me.
> 
> But that behavior is not described that I know. If that is intended to
> be so, that marking and flagging is the same, then maybe description
> should be changed for that function, that user knows that function
> will not work if files have the flag C for being copied.
> 
> Toggle marks: marked files become unmarked, and vice versa.
> Files marked with other flags (such as ‘D’) are not affected.
> ‘.’ and ‘..’ are never toggled.
> As always, hidden subdirs are not affected.

Could you please tell what is missing or confusing in the doc string?
Is it the fact that it mentions 'D', but not 'C'?

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-05-10 17:08]:
> > Date: Sun, 10 May 2020 12:56:46 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: Michael Heerdegen <michael_heerdegen@web.de>, 41097@debbugs.gnu.org,
> >  rthur Miller <arthur.miller@live.com>
> > 
> > So C flag is mark same as with t, that is good for me.
> > 
> > But that behavior is not described that I know. If that is intended to
> > be so, that marking and flagging is the same, then maybe description
> > should be changed for that function, that user knows that function
> > will not work if files have the flag C for being copied.
> > 
> > Toggle marks: marked files become unmarked, and vice versa.
> > Files marked with other flags (such as ‘D’) are not affected.
> > ‘.’ and ‘..’ are never toggled.
> > As always, hidden subdirs are not affected.
> 
> Could you please tell what is missing or confusing in the doc string?
> Is it the fact that it mentions 'D', but not 'C'?

There is menu "Mark", in the menu there is "m" for mark, and "d" for
flag.

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.

Jean

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

[Eli Zaretskii]

> Date: Sun, 10 May 2020 17:55:03 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: tomasn@posteo.net, michael_heerdegen@web.de,
>   41097@debbugs.gnu.org, arthur.miller@live.com
> 
> > > Toggle marks: marked files become unmarked, and vice versa.
> > > Files marked with other flags (such as ‘D’) are not affected.
> > > ‘.’ and ‘..’ are never toggled.
> > > As always, hidden subdirs are not affected.
> > 
> > Could you please tell what is missing or confusing in the doc string?
> > Is it the fact that it mentions 'D', but not 'C'?
> 
> There is menu "Mark", in the menu there is "m" for mark, and "d" for
> flag.
> 
> 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.

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?

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-05-10 18:12]:
> Because t toggles marks, and C is not a mark, it's a flag.
> 
> 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?

That makes sense to me now.

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

[Eli Zaretskii]

> Date: Sun, 10 May 2020 18:33:11 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: tomasn@posteo.net, michael_heerdegen@web.de,
>   41097@debbugs.gnu.org, arthur.miller@live.com
> 
> * Eli Zaretskii <eliz@gnu.org> [2020-05-10 18:12]:
> > Because t toggles marks, and C is not a mark, it's a flag.
> > 
> > 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?
> 
> That makes sense to me now.

Thanks, I installed this on the release branch.

OK to close the bug now?

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

[Drew Adams]

> Thanks, I installed this on the release branch.
> 
> OK to close the bug now?

That "fix" is a real step backward, not forward.

When combined with the rest of Dired - behavior
and doc, it introduces inconsistency and confusion.
Please see my previous messages in this thread.

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

[Eli Zaretskii]

> Date: Sun, 10 May 2020 09:29:33 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: michael_heerdegen@web.de, tomasn@posteo.net, 41097@debbugs.gnu.org,
>         arthur.miller@live.com
> 
> > Thanks, I installed this on the release branch.
> > 
> > OK to close the bug now?
> 
> That "fix" is a real step backward, not forward.

I disagree.

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-05-10 19:06]:
> > Date: Sun, 10 May 2020 18:33:11 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: tomasn@posteo.net, michael_heerdegen@web.de,
> >   41097@debbugs.gnu.org, arthur.miller@live.com
> > 
> > * Eli Zaretskii <eliz@gnu.org> [2020-05-10 18:12]:
> > > Because t toggles marks, and C is not a mark, it's a flag.
> > > 
> > > 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?
> > 
> > That makes sense to me now.
> 
> Thanks, I installed this on the release branch.
> 
> OK to close the bug now?

Sure is OK.

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

[Eli Zaretskii]

> Date: Sun, 10 May 2020 20:17:24 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: tomasn@posteo.net, michael_heerdegen@web.de,
>   41097@debbugs.gnu.org, arthur.miller@live.com
> 
> > Thanks, I installed this on the release branch.
> > 
> > OK to close the bug now?
> 
> Sure is OK.

Thanks, closed.

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

[Drew Adams]

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

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

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2020-05-10 19:28]:
> 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."

Thanks, that gives me more clariy.

> 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 makes sense to me now. Thank you.

Jean

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

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> > Because t toggles marks, and C is not a mark, it's a flag.
>
> This is not true.  Let's please not go there.

But if you think so (and I somewhat agree), isn't then the first
sentence in the docstring that Eli didn't touch:

  "Toggle marks: marked files become unmarked, and vice versa."

even more confusing?  I guess Eli wanted to avoid a sentence like "and
files marked with marks other than the * mark don't count as marked."

But the inconsistency goes much further, we say that commands operate on
the "marked" files, but we mean only the *-marked files.

So I guess the terminology is "marked with" applies to any mark and
"marked" only to files marked with *, and "unmarked" means "doesn't have
any mark".  Oh dear, it's like learning English modal verbs.

I think we can be more specific in the docstring, and I also don't like
to introduce the second term "flag" here since it is somewhat linked to
deletion indeed, and it's meaning is as fluent as "mark" - that doesn't
help.

Ok, would something like this be a compromise?

- Toggle marks: marked files become unmarked, and vice versa.
- Files marked with other flags (such as `D') are not affected.

+ Toggle marks: marked files become unmarked, and vice versa.
+ This means that files marked with `*' are unmarked and files that don't
+ have any mark are marked with `*'.  Files marked with any
+ characters other than `*' are uneffected.

(the term "marker character" is already used in the manual.)


Regards,

Michael.

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

[Drew Adams]

> > > Because t toggles marks, and C is not a mark, it's a flag.
> >
> > This is not true.  Let's please not go there.
> 
> But if you think so (and I somewhat agree), isn't then the first
> sentence in the docstring that Eli didn't touch:
> 
>   "Toggle marks: marked files become unmarked, and vice versa."
> 
> even more confusing?  I guess Eli wanted to avoid a sentence like "and
> files marked with marks other than the * mark don't count as marked."

I already agreed that the doc string could be clearer.
I suggested this:

  Toggle `*' marks: unmark marked files, and vice versa.

But perhaps this would be even better (since "those"
refers to "`*' marks"):

  Toggle `*' marks: unmark those marked, and vice versa.

Or (72 chars):

  Toggle `*' marks: unmark files marked `*'; mark unmarked files with `*'.

IOW, explicitly say that toggling applies to `*' marks.

> But the inconsistency goes much further, we say that commands operate
> on the "marked" files, but we mean only the *-marked files.

See above.  (Are you talking about `t' here still?
Why do you say "commands" (plural)?)

> So I guess the terminology is "marked with" applies to any mark and
> "marked" only to files marked with *, and "unmarked" means "doesn't
> have any mark".  Oh dear, it's like learning English modal verbs.

I don't understand.  Perhaps I'm missing something.
No, there's nothing special about "marked with".

`t' replaces all `*' marks with a space - unmarks them.
`t' replaces all unmarked (space) with a `*' mark.

> I think we can be more specific in the docstring, and I also don't like
> to introduce the second term "flag" here since it is somewhat linked to
> deletion indeed, and it's meaning is as fluent as "mark" - that doesn't
> help.

It's _entirely_ linked to deletion, in Dired.  Or it
was, until Eli's change.

> Ok, would something like this be a compromise?
> 
> - Toggle marks: marked files become unmarked, and vice versa.
> - Files marked with other flags (such as `D') are not affected.
> 
> + Toggle marks: marked files become unmarked, and vice versa.
> + This means that files marked with `*' are unmarked and files that
> don't
> + have any mark are marked with `*'.  Files marked with any
> + characters other than `*' are uneffected.

unaffected, not uneffected.

That text is fine by me, even if a bit verbose
("This means").

I'd still propose mentioning `*' in the first
sentence (the main one) - it's about `*' marks
(only).  But your text is clear enough, to me.

> (the term "marker character" is already used in the manual.)

FWIW I don't understand why you added that part
in parens to your message.

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

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> IOW, explicitly say that toggling applies to `*' marks.

Yes, exactly.

> > But the inconsistency goes much further, we say that commands operate
> > on the "marked" files, but we mean only the *-marked files.
>
> See above.  (Are you talking about `t' here still?
> Why do you say "commands" (plural)?)

No, I mean commands, like

  dired-do-delete is an interactive compiled Lisp function in
  `dired.el'.
  [...]

  Delete all marked (or next ARG) files.

It doesn't say *-marked.  "Marked" typically means *-marked most of the
time.

> > (the term "marker character" is already used in the manual.)
>
> FWIW I don't understand why you added that part
> in parens to your message.

I only wanted to make clear that it's not a new term but one users that
read the manual are familiar with.  And it's maybe less misguiding than
"flag" (personally I could also live with just "character", since marks
are really just that).

Michael.

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

[Drew Adams]

> > IOW, explicitly say that toggling applies to `*' marks.
> 
> Yes, exactly.
> 
> > > But the inconsistency goes much further, we say that commands
> > > operate on the "marked" files, but we mean only the *-marked files.
>
> I mean commands, like
> 
>   dired-do-delete is an interactive compiled Lisp function in
>   `dired.el'.  [...]
> 
>   Delete all marked (or next ARG) files.
> 
> It doesn't say *-marked.  "Marked" typically means *-marked most of the
> time.

You're absolutely right.  The fix for this bug could
usefully be to correct the doc of any command that
acts only on `*' marks but says it acts on "marks".

Doc that says that a command acts on "marks" should
be only for a command that acts on all marks.  Doc
for a command that acts only on certain marks should
say so.

> > > (the term "marker character" is already used in the manual.)
> >
> > FWIW I don't understand why you added that part
> > in parens to your message.
> 
> I only wanted to make clear that it's not a new term but one users that
> read the manual are familiar with.  And it's maybe less misguiding than
> "flag" (personally I could also live with just "character", since marks
> are really just that).

I don't see the connection.  "Flag" has
specifically been used only for `D', the mark
for deletion.

?D is the marker character for the mark (flag)
`D'.  ?D is a character.  A visual `D' mark in
the buffer is, yes, created by putting a ?D
character in the mark position.

But that's a nit.  If what you're suggesting is
that the doc not speak of "flag `D'" but speak
instead of "marker character ?D" or "marker
character D" then I understand.  Is that it?

That's OK by me, provided the same is done
everywhere, for each mark: "marker character C"
etc.  I don't think that's really helpful - it
seems overly verbose and makes reading more
cumbersome.  But if others feel it's an
improvement, fine.

My concern here is that Emacs be consistent in
its explanations and terminology.  Another
concern is that things be clear and easy to
understand.

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

[Arthur Miller]

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.

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

[Drew Adams]

> So people are supposed to keep in their mind all this distinction when
> it is a flag and when it is a mark? 

Not necessary, really, I think.  Pretty much every
time "flag" is used it's accompanied by "deletion".
(Extra emphasis, I imagine.)

> So we are supposed to "flag" for
> deletion, but "mark" for copy. Is it really necessary?

Necessary?  No.  What's necessary, besides read,
eval, print?  Someone thought it was helpful.
Probably someone who was worried about users
accidentally deleting files.  Maybe the same
someone who implemented prompting for deletion
confirmation.

> Does it really need to be that complicated,

Is it really complicated?  As one user, I don't
think so.  But YMMV.

> I mean, cognitively speaking? Does it
> really add anything in quality if you distinct between "marking" and
> "flagging" for deletion?

Someone thought so.  I agree with whoever that
was.  But I'm just one user, like you.

> What is wrong to just simply "mark" files
> with different "flags"?

I don't think anyone said there's anything wrong
with that.  But in that case, there's also no
reason to introduce two different terms - just
"mark" with different "marks".

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

It's fine with me if everyone wants to remove mention
of "flag" and "flagging".  If you do that, please do
it well, everywhere.  Say explicitly which marks are
involved for each action, unless an action applies to
all marks.

If you make such a change, it's not just a fix for
this minor bug.  You'll need to adjust text, menus,
etc. everywhere, to be consistent.

(IMHO, there's no need in that case to also change
function and variable names.  Ideally, yes, if use of
"flag" is removed then Dired functions and vars with
"flag" in their name should be renamed.  Similarly, but
with less importance, functions and vars with "mark" in
their name should ideally be renamed if they affect
only certain marks - to say that.  But I wouldn't ask
for any such renamings, personally.)

My only position here has been to say what the Dired
convention is and has always been.  And to say that
I think it should be respected consistently.  Any
inconsistencies are candidates for correction.

The convention doesn't come from me.  I'm just the
messenger, reminding us about it.  As a user who knows
it, I've benefitted from it (when I see "flag" I know
it's about deletion).  But I won't argue that the
convention can't be changed.

If someone proposes to change the convention, e.g. to
remove any mention of "flag", then please do that
consistently.  That's all.