all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Dmitry Gutov <dmitry@gutov.dev>, Eli Zaretskii <eliz@gnu.org>,
	70968@debbugs.gnu.org, juri@linkov.net
Subject: bug#70968: 29.2.50; choose-completion on an emacs22-style completion deletes text after point
Date: Tue, 10 Sep 2024 12:54:05 -0400	[thread overview]
Message-ID: <ierjzfjphzm.fsf@janestreet.com> (raw)
In-Reply-To: <jwvjzfmcsfv.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Sun, 08 Sep 2024 07:12:47 -0400")

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Ping!  How should we proceed with this bug report?
>
> I don't quite understand the question.
>
> After:
>
> Eli wrote:
>> Stefan wrote:
>> > I'm not sure it's terribly important to preserve this detail of the
>> > behavior of `Emacs-22`.  The `emacs22` style does not aim to provide the
>> > illusion you're running an old Emacs.  I named it that way because
>> > I couldn't come up with a good descriptive name for it.  If it
>> > misbehaves, I don't see a need to be bug-compatible, especially since
>> > this doesn't affect ELisp code but users.
>>
>> I think it does, sorry.  Suchj old behavior is a de-facto standard.
>> If we change that, we should at least have a knob to get back the old
>> behavior.
>
> I thought you had decided that the current behavior is not a bug.
> I'm fine with this choice and we can close it as such.
> Tho maybe we'd want to deprecate that `emacs22` style because of
> those odd cases.

I definitely don't want to just close this bug.  I often get user
complaints about this behavior.  In my experience, for novice users,
it's a fairly significant inconsistency in the default Emacs completion
experience.

I see a few good ways to fix this in a backwards-compatible way:

A. Fix it in emacs22 with a defcustom to get back the old behavior.

B. Deprecate the emacs22 style and replace it with a new style called
   `ignore-suffix` which has this bug fixed, and which replaces emacs22
   in the default value of completion-styles.

C. Follow this idea I suggested earlier:

   Currently emacs22 is the only style that ignores the text after point
   when completing.  But, this is often useful behavior, and I'd like to
   support it in other completion styles.  Specifically, I think it
   would be nice if completion always:
   
   1. First, run the completion styles on the literal text in the
   completion region or minibuffer.
   
   2. If that returned nil, run the completion styles again, but without
   the text after point in the region or minibuffer.
   
   Step 2 when run with the basic style is equivalent to the emacs22
   style.  So, emacs22 could be removed from the default
   completion-styles, since a completion-styles of '(basic) would be
   equivalent to '(basic emacs22).

   I think this would make it straightforward to then fix
   choose-completion to behave correctly when the completion was
   generated through step 2.
   
I personally like the option C best, because I already want to do this
generalization, so that the ignore-suffix behavior also works for other
completion styles (e.g. partial-completion or substring).

But I would like to get some feedback on this idea from others first.





  reply	other threads:[~2024-09-10 16:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-15 20:26 bug#70968: 29.2.50; choose-completion on an emacs22-style completion deletes text after point Spencer Baugh
2024-05-16  8:13 ` Eli Zaretskii
2024-05-16 17:26   ` Dmitry Gutov
2024-05-16 18:25     ` Eli Zaretskii
2024-08-26  0:08       ` Dmitry Gutov
2024-09-07  7:30         ` Eli Zaretskii
2024-09-08  2:02           ` Dmitry Gutov
2024-09-08 11:12           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-10 16:54             ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-09-14  9:17               ` Eli Zaretskii
2024-09-14 15:18                 ` Dmitry Gutov
2024-09-14 16:00                   ` Eli Zaretskii
2024-09-16 19:54                 ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-16 17:40   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-16 18:28     ` Eli Zaretskii
2024-06-20 15:45 ` Spencer Baugh

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ierjzfjphzm.fsf@janestreet.com \
    --to=bug-gnu-emacs@gnu.org \
    --cc=70968@debbugs.gnu.org \
    --cc=dmitry@gutov.dev \
    --cc=eliz@gnu.org \
    --cc=juri@linkov.net \
    --cc=monnier@iro.umontreal.ca \
    --cc=sbaugh@janestreet.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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.