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: Mon, 11 May 2020 09:03:17 -0700 (PDT)

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





reply via email to

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