unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dmitry@gutov.dev>
To: Spencer Baugh <sbaugh@janestreet.com>, Eli Zaretskii <eliz@gnu.org>
Cc: 70968@debbugs.gnu.org, monnier@iro.umontreal.ca, juri@linkov.net
Subject: bug#70968: 29.2.50; choose-completion on an emacs22-style completion deletes text after point
Date: Tue, 24 Sep 2024 03:03:41 +0300	[thread overview]
Message-ID: <8479c25d-b4ae-4e89-9880-0857a996936a@gutov.dev> (raw)
In-Reply-To: <ierr09jgyr1.fsf@janestreet.com>

[-- Attachment #1: Type: text/plain, Size: 4528 bytes --]

Hi Spencer,

On 16/09/2024 22:54, Spencer Baugh wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>> I'm okay with adding a new style, per B, but why do we need to
>> deprecate emacs22 at the same time?  Let users who want this new
>> behavior customize their completion styles to use this new style
>> instead of emacs22.  That'd be fully backward compatible, and will
>> solve the problem for those who don't like the current behavior.
> 
> That's fair enough, we don't need to deprecate emacs22 at the same time,
> we can wait until the new style has been battle-tested.
> 
> I think a new style should replace emacs22 in the default
> completion-styles eventually, but that can wait.
> 
> And after working on this bug for a while, I now am convinced that the
> new style approach is straightforward, and is the best way.  (Although
> it would also work to make these changes in the emacs22 style)

I'm not quite convinced about the "new style only" approach myself, but 
anyway we can discuss a solution that could be applied to any style, 
opt-in or opt-out.

> Attached is a patch which adds a new ignore-after-point style.  The fix
> for this bug is entirely contained in the differences between
> completion-ignore-after-point-all-completions (c-iap-a-c) and
> completion-emacs22-all-completions (c-e22-a-c).
> 
> c-e22-a-c always omits the text after point, which means
> choose-completion always deletes that text, causing this bug.
> 
> c-iap-a-c includes the text after point in some cases.  Whenever the
> text after point is included, it's grayed out with a new
> completions-ignored face to indicate it was ignored.
> 
> The cases where c-iap-a-c includes the text after point are those where
> the user will have further chances to edit or complete with that text:
> 
> - When we're doing minibuffer completion and choose-completion will
>    immediately exit the minibuffer, the text after point is not included,
>    since the user won't get any further changes to use it, and it's
>    probably garbage.
> 
> - When we're doing completion-at-point (or certain kinds of minibuffer
>    completion, e.g. completing a directory in filename completion), the
>    text after point is included.  In such cases, the user can always
>    delete it themselves later, or might want to actually use it.
> 
> To make this work consistently with completion-try-completion (which
> keeps point before the ignored suffix in both the ignore-after-point and
> emacs22 styles), choose-completion-string now checks a new
> 'completion-position-after-insert text property, and moves point to that
> position.
> 
> (There are two other changes which are general improvements unrelated to
> this bug:
> 
> - The behavior of keeping point before the ignored suffix is more
>    consistent.
> 
> - Instead of hardcoding try-completion and all-completion,
>    ignore-after-point uses the configured completion styles.)

Thank you, I see a few problems with that approach (as discussed 
privately as well). To recap:

 From my POV integrating the result with company-mode is non-trivial. 
And the created visual doesn't seem optimal in a number of edge cases 
(long prefix = weird-looking popup; this probably applies to the 
*Completions* buffer as well, though maybe to a lesser extent).

Another problem is both the "all-completions" method and the insertion 
function call out to UI: choose-completion-string--should-exit 
references minibuffer-completion-table and completion-no-auto-exit 
directly, for example. I'm on the fence about coupling to the completion 
category.

Finally, the use of 'completion-position-after-insert' seems like it 
could be used separately from the "ignored text", meaning the spans 
don't have to match. So it could be a separate feature, one that's easy 
enough to implement on its own.

None of the above would be insurmountable, but here's what I think 
avoids it using the 'completion--adjust-metadata' thingy that was 
originally added for 'flex' a few releases ago: adding a metadata key 
'completion-ignore-after-point'.

The attached patch does not make a distinction for file name completion 
- it just covers the core problem - but I think any UI could use the 
addition and likewise lookup the 'file' category, and print the "hidden" 
suffix in the Completions, and decide to drop the suffix in your first 
scenario (file name completion with exit imminent).

Spencer, Stefan, WDYT?

Again, the patch is against the emacs22 style for readability, but a new 
style can be added just as well.

[-- Attachment #2: completion-ignore-after-point-metadata.diff --]
[-- Type: text/x-patch, Size: 1878 bytes --]

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 804afe9cb43..4ac231171b6 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2613,7 +2613,6 @@ minibuffer-completion-help
                                              (buffer-substring (point) end))))
                 (point)))
              (field-char (and (< field-end end) (char-after field-end)))
-             (base-position (list (+ start base-size) field-end))
              (all-md (completion--metadata (buffer-substring-no-properties
                                             start (point))
                                            base-size md
@@ -2623,6 +2622,12 @@ minibuffer-completion-help
              (aff-fun (completion-metadata-get all-md 'affixation-function))
              (sort-fun (completion-metadata-get all-md 'display-sort-function))
              (group-fun (completion-metadata-get all-md 'group-function))
+             (ignore-after-point (completion-metadata-get all-md
+                                                          'ignore-after-point))
+             (base-position (list (+ start base-size)
+                                  (if ignore-after-point
+                                      (point)
+                                    field-end)))
              (mainbuf (current-buffer))
              ;; If the *Completions* buffer is shown in a new
              ;; window, mark it as softly-dedicated, so bury-buffer in
@@ -3778,6 +3783,13 @@ completion-emacs22-all-completions
      point
      (car (completion-boundaries beforepoint table pred "")))))
 
+(put 'emacs22 'completion--adjust-metadata 'completion--emacs22-adjust-metadata)
+
+(defun completion--emacs22-adjust-metadata (metadata)
+  `(metadata
+    (ignore-after-point . t)
+    ,@(cdr metadata)))
+
 ;;; Basic completion.
 
 (defun completion--merge-suffix (completion point suffix)

  reply	other threads:[~2024-09-24  0:03 UTC|newest]

Thread overview: 17+ 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
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-09-24  0:03                   ` Dmitry Gutov [this message]
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

  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=8479c25d-b4ae-4e89-9880-0857a996936a@gutov.dev \
    --to=dmitry@gutov.dev \
    --cc=70968@debbugs.gnu.org \
    --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 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).