* bug#42101: icomplete-fido-ret doesn't always use minibuffer-default when input is empty
@ 2020-06-28 5:59 Andrew Schwartzmeyer
2020-06-28 6:36 ` bug#42101: Andy Schwartzmeyer
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Andrew Schwartzmeyer @ 2020-06-28 5:59 UTC (permalink / raw)
To: 42101
Hi,
Funny bug, haven’t figured out the cause. It may be hard to repro.
If you have some amount of minibuffer history, you can cause icomplete-fido-ret to not accept the minibuffer-default. An example is having history such that 'C-h v' when point is on ‘completion-styles’ causes ‘completion-styles-alist’ to be the first history element. Since the minibuffer-default shows ‘completion-styles’ (being that it’s under point, and I’ve not entered any text into the minibuffer), I’d expect RET to choose ‘completion-styles’, but instead it choses ‘completion-styles-alist’ (the head of the presented candidates, ‘completion-styles’ is instead the second candidate).
This repros in fido-mode, but not icomplete-mode. I took a look at the relevant functions called on RET for these modes but am having trouble finding the issue.
I think the root cause is that if minibuffer-default matches a candidate exactly, that candidate should always become the first history element, but this isn’t happening. I’m not sure why; I played around with different completion-styles but that had no effect. Regardless, if there is no input but there is minibuffer-default, various code in icomplete.el suggests that 'minibuffer-complete-and-exit’ should just be called, I don’t know why it’s not happening.
Any ideas?
Thanks,
Andy
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#42101:
2020-06-28 5:59 bug#42101: icomplete-fido-ret doesn't always use minibuffer-default when input is empty Andrew Schwartzmeyer
@ 2020-06-28 6:36 ` Andy Schwartzmeyer
[not found] ` <handler.42101.B.159332399316501.ack@debbugs.gnu.org>
2020-06-29 14:00 ` bug#42101: icomplete-fido-ret doesn't always use minibuffer-default when input is empty João Távora
2 siblings, 0 replies; 9+ messages in thread
From: Andy Schwartzmeyer @ 2020-06-28 6:36 UTC (permalink / raw)
To: 42101
[-- Attachment #1: Type: text/plain, Size: 5027 bytes --]
Okay, with some message style debugging I think I narrowed it down:
(defun icomplete-force-complete-and-exit ()
"Complete the minibuffer with the longest possible match and exit.
Use the first of the matches if there are any displayed, and use
the default otherwise."
(interactive)
;; This function is tricky. The mandate is to "force", meaning we
;; should take the first possible valid completion for the input.
;; However, if there is no input and we can prove that that
;; coincides with the default, it is much faster to just call
;; `minibuffer-complete-and-exit'. Otherwise, we have to call
;; `minibuffer-force-complete-and-exit', which needs the full
;; completion set and is potentially slow and blocking. Do the
;; latter if:
(if (or
;; there's some input, meaning the default in off the table by
;; definition; OR
(> (icomplete--field-end) (icomplete--field-beg))
;; there's no input, but there's also no minibuffer default
;; (and the user really wants to see completions on no input,
;; meaning he expects a "force" to be at least attempted); OR
(and (not minibuffer-default)
icomplete-show-matches-on-no-input)
;; there's no input but the full completion set has been
;; calculated, This causes the first cached completion to
;; be taken (i.e. the one that the user sees highlighted)
completion-all-sorted-completions)
(progn
(message (if completion-all-sorted-completions (message "completions t") (message "completions nil")))
(message (if minibuffer-default "default t" "default nil"))
(message "FORCING")
(minibuffer-force-complete-and-exit))
;; Otherwise take the faster route...
(minibuffer-complete-and-exit)))
With fido-mode, the final test in the or clause, namely 'completion-all-sorted-completions’, is t, whereas in icomplete-mode it is nil. This is causing the first cached completion to be taken (i.e. the ‘completion-styles-alist’ which probably shouldn’t be the first completion anyway). Moreover, it means that this function’s existence is being overriden: it’s never shortcutting to 'minibuffer-complete-and-exit’ for fido-mode users.
Now to find out two more things:
1. Why is the completion list not bubbling minibuffer-default to the top? (I’m using helpful-variable, but this also happens with describe-variable, and I’ve noticed it with other functions that will use a default from point.)
2. Why is 'completion-all-sorted-completions’ always t when using fido-mode?
At least for #1:
In this bit of code the minibuffer-default is compared with equal and with string-prefix-p:
(defun icomplete--sorted-completions ()
(or completion-all-sorted-completions
(cl-loop
with beg = (icomplete--field-beg)
with end = (icomplete--field-end)
with all = (completion-all-sorted-completions beg end)
for fn in (cond ((and minibuffer-default
(stringp minibuffer-default) ; bug#38992
(= (icomplete--field-end) (icomplete--field-beg)))
;; When we have a non-nil string default and
;; no input whatsoever: we want to make sure
;; that default is bubbled to the top so that
;; `icomplete-force-complete-and-exit' will
;; select it (do that even if the match
;; doesn't match the completion perfectly.
`(,(lambda (comp)
(equal minibuffer-default comp))
,(lambda (comp)
(string-prefix-p minibuffer-default comp))))
((and fido-mode
(not minibuffer-default)
(eq (icomplete--category) 'file))
;; `fido-mode' has some extra file-sorting
;; semantics even if there isn't a default,
;; which is to bubble "./" to the top if it
;; exists. This makes M-x dired RET RET go to
;; the directory of current file, which is
;; what vanilla Emacs and `ido-mode' both do.
`(,(lambda (comp)
(string= "./" comp)))))
thereis (cl-loop
for l on all
while (consp (cdr l))
for comp = (cadr l)
when (funcall fn comp)
do (setf (cdr l) (cddr l))
and return
(completion--cache-all-sorted-completions beg end (cons comp all)))
finally return all)))
I’m not sure how to get it to do so, but when there are candidates satisfying both ‘equals’ and ‘string-prefix-p’, we need to get this to prefer the former over the latter.
Cheers,
Andy
[-- Attachment #2: Type: text/html, Size: 12290 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#42101: Acknowledgement (icomplete-fido-ret doesn't always use minibuffer-default when input is empty)
[not found] ` <handler.42101.B.159332399316501.ack@debbugs.gnu.org>
@ 2020-06-29 1:48 ` Andrew Schwartzmeyer
2020-06-29 13:52 ` João Távora
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Schwartzmeyer @ 2020-06-29 1:48 UTC (permalink / raw)
To: 42101; +Cc: João Távora
Hi João, here’s that CC to get into the bug report. I’m sorry I don’t know how debbugs works! I had to actually disable my email provider’s TLS sending guarantee to send this email…maybe one day we’ll see GNU Emacs on GitHub or something :)
Thanks,
Andy
> On Jun 27, 2020, at 11:00 PM, GNU bug Tracking System <help-debbugs@gnu.org> wrote:
>
> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
> bug-gnu-emacs@gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 42101@debbugs.gnu.org.
>
> Please do not send mail to help-debbugs@gnu.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 42101: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=42101
> GNU Bug Tracking System
> Contact help-debbugs@gnu.org with problems
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#42101: Acknowledgement (icomplete-fido-ret doesn't always use minibuffer-default when input is empty)
2020-06-29 1:48 ` bug#42101: Acknowledgement (icomplete-fido-ret doesn't always use minibuffer-default when input is empty) Andrew Schwartzmeyer
@ 2020-06-29 13:52 ` João Távora
2020-06-30 1:41 ` Richard Stallman
0 siblings, 1 reply; 9+ messages in thread
From: João Távora @ 2020-06-29 13:52 UTC (permalink / raw)
To: Andrew Schwartzmeyer; +Cc: 42101
Andrew Schwartzmeyer <andrew@schwartzmeyer.com> writes:
> Hi João, here’s that CC to get into the bug report. I’m sorry I don’t
> know how debbugs works! I had to actually disable my email provider’s
> TLS sending guarantee to send this email…
This is very odd. it should be as simple as sending an email message to
to 42101@debbugs.gnu.org, in this case. No idea if that violate any
"TLS sending guarantees".
> maybe one day we’ll see GNU Emacs on GitHub or something :)
I lean towards the "or something".
As to the actual bug, I'll try to look at it soon.
João
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#42101: icomplete-fido-ret doesn't always use minibuffer-default when input is empty
2020-06-28 5:59 bug#42101: icomplete-fido-ret doesn't always use minibuffer-default when input is empty Andrew Schwartzmeyer
2020-06-28 6:36 ` bug#42101: Andy Schwartzmeyer
[not found] ` <handler.42101.B.159332399316501.ack@debbugs.gnu.org>
@ 2020-06-29 14:00 ` João Távora
2020-07-04 5:22 ` Andrew Schwartzmeyer
2 siblings, 1 reply; 9+ messages in thread
From: João Távora @ 2020-06-29 14:00 UTC (permalink / raw)
To: Andrew Schwartzmeyer; +Cc: 42101
Andrew Schwartzmeyer <andrew@schwartzmeyer.com> writes:
> Hi,
>
> Funny bug, haven’t figured out the cause. It may be hard to repro.
>
> If you have some amount of minibuffer history, you can cause
> icomplete-fido-ret to not accept the minibuffer-default. An example is
> having history such that 'C-h v' when point is on ‘completion-styles’
> causes ‘completion-styles-alist’ to be the first history
> element. Since the minibuffer-default shows ‘completion-styles’ (being
> that it’s under point, and I’ve not entered any text into the
> minibuffer), I’d expect RET to choose ‘completion-styles’, but instead
> it choses ‘completion-styles-alist’ (the head of the presented
> candidates, ‘completion-styles’ is instead the second candidate).
>
> This repros in fido-mode, but not icomplete-mode. I took a look at the
> relevant functions called on RET for these modes but am having trouble
> finding the issue.
I can't reproduce this. I think the first step is for you to try to
identify which sequence of actions as performed from an Emacs
session started with -Q lead to the problem. For the record, I tried
Emacs -Q (master of around two weeks ago)
C-h v completion-styles RET
C-h v completion-styles-alist RET
type "completion-styles" in *scratch* buffer. With cursor on word.
C-h v RET (quickly, before the completions appear)
C-h v RET (slowly, letting the completions appear)
Both approaches lead to the variable `completion-styles` being
described.
João
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#42101: Acknowledgement (icomplete-fido-ret doesn't always use minibuffer-default when input is empty)
2020-06-29 13:52 ` João Távora
@ 2020-06-30 1:41 ` Richard Stallman
0 siblings, 0 replies; 9+ messages in thread
From: Richard Stallman @ 2020-06-30 1:41 UTC (permalink / raw)
To: João Távora; +Cc: andrew, 42101
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > maybe one day we’ll see GNU Emacs on GitHub or something :)
> I lean towards the "or something".
Here's why it can't be Github:
https://www.gnu.org/software/repo-criteria-evaluation.html.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#42101: icomplete-fido-ret doesn't always use minibuffer-default when input is empty
2020-06-29 14:00 ` bug#42101: icomplete-fido-ret doesn't always use minibuffer-default when input is empty João Távora
@ 2020-07-04 5:22 ` Andrew Schwartzmeyer
[not found] ` <FDB51F0D-4611-4146-BA7A-6FD6AA566442@schwartzmeyer.com>
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Schwartzmeyer @ 2020-07-04 5:22 UTC (permalink / raw)
To: João Távora; +Cc: 42101
[-- Attachment #1: Type: text/plain, Size: 3386 bytes --]
I’m sorry so João, I had sent you a repro last week, but it again didn’t go through.
It appears I have to leave TLS-sending guarantees disabled because the debbugs mail server is insecurely configured (for others who may be reading but offering no useful input, this is a security issue that does not exist with GitHub or other similar software). Perhaps we should move to emacs-devel which at least accepts email sent over TLS.
Anyway, I can repro this in emacs -Q with:
(defun fido-mode+ ()
(setq-local completion-styles '(basic)))
(add-hook 'icomplete-minibuffer-setup-hook #'fido-mode+)
(fido-mode)
Basically (heh) this happens if the “basic” completion-style is used (or “partial-completion” or “substring” or any combination including one of those styles).
It only doesn’t repro if “flex” is used by itself (the default for fido-mode, but should be able to be overridden).
This also repros with icomplete-mode if “icomplete-show-matches-on-no-input” is t, as in:
(defun fido-mode+ ()
(setq-local completion-styles '(basic)
icomplete-show-matches-on-no-input t))
(add-hook 'icomplete-minibuffer-setup-hook #'fido-mode+)
(icomplete-mode)
Which explains why it’s readily apparent in fido-mode, where that’s set to t already. Unfortunately, I still have no clue how to fix it. I would appreciate your help! Being able to use the default styles in addition to flex makes the fido-mode experience smoother, because they return defaults for no input much faster, I find them to be more predictable, and it’s when they fail that flex tends to shine most.
Thanks,
Andy
> On Jun 29, 2020, at 7:00 AM, João Távora <joaotavora@gmail.com> wrote:
>
> Andrew Schwartzmeyer <andrew@schwartzmeyer.com <mailto:andrew@schwartzmeyer.com>> writes:
>
>> Hi,
>>
>> Funny bug, haven’t figured out the cause. It may be hard to repro.
>>
>> If you have some amount of minibuffer history, you can cause
>> icomplete-fido-ret to not accept the minibuffer-default. An example is
>> having history such that 'C-h v' when point is on ‘completion-styles’
>> causes ‘completion-styles-alist’ to be the first history
>> element. Since the minibuffer-default shows ‘completion-styles’ (being
>> that it’s under point, and I’ve not entered any text into the
>> minibuffer), I’d expect RET to choose ‘completion-styles’, but instead
>> it choses ‘completion-styles-alist’ (the head of the presented
>> candidates, ‘completion-styles’ is instead the second candidate).
>>
>> This repros in fido-mode, but not icomplete-mode. I took a look at the
>> relevant functions called on RET for these modes but am having trouble
>> finding the issue.
>
> I can't reproduce this. I think the first step is for you to try to
> identify which sequence of actions as performed from an Emacs
> session started with -Q lead to the problem. For the record, I tried
>
> Emacs -Q (master of around two weeks ago)
>
> C-h v completion-styles RET
> C-h v completion-styles-alist RET
>
> type "completion-styles" in *scratch* buffer. With cursor on word.
>
> C-h v RET (quickly, before the completions appear)
> C-h v RET (slowly, letting the completions appear)
>
> Both approaches lead to the variable `completion-styles` being
> described.
>
> João
[-- Attachment #2: Type: text/html, Size: 17433 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#42101: icomplete-fido-ret doesn't always use minibuffer-default when input is empty
[not found] ` <FDB51F0D-4611-4146-BA7A-6FD6AA566442@schwartzmeyer.com>
@ 2020-07-04 9:35 ` João Távora
2020-07-26 4:11 ` Andrew Schwartzmeyer
0 siblings, 1 reply; 9+ messages in thread
From: João Távora @ 2020-07-04 9:35 UTC (permalink / raw)
To: Andrew Schwartzmeyer; +Cc: 42101
[-- Attachment #1: Type: text/plain, Size: 272 bytes --]
Schwartzmeyer <andrew@schwartzmeyer.com> wrote
> Any clue?
I'm sorry Andrew haven't had time to look into it yet, but your analyses
help. Just note that Fido-mode is indeed geared primarily to working with
flex. But it should be customizable of course.
João
[-- Attachment #2: Type: text/html, Size: 548 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#42101: icomplete-fido-ret doesn't always use minibuffer-default when input is empty
2020-07-04 9:35 ` João Távora
@ 2020-07-26 4:11 ` Andrew Schwartzmeyer
0 siblings, 0 replies; 9+ messages in thread
From: Andrew Schwartzmeyer @ 2020-07-26 4:11 UTC (permalink / raw)
To: João Távora; +Cc: 42101
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]
This bug can be fixed by deleting the expression:
,(lambda (comp)
(string-prefix-p minibuffer-default comp))
from icomplete--sorted-completions.
But it’s obviously there for some reason, so idk.
> On Jul 4, 2020, at 2:35 AM, João Távora <joaotavora@gmail.com> wrote:
>
> Schwartzmeyer <andrew@schwartzmeyer.com <mailto:andrew@schwartzmeyer.com>> wrote
>
> > Any clue?
>
> I'm sorry Andrew haven't had time to look into it yet, but your analyses help. Just note that Fido-mode is indeed geared primarily to working with flex. But it should be customizable of course.
>
> João
[-- Attachment #2: Type: text/html, Size: 1589 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-07-26 4:11 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-06-28 5:59 bug#42101: icomplete-fido-ret doesn't always use minibuffer-default when input is empty Andrew Schwartzmeyer
2020-06-28 6:36 ` bug#42101: Andy Schwartzmeyer
[not found] ` <handler.42101.B.159332399316501.ack@debbugs.gnu.org>
2020-06-29 1:48 ` bug#42101: Acknowledgement (icomplete-fido-ret doesn't always use minibuffer-default when input is empty) Andrew Schwartzmeyer
2020-06-29 13:52 ` João Távora
2020-06-30 1:41 ` Richard Stallman
2020-06-29 14:00 ` bug#42101: icomplete-fido-ret doesn't always use minibuffer-default when input is empty João Távora
2020-07-04 5:22 ` Andrew Schwartzmeyer
[not found] ` <FDB51F0D-4611-4146-BA7A-6FD6AA566442@schwartzmeyer.com>
2020-07-04 9:35 ` João Távora
2020-07-26 4:11 ` Andrew Schwartzmeyer
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).