unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Augusto Stoffel <arstoffel@gmail.com>
Cc: 46469@debbugs.gnu.org, juri@linkov.net
Subject: bug#46469: [External] : bug#46469: 27.1; `isearch-del-char' should move point further back
Date: Sun, 14 Feb 2021 17:24:47 +0200	[thread overview]
Message-ID: <83v9aubrk0.fsf@gnu.org> (raw)
In-Reply-To: <878s7rnmm8.fsf@gmail.com> (message from Augusto Stoffel on Sun,  14 Feb 2021 08:18:23 +0100)

> From: Augusto Stoffel <arstoffel@gmail.com>
> Cc: Drew Adams <drew.adams@oracle.com>,  Juri Linkov <juri@linkov.net>,
>  46469@debbugs.gnu.org
> Date: Sun, 14 Feb 2021 08:18:23 +0100
> 
> Re the idea that we can't change the behavior of an old command: if
> taken too seriously, this principle would imply that the standard Emacs
> UI can never improve

I didn't say that behavior of old commands cannot change, I said it
cannot change _unconditionally_.  That is, users should have a way to
revert to the old behavior.  It is generally preferable to make any
change in behavior opt-in; but even if we decide to make it the
default, there should be a way to go back.  That is because Emacs is a
very old and stable program, with users who are used to its present
behavior, and we try very hard not to break things that were working
for many years, nor change them in incompatible ways, since such
changes tend rightfully annoy veteran users.

In this particular case, whatever new aspects of the behavior you
suggest to add, they should be conditioned on a user option, and users
should be told in NEWS about the new behavior and the way to go back
to the old one (if the new one is made the default).

> Also, `isearch-del-char' changed from one obscure key to another
> obscure key in Emacs 27.  So clearly things can change.

It is IMO unfortunate that so many changes are happening lately in the
Isearch area regarding key bindings.  But that doesn't mean we should
make more changes there too lightly, let alone make them
unconditional.  At least keybindings can be easily undone on the user
level.

> Re this being a personal preference: I wouldn't bother to send a patch
> if I thought so.

"Personal preference" should not be interpreted to mean you are the
only person to prefer that.  Rather, it means that some people may
want that and some won't.  At least two people in this thread opined
that the existing behavior is fine, so clearly at least some people
would like to have the existing behavior.  Which doesn't mean what you
suggest doesn't have its place, it just means it isn't the only
opinion among Emacs users.

Where some users prefer one behavior and some prefer another, a user
option to control which behavior actually happens is a good way to
allow everyone to have what they want at a price of flipping a
variable.

> Is there a case where the current behavior is much more convenient
> and/or takes the search to a state that can't be easily reproduced by
> the patched version?

It is more convenient to me because I'm used to it: when I want to
remove the last character from the search string, I type DEL twice
without even looking.  I'm guessing there are others who have the same
habits.





  reply	other threads:[~2021-02-14 15:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-12 18:56 bug#46469: 27.1; `isearch-del-char' should move point further back Augusto Stoffel
2021-02-12 20:00 ` Eli Zaretskii
2021-02-12 20:20   ` Augusto Stoffel
2021-02-13  7:04     ` Eli Zaretskii
2021-02-13  7:32       ` Augusto Stoffel
2021-02-13  8:59         ` Eli Zaretskii
2021-02-13  9:53           ` Augusto Stoffel
2021-02-13 13:28             ` Eli Zaretskii
2021-02-13 23:14           ` bug#46469: [External] : " Drew Adams
2021-02-14  3:42             ` Eli Zaretskii
2021-02-14  7:18               ` Augusto Stoffel
2021-02-14 15:24                 ` Eli Zaretskii [this message]
2021-02-14 17:49                 ` Juri Linkov
2021-02-15 19:31                   ` Augusto Stoffel
2021-02-15 19:41                     ` Eli Zaretskii
2021-02-13 18:31 ` Juri Linkov
2021-02-14  7:00   ` Augusto Stoffel
2021-02-14 17:45     ` Juri Linkov
2021-04-27 18:44       ` Augusto Stoffel
2021-04-28 20:53         ` Juri Linkov
2021-04-28 21:16           ` Augusto Stoffel
2021-04-28 21:37             ` Juri Linkov

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=83v9aubrk0.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=46469@debbugs.gnu.org \
    --cc=arstoffel@gmail.com \
    --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).