unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: tino.calancha@gmail.com, emacs-devel@gnu.org
Subject: Re: Dired: Improve symmetry in mark/unmark commands bound to keys
Date: Sun, 25 Sep 2016 22:14:48 +0300	[thread overview]
Message-ID: <831t07bxlj.fsf@gnu.org> (raw)
In-Reply-To: <87twd512pk.fsf@linux-m68k.org> (message from Andreas Schwab on Sat, 24 Sep 2016 22:07:35 +0200)

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Sat, 24 Sep 2016 22:07:35 +0200
> Cc: emacs-devel@gnu.org, tino.calancha@gmail.com
> 
> No, they make absolutely no sense.  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.

Before commit 736b582 the doc string didn't mention that EXTENSION
could be a list, either.  Like the optional argument, the fact that it
could be a list was only mentioned in the comment, which was later
moved into the doc string.  So by that logic the list feature also
makes no sense, which is of course absurd.

IOW, this argument proves nothing.

Look, if you want to convince me, either get the author(s) of the code
tell that they made a mistake using that 'P' in the interactive spec,
or come up with a _very_ plausible theory how it could happen without
the author really meaning it to happen.  The interactive spec in its
form before my yesterday's changes was there since the day the
function was added to Emacs.  We need a clear understanding how did
the spec end up being in that form when the programmer didn't mean to
allow specification of the marker.  This stuff doesn't get written by
itself, so any explanation should be good and convincing.

If we cannot prove to ourselves it was an accident or a mistake, then
I object to removing this feature, even if we think it's not very
useful, and even if we don't know who uses it or whether anybody used
it in the past.  I don't think we should knowingly remove existing
features without a very good reason.  Emacs is stable, and "stable"
means existing features don't just disappear.

If we want to have a convenient way of unmarking by extension without
introducing a new function, let's do that without removing this
feature of specifying the marker character.  There are quite a few
examples elsewhere in Emacs for how to get creative with prefix
arguments; I'm sure one of them will allow us to support both features
in this case.



  parent reply	other threads:[~2016-09-25 19:14 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
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 [this message]
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=831t07bxlj.fsf@gnu.org \
    --to=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).