bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#34116: 27.0.50; minibuffer-force-complete-and-exit mostly broken


From: Stefan Monnier
Subject: bug#34116: 27.0.50; minibuffer-force-complete-and-exit mostly broken
Date: Fri, 18 Jan 2019 08:09:15 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> It seems to work most of the times, but I could swear it is
> is doing mischief in some situations (can't tell which tho).

I can believe it.

> Other arguments against it is that it shouldn't be necessary
> to query the table again by this point, which is potentially
> slow and could have side effects depending on the table.

test-completion should be pretty fast (and it's called by the subsequent
completion--complete-and-exit so no matter how slow, adding a call
cannot slowdown the command by more than a factor 2x).

> In other words, there is some arguably poorly chosen cons
> juggling going on in minibuffer-force-complete.  My fix adds
> to that, but at least it stays within the same idiom.

I must admit that I find your fix a bit ugly (adding an ad-hoc extra
arg, then undoing cycling depending on (and dont-cycle
completion-cycling), ...).

Taking another look at the problem, I believe the change below is the
better option.  Any objection?


        Stefan


diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index db8d4ba5ce..879ad9a8f7 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1378,7 +1381,8 @@ completion-all-sorted-completions
 (defun minibuffer-force-complete-and-exit ()
   "Complete the minibuffer with first of the matches and exit."
   (interactive)
-  (minibuffer-force-complete)
+  (unless completion-cycling
+    (minibuffer-force-complete))
   (completion--complete-and-exit
    (minibuffer-prompt-end) (point-max) #'exit-minibuffer
    ;; If the previous completion completed to an element which fails





reply via email to

[Prev in Thread] Current Thread [Next in Thread]