GNU bug report logs -
#39600
[PATCH] Fix handling of non-exclusive non-prefix completion functions
Previous Next
To reply to this bug, email your comments to 39600 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39600
; Package
emacs
.
(Fri, 14 Feb 2020 15:08:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Amai Kinono <amaikinono <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 14 Feb 2020 15:08:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
# What does this fix?
Currently, with non-exclusive completion functions, Emacs will do
`try-completion` on the current text, and decide whether to try next
completion function based on that. This makes completion functions that
can do non-prefix completions fails when the current text only occurs in
the middle of the candidates. This is a problem I found in a FIXME in
the code.
# How does this work?
I use `completion-all-completions` instead. As far as I know, this
respects the `completion-styles`.
Here's a simple test. Eval this:
```
(require 'thingatpt)
(defun my-completion-at-point ()
(let* ((symbol (thing-at-point 'symbol))
(bounds (bounds-of-thing-at-point 'symbol)))
(list (car bounds) (cdr bounds)
'("gnuemacs" "xemacs" "uemacs")
:exclusive 'no)))
(setq completion-at-point-functions
'(my-completion-at-point elisp-completion-at-point))
(setq completion-styles '(substring))
```
Now type "emacs" and press `C-M-i`, the candidates defined in
`my-completion-at-point` will show up correctly. Now change
`completion-styles` to `(basic)`, and complete "emacs" again, it
fallbacks to `elisp-completion-at-point`.
# The patch
See the attachment. Since I don't know much about email, I'm not sure if
gmail's attachment is permanent, so I'll also paste the diff and commit
log here:
## Diff
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2244,18 +2244,11 @@ completion--capf-wrapper
(unless (member fun completion--capf-safe-funs)
(push fun completion--capf-safe-funs))
(and (eq 'no (plist-get (nthcdr 3 res) :exclusive))
- ;; FIXME: Here we'd need to decide whether there are
- ;; valid completions against the current text. But this
depends
- ;; on the actual completion UI (e.g. with the default
completion
- ;; it depends on completion-style) ;-(
- ;; We approximate this result by checking whether prefix
- ;; completion might work, which means that non-prefix
completion
- ;; will not work (or not right) for completion functions
that
- ;; are non-exclusive.
- (null (try-completion (buffer-substring-no-properties
- (car res) (point))
- (nth 2 res)
- (plist-get (nthcdr 3 res)
:predicate)))
+ (null (completion-all-completions
+ (buffer-substring-no-properties (car res) (point))
+ (nth 2 res)
+ (plist-get (nthcdr 3 res) :predicate)
+ (- (point) (car res))))
(setq res nil)))
((not (or (listp res) (functionp res)))
(unless (member fun completion--capf-misbehave-funs)
## Commit Log
Fix handling for non-exclusive non-prefix completion functions
* lisp/minibuffer.el (completion--capf-wrapper):
use completion-all-completions to do the test.
[Message part 2 (text/html, inline)]
[0001-Fix-handling-for-non-exclusive-non-prefix-completion.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39600
; Package
emacs
.
(Sat, 08 Aug 2020 14:05:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 39600 <at> debbugs.gnu.org (full text, mbox):
Amai Kinono <amaikinono <at> gmail.com> writes:
> Currently, with non-exclusive completion functions, Emacs will do
> `try-completion` on the current text, and decide whether to try next
> completion function based on that. This makes completion functions that
> can do non-prefix completions fails when the current text only occurs in
> the middle of the candidates. This is a problem I found in a FIXME in
> the code.
>
> # How does this work?
>
> I use `completion-all-completions` instead. As far as I know, this
> respects the `completion-styles`.
[...]
Stefan, how does this patch look to you?
> - ;; FIXME: Here we'd need to decide whether there are
> - ;; valid completions against the current text. But this depends
> - ;; on the actual completion UI (e.g. with the default completion
> - ;; it depends on completion-style) ;-(
> - ;; We approximate this result by checking whether prefix
> - ;; completion might work, which means that non-prefix completion
> - ;; will not work (or not right) for completion functions that
> - ;; are non-exclusive.
> - (null (try-completion (buffer-substring-no-properties
> - (car res) (point))
> - (nth 2 res)
> - (plist-get (nthcdr 3 res) :predicate)))
> + (null (completion-all-completions
> + (buffer-substring-no-properties (car res) (point))
> + (nth 2 res)
> + (plist-get (nthcdr 3 res) :predicate)
> + (- (point) (car res))))
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39600
; Package
emacs
.
(Sat, 08 Aug 2020 21:59:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 39600 <at> debbugs.gnu.org (full text, mbox):
>> Currently, with non-exclusive completion functions, Emacs will do
>> `try-completion` on the current text, and decide whether to try next
>> completion function based on that. This makes completion functions that
>> can do non-prefix completions fails when the current text only occurs in
>> the middle of the candidates. This is a problem I found in a FIXME in
>> the code.
>>
>> # How does this work?
>>
>> I use `completion-all-completions` instead. As far as I know, this
>> respects the `completion-styles`.
> [...]
> Stefan, how does this patch look to you?
I think it replaces one set of problems with another.
Within the completion-at-point-function we shouldn't call anything like
`try-completion`: we should only decide which completion table to use
but we shouldn't look inside those completion tables.
So a better solution is to build a new completion table which combines
(e.g. with `completion-table-in-turn`) the current one with that of "the
rest". [ The tricky (but still doable) case being when when the current
completion table and that of the rest don't use the same BEG and END. ]
Stefan
Removed tag(s) patch.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 15 Aug 2020 12:22:02 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 306 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.