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

["João Távora" <joaotavora@gmail.com>]

On Sat, Jan 19, 2019 at 2:31 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> >>> Yes, it elegantly fixes this bug, but complicates #34077.
> >> I don't see why.  Can you explain?
> > If I do that, then C-M-i will still cycle/rotate after completing say,
> > '/emacs/sr' to '/emacs/src', which means that
> > completion-all-sorted-completions, used by the prospects, listing is
> > still forcibly cached by minibuffer-force-complete.
>
> Right, but the patch doesn't affect minibuffer-force-complete at all, so
> it doesn't make the problem any harder, does it?

No but to solve the other problem, I still need the DONT-CYCLE hack.
What I should have said is "this doesn't solve my other problem".
Indeed it doesn't make it any harder.

But what about this which solves both problems bug#34077
and bug#34116?

diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index 6d77c0649a..562da1a71d 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -145,7 +145,7 @@ icomplete-post-command-hook

 (defvar icomplete-minibuffer-map
   (let ((map (make-sparse-keymap)))
-    (define-key map [?\M-\t] 'minibuffer-force-complete)
+    (define-key map [?\M-\t] 'icomplete-force-complete)
     (define-key map [?\C-j]  'icomplete-force-complete-and-exit)
     (define-key map [?\C-.]  'icomplete-forward-completions)
     (define-key map [?\C-,]  'icomplete-backward-completions)
@@ -162,6 +162,21 @@ icomplete-force-complete-and-exit
       (minibuffer-force-complete-and-exit)
     (minibuffer-complete-and-exit)))

+(defun icomplete-force-complete ()
+  "Complete the icomplete minibuffer."
+  (interactive)
+  (let ((retval (minibuffer-force-complete)))
+    ;; FIXME: What's this you ask?  Do deal with a cycling corner
+    ;; case, `minibuffer-force-complete' will replace the keybinding
+    ;; that `icomplete-force-complete' was called with, but at least
+    ;; returns a function which we can call to disable that, since
+    ;; we're not interested in cycling at all here (bug#34077).
+    (when (and completion-cycling (functionp retval)) (funcall retval)))
+  ;; Again, since we're not interested in cycling, we want prospects
+  ;; to be recalcualted, and not based on cached, rotated completions.
+  (setq completion-cycling nil)
+  (setq completion-all-sorted-completions nil))
+
 (defun icomplete-forward-completions ()
   "Step forward completions by one entry.
 Second entry becomes the first and can be selected with
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 5760a2e49d..b06f13251f 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1257,7 +1257,12 @@ completion-all-sorted-completions
 (defun minibuffer-force-complete-and-exit ()
   "Complete the minibuffer with first of the matches and exit."
   (interactive)
-  (minibuffer-force-complete)
+  ;; If `completion-cycling' is t, then surely a
+  ;; `minibuffer-force-complete' has already executed.  This is not
+  ;; for speed: the extra rotation caused by the second unnecessary call
+  ;; would mess up the final result value (bug#34116).
+  (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