[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave
From: |
sbaugh |
Subject: |
bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer |
Date: |
Fri, 07 Apr 2023 21:02:47 +0000 (UTC) |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Juri Linkov <juri@linkov.net> writes:
> Changing the API will definitely cause problems with backwards-compatibility.
> But maybe you could find a simple heuristic that would decide what base-suffix
> to set in minibuffer-completion-help? Then no API changes will be needed.
Thank you for the guidance and suggestion.
Here's one heuristic which works decently well:
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 21d4607e7cf..dfb06b5b88f 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2374,7 +2374,11 @@ minibuffer-completion-help
(prefix (unless (zerop base-size) (substring string 0 base-size)))
(base-prefix (buffer-substring (minibuffer--completion-prompt-end)
(+ start base-size)))
- (base-suffix (buffer-substring (point) (point-max)))
+ (base-suffix
+ (if (eq (alist-get 'category (cdr md)) 'file)
+ (buffer-substring (save-excursion (search-forward "/" nil t)
(point))
+ (point-max))
+ ""))
(all-md (completion--metadata (buffer-substring-no-properties
start (point))
base-size md
The reasoning here is that if completion returns the full string which
should be in the minibuffer, then we should replace the minibuffer with
that string, so base-suffix should be "". But if we're completing only
part of the string, base-suffix should be something else. AFAIK only
file completion falls into the latter category, and it always completes
just one component of a path, so I set base-suffix to not include the
component of the path that point is in, so that completion replaces it
entirely.
I think this is basically a satisfactory heuristic, although I'm sure
I'm missing some categories of completion besides file completion which
complete only part of the string.
Regardless of whether this is a satisfactory heuristic, it's revealed to
me an unexpected behavior of a solution to this bug using base-suffix,
which may or may not be fine: Point is moved to the end of the
completion inserted.
So e.g. if point is at | and I'm completing |-path, then when I choose
the completion load-path, point will be at load-path| rather than
load|-path. This isn't a huge issue but it might be a little annoying?
I don't know if there's any way to fix this.
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Spencer Baugh, 2023/04/06
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Juri Linkov, 2023/04/06
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Spencer Baugh, 2023/04/06
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Juri Linkov, 2023/04/07
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer,
sbaugh <=
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Eli Zaretskii, 2023/04/08
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, sbaugh, 2023/04/08
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Eli Zaretskii, 2023/04/08
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Juri Linkov, 2023/04/08
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Eli Zaretskii, 2023/04/08
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Juri Linkov, 2023/04/09
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Eli Zaretskii, 2023/04/09
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Juri Linkov, 2023/04/08
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Spencer Baugh, 2023/04/10
- bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer, Juri Linkov, 2023/04/10