* 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
[parent not found: <handler.42101.B.159332399316501.ack@debbugs.gnu.org>]
* 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: 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-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: 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
[parent not found: <FDB51F0D-4611-4146-BA7A-6FD6AA566442@schwartzmeyer.com>]
* 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 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.