unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Andreas Schwab <schwab@linux-m68k.org>, Eli Zaretskii <eliz@gnu.org>
Cc: tino.calancha@gmail.com, emacs-devel@gnu.org
Subject: RE: Dired: Improve symmetry in mark/unmark commands bound to keys
Date: Sat, 24 Sep 2016 16:49:49 -0700 (PDT)	[thread overview]
Message-ID: <956c08c7-abd8-4cf5-aa70-bcd85f8f3499@default> (raw)
In-Reply-To: <87twd512pk.fsf@linux-m68k.org>

> The prefix was obviously never
> intented to be used with this command.  The only intented use of the
> second argument was the its caller, dired-flag-extension.  That is easy
> to prove, because before commit 736b582 it wasn't even documented in the
> doc string.

Yes.  More importantly, we can do what we think is best.

What do we really need?

1. We need for `dired-flag-extension' to work.  With the current
   implementation that means calling `dired-mark-extension' with
   a `D' mark.

2. We need a command for changing the mark character that is used
   for the currently marked files.  We have that: `* c'
   (`dired-change-marks').

3. We need a command to mark files that have a given extension.
   We have that: `* .' (`dired-mark-extension').

4. We need a command to unmark files that have a given extension.
   We do NOT have this.

5. Do we need a command that marks files that have a given
   extension and prompts you for which mark character to use?
   This is currently provided by `* .' with a prefix arg.

I agree with Tino and Andreas that #5 is not needed.  It has never
been used, AFAICT.  #2 suffices for getting whatever marks you want.

I agree with them also that we do not need a new, separate command
for #4, and that we should let `* .' also unmark, with a prefix arg.

Two possibilities, if we want that behavior for `* .':

a. Redefine `dired-mark-extension' to do that.  In this case,
   the implementation of #1 needs to change (provide a helper).

b. Define a new command.  Call it `dired-mark-or-unmark-extension'.

For (b): The other commands for which a prefix arg unmarks
rather than marks do NOT have "-or-unmark" in the name.

Should they, to distinguish them from those that only mark or
only unmark?  For example, should `dired-mark-files-regexp' be
called `dired-mark-or-unmark-files-regexp'?

That brings us back to the question of thread "Ibuffer: w and B
default to buffer at current line".  I think we should name the
commands after only the _default_ behavior, i.e., what happens
if you do not use a prefix arg.  So I'd argue for just making
`dired-mark-extension' unmark with a prefix arg (and providing
a different helper function for `dired-flag-extension') -
unless someone can point out how using a prefix arg to specify
the mark character is actually useful for `* .'.

On the other hand, there are some commands that only mark or
unmark, and for which either (a) the opposite behavior is not
useful or (b) the prefix arg is used for something else, and
two different keys might be provided for marking and unmarking.
For example, `* m' just marks, and `* u' just unmarks.  Such
exceptions also include `* ?' (`dired-unmark-all-files') and
`* !' (`dired-unmark-all-marks').

Other than such exceptions, should commands that currently only
mark or unmark, and for which both operations are useful, also
do double-duty, via a prefix arg?  For example, should `* s'
unmark all with a prefix arg (one of Tino's proposals)?
 
Most commands that unmark also unflag - they remove all marks,
including `D' (deletion flag).  The doc strings make this clear -
except the doc string of `dired-unmark'.  Shouldn't that doc
string also make this clear?

There is maybe a little room for some minor cleanup and making
the command set a bit more consistent.  On the other hand, all
things are not equal, and forcing consistency where it is not
appropriate is not the answer either.  There is no imperative
to paint with a broad brush.  In most cases there are good
reasons for the current command behavior, I think.



  reply	other threads:[~2016-09-24 23:49 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-24 17:31 Dired: Improve symmetry in mark/unmark commands bound to keys Tino Calancha
2016-09-24 18:12 ` Eli Zaretskii
2016-09-24 18:25   ` Tino Calancha
2016-09-24 19:31 ` Andreas Schwab
2016-09-24 19:39   ` Eli Zaretskii
2016-09-24 19:46     ` Andreas Schwab
2016-09-24 19:58       ` Eli Zaretskii
2016-09-24 20:07         ` Andreas Schwab
2016-09-24 23:49           ` Drew Adams [this message]
2016-09-25  9:06             ` Tino Calancha
2016-09-25 18:55           ` John Wiegley
2016-09-26  9:23             ` Tino Calancha
2016-09-26 11:05               ` Tino Calancha
2016-09-26 15:02               ` Eli Zaretskii
2016-09-26 15:06               ` Eli Zaretskii
2016-09-26 15:47               ` John Wiegley
2016-09-26 16:30                 ` Tino Calancha
2016-09-26 19:02                   ` Eli Zaretskii
2016-10-03  9:21                     ` Tino Calancha
2016-10-03  9:54                       ` Eli Zaretskii
2016-10-03 11:15                         ` Tino Calancha
2016-09-26 21:52                   ` John Wiegley
2016-09-25 19:14           ` Eli Zaretskii
2016-09-25 22:43             ` Andreas Schwab
2016-09-25 22:58             ` Andreas Schwab
2016-09-25 23:00             ` Andreas Schwab
2016-09-26  2:38               ` Eli Zaretskii
2016-09-26  8:33                 ` Andreas Schwab
2016-09-26 14:59                   ` Eli Zaretskii
2016-09-24 19:49     ` Tino Calancha
     [not found] <<alpine.DEB.2.20.1609250230400.4103@calancha-pc>
     [not found] ` <<83oa3db20a.fsf@gnu.org>
2016-09-24 18:53   ` Drew Adams

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=956c08c7-abd8-4cf5-aa70-bcd85f8f3499@default \
    --to=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=schwab@linux-m68k.org \
    --cc=tino.calancha@gmail.com \
    /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).