unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org, juri@linkov.net
Subject: RE: Why change the advertised bindings of Isearch commands?
Date: Fri, 27 Nov 2015 08:50:25 -0800 (PST)	[thread overview]
Message-ID: <6191c91b-e09a-4cf2-859d-7370e1300924@default> (raw)
In-Reply-To: <<83k2p3sq71.fsf@gnu.org>>

> > Using M-c to exit and capitalize means removing it as a key
> > that does something useful _in_ Isearch.
> 
> And evidently, the desire to remove it means we think its binding
> outside Isearch is more useful.

We do?  How and when did we decide that?

What were the arguments pro and con - where can I find the
discussion?  Did we poll the users, to get their take on this?
 
> > > What you are saying is that a user who spots a word to be
> > > capitalized during Isearch needs to do at least 2 things:
> > > exit Isearch with some key, then type M-c.
> >
> > Exactly as it has always been: `RET M-c'.
> 
> The intent of the advertised bindings is to change that at some
> future point.

Since when do we advertise bindings for that reason?  Can you
point to a case where we've done that?  An advertised binding
is typically used to ensure that the simplest or most flexible
binding gets advertised, instead of a more complex binding that
the tools would otherwise automatically report as "the" binding.

At any rate, it's that intention to "change that at some future
point" that I haven't seen discussed or decided.

And that I disagree with.  But if it _has_ been discussed and
decided then I have no problem supporting the decision, even
if I disagree with it.

> > And not "at least 2 things".  Exactly 2 things: exit & act.
> 
> No, it's "at least 2 things".  Because depending on how you exit
> Isearch you may need to move point first.

Oh come on.  Sure, you _could_ exit with a key that you bind
to a function that does whatever nutty thing you like, and
then have to move back where you were.  This is 100% beside
the point (seems like arguing for the sake of arguing), since
there are other keys (e.g. RET) that do _not_ take you all
around Robinson's barn.

> > So far, no reason for this change in defaults (for 3 keys)
> > was even given.  AFAIK, it ain't broke; no need to fix it.
> 
> That's a different issue.  You asked why the advertised
> bindings were changed; you now have the answer, I hope.

No, my question is why _should_ we change these bindings?

Your answer is that they were changed because we decided to
change them.  Sheesh.  How about an argument to support the
change and the intention to remove these Isearch bindings?
How about polling the users?

> > As I said, "different users care to have different keys
> > exit and act immediately".
> 
> There are facilities to tailor the commands that exit
> Isearch, if the user doesn't like the defaults.

Precisely.  So why the need for this change?  That's the
question (still unanswered).

> > But let's hear some arguments in favor of the changes,
> > please.
> 
> That's a separate discussion.

No, that's exactly what this thread is about.  I started
the thread, and that is what my question is: _Why_ should
we change these bindings?  Reasons, please.

You seem to be content to say that the "reason" for the
change is that Juri made the change - he decided that it
should be made and he made it.  That's the starting point
for the question; it does not answer the question.



       reply	other threads:[~2015-11-27 16:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<dddad317-4c44-4a68-b1d3-19bbd3a6746f@default>
     [not found] ` <<83k2p3sq71.fsf@gnu.org>
2015-11-27 16:50   ` Drew Adams [this message]
2015-11-27 23:09     ` Why change the advertised bindings of Isearch commands? Juri Linkov
2015-11-28  1:01       ` Drew Adams
     [not found] <<98f8a71f-1f10-4ff6-a4c1-8dc2d179b84b@default>
     [not found] ` <<87ziy05p3g.fsf@mail.linkov.net>
     [not found]   ` <<1a6f342a-3e59-4555-a345-e518cc598299@default>
     [not found]     ` <<83egfbub4q.fsf@gnu.org>
2015-11-27  9:33       ` Drew Adams
2015-11-27 10:16         ` Eli Zaretskii
2015-11-26 18:45 Drew Adams
2015-11-26 23:16 ` Juri Linkov
2015-11-27  0:03   ` Drew Adams
2015-11-27  7:58     ` Eli Zaretskii
2015-11-28  5:33       ` Richard Stallman
2015-11-28 20:30         ` John Wiegley

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=6191c91b-e09a-4cf2-859d-7370e1300924@default \
    --to=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=juri@linkov.net \
    /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).