GNU bug report logs - #62700
29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 62700 in the body.
You can then email your comments to 62700 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Cc: Juri Linkov <juri <at> linkov.net>
Subject: 29.0.60; minibuffer-{previous,next,choose}-completion behave
 unintuitively when point is not at end of buffer
Date: Thu, 06 Apr 2023 13:56:35 -0400

1. emacs -Q
2. C-h v -path
3. <tab> to show completions of variables containing the string -path
4. Use M-<up> and M-<down> to switch between completions.  Note that as
you switch completions, they replace the text already in the minibuffer.
5. C-g

6. C-h v -path
7. C-a to move point to before -path
8. <tab> to show completions of variables ending in -path
9. Use M-<up> and M-<down> to switch between completions.  Now as you
switch completions, they are inserted at point, *without* replacing the
text already in the buffer.  So e.g. the minibuffer will contain
"load-path-path".
10. Likewise, if you (setq minibuffer-completion-auto-choose nil), M-RET
inserts the completion string at point, without replacing the text in
the minibuffer, so you will get "load-path-path".

I think this is basically just a bug.  Hopefully we can fix this before
Emacs 29 is released, because this is the last thing which stops these
new commands from being a really great improvement to the Emacs
completion defaults.

If this is intentional for some reason, I think the behavior should
definitely be changed before Emacs 29 is released.  Moving point around
in the minibuffer while completing is an important part of using the
default completion-styles, so we should not make that harder.  Other
completion packages for Emacs do not have this behavior, e.g. icomplete
or ido.


In GNU Emacs 29.0.60 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2023-03-13 built on
 igm-qws-u22796a
Repository revision: e759905d2e0828eac4c8164b09113b40f6899656
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: CentOS Linux 7 (Core)

Configured using:
 'configure --with-x-toolkit=lucid --with-modules
 --with-gif=ifavailable'

Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND
SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM LUCID
ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Dired by name

Minor modes in effect:
  jane-fe-minor-mode: t
  editorconfig-mode: t
  dired-omit-mode: t
  which-function-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  shell-dirtrack-mode: t
  windmove-mode: t
  savehist-mode: t
  save-place-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tab-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/csharp-mode hides /home/sbaugh/.local/src/emacs29/lisp/progmodes/csharp-mode
/usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/eldoc hides /home/sbaugh/.local/src/emacs29/lisp/emacs-lisp/eldoc
/usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/auctex/lpath hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/dictionary/lpath
/home/sbaugh/.local/src/emacs29/lisp/net/dictionary hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/dictionary/dictionary
/usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/caml-font hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/ocaml/caml-font
/home/sbaugh/.local/src/emacs29/lisp/org/org-version hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-version
/home/sbaugh/.local/src/emacs29/lisp/org/org-loaddefs hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-loaddefs
/home/sbaugh/.local/src/emacs29/lisp/org/org-keys hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-keys
/home/sbaugh/.local/src/emacs29/lisp/org/ol hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ol
/home/sbaugh/.local/src/emacs29/lisp/org/ob-perl hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-perl
/home/sbaugh/.local/src/emacs29/lisp/org/ob-core hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-core
/home/sbaugh/.local/src/emacs29/lisp/org/ox hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ox
/home/sbaugh/.local/src/emacs29/lisp/org/ol-rmail hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ol-rmail
/home/sbaugh/.local/src/emacs29/lisp/org/ob-octave hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-octave
/home/sbaugh/.local/src/emacs29/lisp/org/ob-comint hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-comint
/home/sbaugh/.local/src/emacs29/lisp/org/ol-w3m hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ol-w3m
/home/sbaugh/.local/src/emacs29/lisp/org/ob-org hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-org
/home/sbaugh/.local/src/emacs29/lisp/org/ox-texinfo hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ox-texinfo
/home/sbaugh/.local/src/emacs29/lisp/org/org-inlinetask hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-inlinetask
/home/sbaugh/.local/src/emacs29/lisp/org/ol-mhe hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ol-mhe
/home/sbaugh/.local/src/emacs29/lisp/org/ob-ocaml hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-ocaml
/home/sbaugh/.local/src/emacs29/lisp/org/ob-clojure hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-clojure
/home/sbaugh/.local/src/emacs29/lisp/org/ox-publish hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ox-publish
/home/sbaugh/.local/src/emacs29/lisp/org/ol-irc hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ol-irc
/home/sbaugh/.local/src/emacs29/lisp/org/ob-calc hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-calc
/home/sbaugh/.local/src/emacs29/lisp/org/ox-odt hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ox-odt
/home/sbaugh/.local/src/emacs29/lisp/org/org-id hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-id
/home/sbaugh/.local/src/emacs29/lisp/org/ol-gnus hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ol-gnus
/home/sbaugh/.local/src/emacs29/lisp/org/ob-matlab hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-matlab
/home/sbaugh/.local/src/emacs29/lisp/org/ox-icalendar hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ox-icalendar
/home/sbaugh/.local/src/emacs29/lisp/org/org-footnote hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-footnote
/home/sbaugh/.local/src/emacs29/lisp/org/ol-bibtex hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ol-bibtex
/home/sbaugh/.local/src/emacs29/lisp/org/ob-lisp hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-lisp
/home/sbaugh/.local/src/emacs29/lisp/org/ob-C hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-C
/home/sbaugh/.local/src/emacs29/lisp/org/ox-org hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ox-org
/home/sbaugh/.local/src/emacs29/lisp/org/org-indent hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-indent
/home/sbaugh/.local/src/emacs29/lisp/org/ol-info hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ol-info
/home/sbaugh/.local/src/emacs29/lisp/org/ob-maxima hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-maxima
/home/sbaugh/.local/src/emacs29/lisp/org/ob-awk hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-awk
/home/sbaugh/.local/src/emacs29/lisp/org/ox-man hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ox-man
/home/sbaugh/.local/src/emacs29/lisp/org/org-goto hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-goto
/home/sbaugh/.local/src/emacs29/lisp/org/ox-md hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ox-md
/home/sbaugh/.local/src/emacs29/lisp/org/ol-eshell hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ol-eshell
/home/sbaugh/.local/src/emacs29/lisp/org/ob-lua hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-lua
/home/sbaugh/.local/src/emacs29/lisp/org/org-habit hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-habit
/home/sbaugh/.local/src/emacs29/lisp/org/ob-R hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-R
/home/sbaugh/.local/src/emacs29/lisp/org/ol-eww hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ol-eww
/home/sbaugh/.local/src/emacs29/lisp/org/ob-makefile hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-makefile
/home/sbaugh/.local/src/emacs29/lisp/org/ox-latex hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ox-latex
/home/sbaugh/.local/src/emacs29/lisp/org/ol-docview hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ol-docview
/home/sbaugh/.local/src/emacs29/lisp/org/ob-lob hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-lob
/home/sbaugh/.local/src/emacs29/lisp/org/ox-beamer hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ox-beamer
/home/sbaugh/.local/src/emacs29/lisp/org/org-faces hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-faces
/home/sbaugh/.local/src/emacs29/lisp/org/ob hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob
/home/sbaugh/.local/src/emacs29/lisp/org/ox-html hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ox-html
/home/sbaugh/.local/src/emacs29/lisp/org/org-feed hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-feed
/home/sbaugh/.local/src/emacs29/lisp/org/ol-bbdb hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ol-bbdb
/home/sbaugh/.local/src/emacs29/lisp/org/ob-lilypond hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-lilypond
/home/sbaugh/.local/src/emacs29/lisp/org/ox-ascii hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ox-ascii
/home/sbaugh/.local/src/emacs29/lisp/org/ob-latex hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-latex
/home/sbaugh/.local/src/emacs29/lisp/org/org hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org
/home/sbaugh/.local/src/emacs29/lisp/org/ob-tangle hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-tangle
/home/sbaugh/.local/src/emacs29/lisp/org/org-tempo hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-tempo
/home/sbaugh/.local/src/emacs29/lisp/org/org-duration hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-duration
/home/sbaugh/.local/src/emacs29/lisp/org/ob-sqlite hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-sqlite
/home/sbaugh/.local/src/emacs29/lisp/org/org-entities hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-entities
/home/sbaugh/.local/src/emacs29/lisp/org/ob-table hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-table
/home/sbaugh/.local/src/emacs29/lisp/org/ob-js hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-js
/home/sbaugh/.local/src/emacs29/lisp/org/org-table hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-table
/home/sbaugh/.local/src/emacs29/lisp/org/ob-sql hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-sql
/home/sbaugh/.local/src/emacs29/lisp/org/org-timer hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-timer
/home/sbaugh/.local/src/emacs29/lisp/org/org-element hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-element
/home/sbaugh/.local/src/emacs29/lisp/org/ob-java hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-java
/home/sbaugh/.local/src/emacs29/lisp/org/org-ctags hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-ctags
/home/sbaugh/.local/src/emacs29/lisp/org/ob-shell hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-shell
/home/sbaugh/.local/src/emacs29/lisp/org/ob-groovy hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-groovy
/home/sbaugh/.local/src/emacs29/lisp/org/org-src hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-src
/home/sbaugh/.local/src/emacs29/lisp/org/org-datetree hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-datetree
/home/sbaugh/.local/src/emacs29/lisp/org/ob-haskell hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-haskell
/home/sbaugh/.local/src/emacs29/lisp/org/org-plot hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-plot
/home/sbaugh/.local/src/emacs29/lisp/org/org-compat hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-compat
/home/sbaugh/.local/src/emacs29/lisp/org/ob-screen hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-screen
/home/sbaugh/.local/src/emacs29/lisp/org/ob-fortran hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-fortran
/home/sbaugh/.local/src/emacs29/lisp/org/org-protocol hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-protocol
/home/sbaugh/.local/src/emacs29/lisp/org/org-crypt hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-crypt
/home/sbaugh/.local/src/emacs29/lisp/org/ob-sed hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-sed
/home/sbaugh/.local/src/emacs29/lisp/org/ob-gnuplot hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-gnuplot
/home/sbaugh/.local/src/emacs29/lisp/org/org-pcomplete hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-pcomplete
/home/sbaugh/.local/src/emacs29/lisp/org/org-colview hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-colview
/home/sbaugh/.local/src/emacs29/lisp/org/ob-scheme hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-scheme
/home/sbaugh/.local/src/emacs29/lisp/org/ob-forth hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-forth
/home/sbaugh/.local/src/emacs29/lisp/org/org-num hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-num
/home/sbaugh/.local/src/emacs29/lisp/org/org-clock hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-clock
/home/sbaugh/.local/src/emacs29/lisp/org/ob-exp hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-exp
/home/sbaugh/.local/src/emacs29/lisp/org/org-mouse hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-mouse
/home/sbaugh/.local/src/emacs29/lisp/org/org-capture hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-capture
/home/sbaugh/.local/src/emacs29/lisp/org/ob-sass hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-sass
/home/sbaugh/.local/src/emacs29/lisp/org/ob-eval hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-eval
/home/sbaugh/.local/src/emacs29/lisp/org/ob-ref hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-ref
/home/sbaugh/.local/src/emacs29/lisp/org/ob-emacs-lisp hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-emacs-lisp
/home/sbaugh/.local/src/emacs29/lisp/org/org-mobile hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-mobile
/home/sbaugh/.local/src/emacs29/lisp/org/ob-ruby hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-ruby
/home/sbaugh/.local/src/emacs29/lisp/org/ob-eshell hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-eshell
/home/sbaugh/.local/src/emacs29/lisp/org/org-lint hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-lint
/home/sbaugh/.local/src/emacs29/lisp/org/org-agenda hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-agenda
/home/sbaugh/.local/src/emacs29/lisp/org/org-macro hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-macro
/home/sbaugh/.local/src/emacs29/lisp/org/org-attach-git hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-attach-git
/home/sbaugh/.local/src/emacs29/lisp/org/ob-processing hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-processing
/home/sbaugh/.local/src/emacs29/lisp/org/ob-css hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-css
/home/sbaugh/.local/src/emacs29/lisp/org/ob-dot hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-dot
/home/sbaugh/.local/src/emacs29/lisp/org/org-list hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-list
/home/sbaugh/.local/src/emacs29/lisp/org/org-macs hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-macs
/home/sbaugh/.local/src/emacs29/lisp/org/org-attach hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-attach
/home/sbaugh/.local/src/emacs29/lisp/org/org-archive hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/org-archive
/home/sbaugh/.local/src/emacs29/lisp/org/ob-python hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-python
/home/sbaugh/.local/src/emacs29/lisp/org/ob-plantuml hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-plantuml
/home/sbaugh/.local/src/emacs29/lisp/org/ob-ditaa hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/lisp/ob-ditaa
/home/sbaugh/.local/src/emacs29/lisp/org/ob-julia hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/contrib/lisp/ob-julia
/home/sbaugh/.local/src/emacs29/lisp/org/ol-man hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/contrib/lisp/ol-man
/home/sbaugh/.local/src/emacs29/lisp/org/ox-koma-letter hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/org/contrib/lisp/ox-koma-letter
/home/sbaugh/.emacs.d/elpa/dash-2.19.1/dash hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/dash/dash
/home/sbaugh/.emacs.d/elpa/dash-2.19.1/dash-functional hides /usr/local/home/sbaugh/workspaces/fe-47828/+share+/app/emacs/elisp/contrib/dash/dash-functional

Features:
(shadow sort mail-extr emacsbug tabify cal-iso org-datetree org-capture
pcmpl-unix pcmpl-gnu dabbrev log-view vc vc-git vc-dispatcher
bug-reference shortdoc cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs dired-aux pulse misearch
multi-isearch org-element org-persist org-id org-refile avl-tree
generator oc-basic ol-eww eww xdg url-queue mm-url ol-rmail ol-mhe
ol-irc ol-info ol-gnus nnselect gnus-art mm-uu mml2015 mm-view mml-smime
smime gnutls dig gnus-sum shr pixel-fill kinsoku url-file svg dom
gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap
nnmail mail-source utf7 nnoo gnus-spec gnus-int gnus-range gnus-win gnus
nnheader range wid-edit ol-docview doc-view jka-compr image-mode exif
ol-bibtex bibtex ol-bbdb ol-w3m ol-doi org-link-doi find-dired sh-script
treesit executable goto-addr hl-line display-line-numbers cl-print
completion help-fns radix-tree vc-hg tramp tramp-loaddefs trampver
tramp-integration files-x tramp-compat parse-time iso8601 ls-lisp
jane-project jane-merlin merlin-imenu merlin-xref xref merlin-cap merlin
jane-async-merlin jane-completion jane-common jane-fe-menu ecaml_plugin
linum view gopcaml magit-bookmark bookmark image+ advice image-file
image-converter editorconfig editorconfig-core editorconfig-core-handle
editorconfig-fnmatch whitespace jane-auto-modes vba-mode markdown-mode
color jane jane-micro-features grep jane-diff unified-test-mode
shell-file core core-buffer core-error core-util ert pp ewoc debug
backtrace jane-sexp jane-ocaml jane-tuareg-theme tuareg tuareg-compat
tuareg-opam skeleton flymake-proc flymake warnings smie caml-types
caml-help caml-emacs find-file compile jane-cr jane-align
jane-deprecated jane-smerge gnu-elpa-keyring-update jane-ocp-indent
ocp-indent cl jane-util page-ext dired-x magit-extras project
magit-submodule magit-obsolete magit-blame magit-stash magit-reflog
magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote
magit-commit magit-sequence magit-notes magit-worktree magit-tag
magit-merge magit-branch magit-reset magit-files magit-refs magit-status
magit magit-repos magit-apply magit-wip magit-log which-func imenu
magit-diff smerge-mode diff diff-mode git-commit log-edit message
sendmail yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa
derived epg rfc6068 epg-config gnus-util text-property-search mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
pcvs-util add-log magit-core magit-autorevert autorevert filenotify
magit-margin magit-transient magit-process with-editor shell server
magit-mode transient edmacro kmacro magit-git magit-section magit-utils
crm dash cl-extra help-mode windmove org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-src ob-comint org-pcomplete pcomplete
org-list org-footnote org-faces org-entities time-date noutline outline
icons ob-emacs-lisp ob-core ob-eval org-cycle org-table ol rx org-fold
org-fold-core org-keys oc org-loaddefs find-func cal-menu calendar
cal-loaddefs org-version org-compat org-macs format-spec gdb-mi bindat
gud easy-mmode comint ansi-osc ansi-color ring ffap thingatpt vundo
pcase cyberpunk-theme savehist saveplace vundo-autoloads magit-autoloads
csv-mode-autoloads magit-section-autoloads cyberpunk-theme-autoloads
url-http-ntlm-autoloads url-auth git-commit-autoloads
with-editor-autoloads finder-inf info dash-autoloads package browse-url
url url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo x-toolkit xinput2 x multi-tty
make-network-process emacs)

Memory information:
((conses 16 583321 56900)
 (symbols 48 44810 0)
 (strings 32 158814 5579)
 (string-bytes 1 5346908)
 (vectors 16 80875)
 (vector-slots 8 1651451 169545)
 (floats 8 540 459)
 (intervals 56 11200 1394)
 (buffers 976 38)
 (heap 1024 63482 7231))

Message #8 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 62700 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively
 when point is not at end of buffer
Date: Thu, 06 Apr 2023 21:22:42 +0300

> Cc: Juri Linkov <juri <at> linkov.net>
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Thu, 06 Apr 2023 13:56:35 -0400
> 
> 6. C-h v -path
> 7. C-a to move point to before -path
> 8. <tab> to show completions of variables ending in -path
> 9. Use M-<up> and M-<down> to switch between completions.  Now as you
> switch completions, they are inserted at point, *without* replacing the
> text already in the buffer.  So e.g. the minibuffer will contain
> "load-path-path".
> 10. Likewise, if you (setq minibuffer-completion-auto-choose nil), M-RET
> inserts the completion string at point, without replacing the text in
> the minibuffer, so you will get "load-path-path".
> 
> I think this is basically just a bug.

I think it's the intended behavior.  In this case, it looks not
useful, because the string you typed before starting to use M-<UP> and
M-<DOWN> happens to be at the end of each completion candidate.  But
this is not the only situation possible.  Basically, completion always
modifies only the text before point, leaving what's after point
intact, so that the user could have after point stuff that completion
should ignore, and that eventually will be appended to the selected
candidate.

> Hopefully we can fix this before Emacs 29 is released, because this
> is the last thing which stops these new commands from being a really
> great improvement to the Emacs completion defaults.

Why did you need to move point to the beginning of what you typed to
begin with?  Unless you explain that, I don't see how we can consider
this issue important enough to fix at all, let alone for Emacs 29.

> If this is intentional for some reason, I think the behavior should
> definitely be changed before Emacs 29 is released.  Moving point around
> in the minibuffer while completing is an important part of using the
> default completion-styles

It is? why?

Message #11 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Thu, 06 Apr 2023 14:58:42 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: Juri Linkov <juri <at> linkov.net>
>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Date: Thu, 06 Apr 2023 13:56:35 -0400
>> 
>> 6. C-h v -path
>> 7. C-a to move point to before -path
>> 8. <tab> to show completions of variables ending in -path
>> 9. Use M-<up> and M-<down> to switch between completions.  Now as you
>> switch completions, they are inserted at point, *without* replacing the
>> text already in the buffer.  So e.g. the minibuffer will contain
>> "load-path-path".
>> 10. Likewise, if you (setq minibuffer-completion-auto-choose nil), M-RET
>> inserts the completion string at point, without replacing the text in
>> the minibuffer, so you will get "load-path-path".
>> 
>> I think this is basically just a bug.
>
> I think it's the intended behavior.  In this case, it looks not
> useful, because the string you typed before starting to use M-<UP> and
> M-<DOWN> happens to be at the end of each completion candidate.  But
> this is not the only situation possible.  Basically, completion always
> modifies only the text before point, leaving what's after point
> intact, so that the user could have after point stuff that completion
> should ignore, and that eventually will be appended to the selected
> candidate.

Could you give an example of when this would be desirable?

>> Hopefully we can fix this before Emacs 29 is released, because this
>> is the last thing which stops these new commands from being a really
>> great improvement to the Emacs completion defaults.
>
> Why did you need to move point to the beginning of what you typed to
> begin with?  Unless you explain that, I don't see how we can consider
> this issue important enough to fix at all, let alone for Emacs 29.
>
>> If this is intentional for some reason, I think the behavior should
>> definitely be changed before Emacs 29 is released.  Moving point around
>> in the minibuffer while completing is an important part of using the
>> default completion-styles
>
> It is? why?

"basic" and "emacs22" are default completion-styles, and they both treat
text after point differently from text before point.

For example, suppose I wanted to wanted to complete filenames starting
with x and ending in .c.  The way I would do this with the default
completion-styles is enter "x.c", placing point just before ".", and hit
TAB.  (I could equivalently do x*.c and hit TAB, but that will move
point to right after the "*" and run into this same issue!)

Actually, * is another good example.  If I input a * in my string to be
completed (which is provided by partial-completion, a default
completion-style), then when I hit TAB point is moved back to the site
of the *.  This makes * very hard to use at the same time as
minibuffer-{previous,next}-completion, because of their behavior of not
modifying the text after point.

Message #14 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 62700 <at> debbugs.gnu.org
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave
 unintuitively when point is not at end of buffer
Date: Thu, 06 Apr 2023 21:55:48 +0300

> 6. C-h v -path
> 7. C-a to move point to before -path
> 8. <tab> to show completions of variables ending in -path
> 9. Use M-<up> and M-<down> to switch between completions.  Now as you
> switch completions, they are inserted at point, *without* replacing the
> text already in the buffer.  So e.g. the minibuffer will contain
> "load-path-path".
> 10. Likewise, if you (setq minibuffer-completion-auto-choose nil), M-RET
> inserts the completion string at point, without replacing the text in
> the minibuffer, so you will get "load-path-path".
>
> I think this is basically just a bug.  Hopefully we can fix this before
> Emacs 29 is released, because this is the last thing which stops these
> new commands from being a really great improvement to the Emacs
> completion defaults.

I agree that it would be nice to fix this in Emacs 29.
But the problem is that this would require non-trivial changes.
We need to apply a small part of the patch mentioned in
bug#47711, bug#48356, bug#48841, bug#60313 and located at
https://lists.gnu.org/archive/html/emacs-devel/2021-08/msg00412.html
that implements the following FIXME item in 'completion-all-completions':

  ;; FIXME: We need to additionally return the info needed for the
  ;; second part of completion-base-position.

When it will return from 'completion-all-completions' not only the start
position of a completion, but also its end, then we could use this
additional information for M-<up> and M-<down>.

Message #17 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62700 <at> debbugs.gnu.org
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Thu, 06 Apr 2023 15:22:49 -0400

Juri Linkov <juri <at> linkov.net> writes:
>> 6. C-h v -path
>> 7. C-a to move point to before -path
>> 8. <tab> to show completions of variables ending in -path
>> 9. Use M-<up> and M-<down> to switch between completions.  Now as you
>> switch completions, they are inserted at point, *without* replacing the
>> text already in the buffer.  So e.g. the minibuffer will contain
>> "load-path-path".
>> 10. Likewise, if you (setq minibuffer-completion-auto-choose nil), M-RET
>> inserts the completion string at point, without replacing the text in
>> the minibuffer, so you will get "load-path-path".
>>
>> I think this is basically just a bug.  Hopefully we can fix this before
>> Emacs 29 is released, because this is the last thing which stops these
>> new commands from being a really great improvement to the Emacs
>> completion defaults.
>
> I agree that it would be nice to fix this in Emacs 29.
> But the problem is that this would require non-trivial changes.
> We need to apply a small part of the patch mentioned in
> bug#47711, bug#48356, bug#48841, bug#60313 and located at
> https://lists.gnu.org/archive/html/emacs-devel/2021-08/msg00412.html
> that implements the following FIXME item in 'completion-all-completions':
>
>   ;; FIXME: We need to additionally return the info needed for the
>   ;; second part of completion-base-position.
>
> When it will return from 'completion-all-completions' not only the start
> position of a completion, but also its end, then we could use this
> additional information for M-<up> and M-<down>.

Any updates on the status of this patch?  I see you asked the same thing
a year ago in one of those bugs.

I can try to prepare a more minimal version of this patch, just targeted
at adding the ability to return the end of the completion position.

Do you have any advice on an appropriate API for that?  An alist as in
that patch seems reasonable to me, but perhaps there's an even simpler
approach?

(BTW, the reason I really want to fix this in Emacs 29 is that I don't
want us to be concerned with being backwards-compatible with the current
behavior in 29, which seems much worse to me.  But if we won't be
concerned about that, doing this in 30 seems totally fine.  I can just
backport it for my users anyway :) )

Message #20 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 62700 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Thu, 06 Apr 2023 22:30:55 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 62700 <at> debbugs.gnu.org,  juri <at> linkov.net
> Date: Thu, 06 Apr 2023 14:58:42 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> I think this is basically just a bug.
> >
> > I think it's the intended behavior.  In this case, it looks not
> > useful, because the string you typed before starting to use M-<UP> and
> > M-<DOWN> happens to be at the end of each completion candidate.  But
> > this is not the only situation possible.  Basically, completion always
> > modifies only the text before point, leaving what's after point
> > intact, so that the user could have after point stuff that completion
> > should ignore, and that eventually will be appended to the selected
> > candidate.
> 
> Could you give an example of when this would be desirable?

When completing on shell commands, for example: the text after point
is usually the command-line arguments to the command, and the
completion is on command names or on some file name.

> >> If this is intentional for some reason, I think the behavior should
> >> definitely be changed before Emacs 29 is released.  Moving point around
> >> in the minibuffer while completing is an important part of using the
> >> default completion-styles
> >
> > It is? why?
> 
> "basic" and "emacs22" are default completion-styles, and they both treat
> text after point differently from text before point.

This is intentional, AFAIK.

> For example, suppose I wanted to wanted to complete filenames starting
> with x and ending in .c.

I don't think the default completion supports such functionality, at
least not with the styles we have by default in completion-styles.

But maybe I'm missing something; adding Stefan to the discussion.

Message #23 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> janestreet.com>,
 juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Thu, 06 Apr 2023 16:42:13 -0400

>> > I think it's the intended behavior.  In this case, it looks not
>> > useful, because the string you typed before starting to use M-<UP> and
>> > M-<DOWN> happens to be at the end of each completion candidate.  But
>> > this is not the only situation possible.  Basically, completion always
>> > modifies only the text before point, leaving what's after point
>> > intact, so that the user could have after point stuff that completion
>> > should ignore, and that eventually will be appended to the selected
>> > candidate.
>> 
>> Could you give an example of when this would be desirable?
>
> When completing on shell commands, for example: the text after point
> is usually the command-line arguments to the command, and the
> completion is on command names or on some file name.

That shouldn't be a worry: when you complete shell commands, you're not
really using "minibuffer completion" (as is the case in `C-h v`) but
"in-buffer completion" (i.e. TAB is bound to `completion-at-point`
rather than to `minibuffer-complete`), so the completion code knows that
you're only completing the command part and will (hopefully) be careful
not to touch anything before or after it.

More specifically, in `M-!` if you're at

    echo hello; e!s world

where `!` shows where point is, the *Completions* buffer should show all
command that start with `e` and end in `s` (assuming we're using
`basic` or `partial-completion` styles) and if you use
minibuffer-{previous,next,choose}-completion, they should replace `e!s`
with the selection.  IOW it should neither "leave the text after point
alone" nor "replace all the text after point".

>> For example, suppose I wanted to wanted to complete filenames starting
>> with x and ending in .c.
> I don't think the default completion supports such functionality, at
> least not with the styles we have by default in completion-styles.

The behavior Spencer describes is very much part of our default (it's
provided both by the `basic` and the `partial-completion` styles, both
of which are enabled by default).


        Stefan

Message #26 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 62700 <at> debbugs.gnu.org
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Fri, 07 Apr 2023 19:37:51 +0300

>> I agree that it would be nice to fix this in Emacs 29.
>> But the problem is that this would require non-trivial changes.
>> We need to apply a small part of the patch mentioned in
>> bug#47711, bug#48356, bug#48841, bug#60313 and located at
>> https://lists.gnu.org/archive/html/emacs-devel/2021-08/msg00412.html
>> that implements the following FIXME item in 'completion-all-completions':
>
> Any updates on the status of this patch?  I see you asked the same thing
> a year ago in one of those bugs.

A year ago I had a clear understanding how to do this but unfortunately
now forgot the details.  The idea was to return from completion-all-completions
not only '("string" . number) where number is the start of the completion position,
but something like '("string" . (number1 number2)) where the second number is
the end of the completion position.

completion-all-completions is called from minibuffer-completion-help.
Then the second number could help to set the right base-suffix in

  (setq-local completion-base-affixes
              (list base-prefix base-suffix))

This base-suffix is used later by M-<up> and M-<down>.
When here base-suffix is "", then your test case will be fixed.
However, non-empty base-suffix is necessary in other cases
such as mentioned in bug#48356:

  ~/emacs/master/li|/calc

> I can try to prepare a more minimal version of this patch, just targeted
> at adding the ability to return the end of the completion position.
>
> Do you have any advice on an appropriate API for that?  An alist as in
> that patch seems reasonable to me, but perhaps there's an even simpler
> approach?

Changing the API will definitely cause problems with backwards-compatibility.
But maybe you could find a simple heuristic that would decide what base-suffix
to set in minibuffer-completion-help?  Then no API changes will be needed.

Message #29 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: sbaugh <at> catern.com
To: Juri Linkov <juri <at> linkov.net>
Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> janestreet.com>
Subject: Re: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion
 behave unintuitively when point is not at end of buffer
Date: Fri, 07 Apr 2023 21:02:47 +0000 (UTC)

Juri Linkov <juri <at> linkov.net> writes:
> Changing the API will definitely cause problems with backwards-compatibility.
> But maybe you could find a simple heuristic that would decide what base-suffix
> to set in minibuffer-completion-help?  Then no API changes will be needed.

Thank you for the guidance and suggestion.

Here's one heuristic which works decently well:

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 21d4607e7cf..dfb06b5b88f 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2374,7 +2374,11 @@ minibuffer-completion-help
              (prefix (unless (zerop base-size) (substring string 0 base-size)))
              (base-prefix (buffer-substring (minibuffer--completion-prompt-end)
                                             (+ start base-size)))
-             (base-suffix (buffer-substring (point) (point-max)))
+             (base-suffix
+              (if (eq (alist-get 'category (cdr md)) 'file)
+                  (buffer-substring (save-excursion (search-forward "/" nil t) (point))
+                                    (point-max))
+                ""))
              (all-md (completion--metadata (buffer-substring-no-properties
                                             start (point))
                                            base-size md


The reasoning here is that if completion returns the full string which
should be in the minibuffer, then we should replace the minibuffer with
that string, so base-suffix should be "".  But if we're completing only
part of the string, base-suffix should be something else.  AFAIK only
file completion falls into the latter category, and it always completes
just one component of a path, so I set base-suffix to not include the
component of the path that point is in, so that completion replaces it
entirely.

I think this is basically a satisfactory heuristic, although I'm sure
I'm missing some categories of completion besides file completion which
complete only part of the string.

Regardless of whether this is a satisfactory heuristic, it's revealed to
me an unexpected behavior of a solution to this bug using base-suffix,
which may or may not be fine: Point is moved to the end of the
completion inserted.

So e.g. if point is at | and I'm completing |-path, then when I choose
the completion load-path, point will be at load-path| rather than
load|-path.  This isn't a huge issue but it might be a little annoying?
I don't know if there's any way to fix this.

Message #32 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: sbaugh <at> catern.com
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively
 when point is not at end of buffer
Date: Sat, 08 Apr 2023 09:34:47 +0300

> Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> janestreet.com>
> From: sbaugh <at> catern.com
> Date: Fri, 07 Apr 2023 21:02:47 +0000 (UTC)
> 
> Juri Linkov <juri <at> linkov.net> writes:
> > Changing the API will definitely cause problems with backwards-compatibility.
> > But maybe you could find a simple heuristic that would decide what base-suffix
> > to set in minibuffer-completion-help?  Then no API changes will be needed.
> 
> Thank you for the guidance and suggestion.
> 
> Here's one heuristic which works decently well:

If this is for master, I'm fine with such changes.  But if you intend
to request installing this on emacs-29, then I will object making
non-trivial changes in any code that is not specific to the M-<UP> and
M-<DOWN> bindings that are new in Emacs 29.  I don't want to risk any
regressions in general-purpose completion code at this late stage.

Thanks.

Message #35 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: sbaugh <at> catern.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion
 behave unintuitively when point is not at end of buffer
Date: Sat, 08 Apr 2023 10:58:36 +0000 (UTC)

Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> janestreet.com>
>> From: sbaugh <at> catern.com
>> Date: Fri, 07 Apr 2023 21:02:47 +0000 (UTC)
>> 
>> Juri Linkov <juri <at> linkov.net> writes:
>> > Changing the API will definitely cause problems with backwards-compatibility.
>> > But maybe you could find a simple heuristic that would decide what base-suffix
>> > to set in minibuffer-completion-help?  Then no API changes will be needed.
>> 
>> Thank you for the guidance and suggestion.
>> 
>> Here's one heuristic which works decently well:
>
> If this is for master, I'm fine with such changes.  But if you intend
> to request installing this on emacs-29, then I will object making
> non-trivial changes in any code that is not specific to the M-<UP> and
> M-<DOWN> bindings that are new in Emacs 29.  I don't want to risk any
> regressions in general-purpose completion code at this late stage.

OK, that's no problem, this can be done by just let-binding
completion-base-affixes in minibuffer-{previous,next,choose}-completion
so that it only affects new code.  That will be a bit uglier to read so
I'll do that if this approach seems reasonable with some review.

Message #38 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: sbaugh <at> catern.com
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion
 behave unintuitively when point is not at end of buffer
Date: Sat, 08 Apr 2023 16:19:56 +0300

> From: sbaugh <at> catern.com
> Date: Sat, 08 Apr 2023 10:58:36 +0000 (UTC)
> Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > If this is for master, I'm fine with such changes.  But if you intend
> > to request installing this on emacs-29, then I will object making
> > non-trivial changes in any code that is not specific to the M-<UP> and
> > M-<DOWN> bindings that are new in Emacs 29.  I don't want to risk any
> > regressions in general-purpose completion code at this late stage.
> 
> OK, that's no problem, this can be done by just let-binding
> completion-base-affixes in minibuffer-{previous,next,choose}-completion
> so that it only affects new code.

Thanks.

> That will be a bit uglier to read so I'll do that if this approach
> seems reasonable with some review.

We can install the cleaner change on master, and the "uglier" one only
on the release branch.

Message #41 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: sbaugh <at> catern.com
Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> janestreet.com>
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Sat, 08 Apr 2023 21:30:39 +0300

> Here's one heuristic which works decently well:
>
> The reasoning here is that if completion returns the full string which
> should be in the minibuffer, then we should replace the minibuffer with
> that string, so base-suffix should be "".  But if we're completing only
> part of the string, base-suffix should be something else.  AFAIK only
> file completion falls into the latter category, and it always completes
> just one component of a path, so I set base-suffix to not include the
> component of the path that point is in, so that completion replaces it
> entirely.
>
> I think this is basically a satisfactory heuristic, although I'm sure
> I'm missing some categories of completion besides file completion which
> complete only part of the string.

Thanks, this looks like a satisfactory heuristic indeed.  It just needs
more testing for different categories of completion.

> Regardless of whether this is a satisfactory heuristic, it's revealed to
> me an unexpected behavior of a solution to this bug using base-suffix,
> which may or may not be fine: Point is moved to the end of the
> completion inserted.
>
> So e.g. if point is at | and I'm completing |-path, then when I choose
> the completion load-path, point will be at load-path| rather than
> load|-path.  This isn't a huge issue but it might be a little annoying?
> I don't know if there's any way to fix this.

Maybe you could find another heuristic for insertion of completion?
The code is located in the same function 'minibuffer-completion-help':

  (if (and (stringp start) (stringp end))
      (progn
        (delete-minibuffer-contents)
        (insert start choice)
        ;; Keep point after completion before suffix
        (save-excursion (insert end)))

Currently it keeps point before the suffix.

Message #44 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com, sbaugh <at> janestreet.com
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Sat, 08 Apr 2023 21:36:30 +0300

>> > Changing the API will definitely cause problems with backwards-compatibility.
>> > But maybe you could find a simple heuristic that would decide what base-suffix
>> > to set in minibuffer-completion-help?  Then no API changes will be needed.
>>
>> Thank you for the guidance and suggestion.
>>
>> Here's one heuristic which works decently well:
>
> If this is for master, I'm fine with such changes.  But if you intend
> to request installing this on emacs-29, then I will object making
> non-trivial changes in any code that is not specific to the M-<UP> and

Actually, a change for base-suffix in minibuffer-completion-help
is a trivial change.  What counts as a non-trivial change would be
changing the API in completion-all-completions.

> M-<DOWN> bindings that are new in Emacs 29.  I don't want to risk any
> regressions in general-purpose completion code at this late stage.

These changes are specific to the M-<UP> and M-<DOWN> bindings:
completion-use-base-affixes is nil, and it's let-bound to t
in M-<UP> (minibuffer-previous-completion) and M-<DOWN>
(minibuffer-next-completion).

Message #47 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com, sbaugh <at> janestreet.com
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Sat, 08 Apr 2023 22:32:34 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: sbaugh <at> catern.com,  62700 <at> debbugs.gnu.org,  sbaugh <at> janestreet.com
> Date: Sat, 08 Apr 2023 21:36:30 +0300
> 
> > If this is for master, I'm fine with such changes.  But if you intend
> > to request installing this on emacs-29, then I will object making
> > non-trivial changes in any code that is not specific to the M-<UP> and
> 
> Actually, a change for base-suffix in minibuffer-completion-help
> is a trivial change.  What counts as a non-trivial change would be
> changing the API in completion-all-completions.
> 
> > M-<DOWN> bindings that are new in Emacs 29.  I don't want to risk any
> > regressions in general-purpose completion code at this late stage.
> 
> These changes are specific to the M-<UP> and M-<DOWN> bindings:
> completion-use-base-affixes is nil, and it's let-bound to t
> in M-<UP> (minibuffer-previous-completion) and M-<DOWN>
> (minibuffer-next-completion).

The change I reviewed and to which I responded was in code that was
there in Emacs 28 as well.  Maybe we are talking about two different
sets of changes.

Message #50 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com, sbaugh <at> janestreet.com
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Sun, 09 Apr 2023 19:40:37 +0300

>> > If this is for master, I'm fine with such changes.  But if you intend
>> > to request installing this on emacs-29, then I will object making
>> > non-trivial changes in any code that is not specific to the M-<UP> and
>> 
>> Actually, a change for base-suffix in minibuffer-completion-help
>> is a trivial change.  What counts as a non-trivial change would be
>> changing the API in completion-all-completions.
>> 
>> > M-<DOWN> bindings that are new in Emacs 29.  I don't want to risk any
>> > regressions in general-purpose completion code at this late stage.
>> 
>> These changes are specific to the M-<UP> and M-<DOWN> bindings:
>> completion-use-base-affixes is nil, and it's let-bound to t
>> in M-<UP> (minibuffer-previous-completion) and M-<DOWN>
>> (minibuffer-next-completion).
>
> The change I reviewed and to which I responded was in code that was
> there in Emacs 28 as well.  Maybe we are talking about two different
> sets of changes.

That code was added in Emacs 29 a year ago in the commit
7aaffe25eb178f69027fb0af844a89a86db4b1f2.

Message #53 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com, sbaugh <at> janestreet.com
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Sun, 09 Apr 2023 20:38:27 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: sbaugh <at> catern.com,  62700 <at> debbugs.gnu.org,  sbaugh <at> janestreet.com
> Date: Sun, 09 Apr 2023 19:40:37 +0300
> 
> >> > If this is for master, I'm fine with such changes.  But if you intend
> >> > to request installing this on emacs-29, then I will object making
> >> > non-trivial changes in any code that is not specific to the M-<UP> and
> >> 
> >> Actually, a change for base-suffix in minibuffer-completion-help
> >> is a trivial change.  What counts as a non-trivial change would be
> >> changing the API in completion-all-completions.
> >> 
> >> > M-<DOWN> bindings that are new in Emacs 29.  I don't want to risk any
> >> > regressions in general-purpose completion code at this late stage.
> >> 
> >> These changes are specific to the M-<UP> and M-<DOWN> bindings:
> >> completion-use-base-affixes is nil, and it's let-bound to t
> >> in M-<UP> (minibuffer-previous-completion) and M-<DOWN>
> >> (minibuffer-next-completion).
> >
> > The change I reviewed and to which I responded was in code that was
> > there in Emacs 28 as well.  Maybe we are talking about two different
> > sets of changes.
> 
> That code was added in Emacs 29 a year ago in the commit
> 7aaffe25eb178f69027fb0af844a89a86db4b1f2.

Ah, you mean that part.  Yes, but a year is a long time, and making
non-trivial changes there now is not something I'd like to do.

Message #56 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> catern.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> janestreet.com>
Subject: Re: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion
 behave unintuitively when point is not at end of buffer
Date: Mon, 10 Apr 2023 13:03:04 +0000 (UTC)

[Message part 1 (text/html, inline)]

Message #59 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> catern.com>
Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> janestreet.com>
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Mon, 10 Apr 2023 21:20:27 +0300

>> It just needs more testing for different categories of completion.
>
> Which categories do you have in mind?

Actually, I can't find categories where it could fail.
So your patch looks safe to push.

>> Maybe you could find another heuristic for insertion of completion? 
>> The code is located in the same function 'minibuffer-completion-help': 
>>
>>   (if (and (stringp start) (stringp end)) 
>>       (progn 
>>         (delete-minibuffer-contents) 
>>         (insert start choice) 
>>         ;; Keep point after completion before suffix 
>>         (save-excursion (insert end))) 
>>
>> Currently it keeps point before the suffix. 
>
> I will try. Although this is a case where completion-base-position feels
> more suited than completion-base-affixes...

Can you get the same info about positions by calculating the
lengths of prefix/choice/suffix?

Message #62 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> catern.com>
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Thu, 20 Apr 2023 12:52:20 -0400

Juri Linkov <juri <at> linkov.net> writes:
>>> It just needs more testing for different categories of completion.
>>
>> Which categories do you have in mind?
>
> Actually, I can't find categories where it could fail.
> So your patch looks safe to push.

Can we go ahead and push it to Emacs master, then?  I will work on the
changing-only-new-code backport for Emacs 29 as Eli requested.

>>> Maybe you could find another heuristic for insertion of completion? 
>>> The code is located in the same function 'minibuffer-completion-help': 
>>>
>>>   (if (and (stringp start) (stringp end)) 
>>>       (progn 
>>>         (delete-minibuffer-contents) 
>>>         (insert start choice) 
>>>         ;; Keep point after completion before suffix 
>>>         (save-excursion (insert end))) 
>>>
>>> Currently it keeps point before the suffix. 
>>
>> I will try. Although this is a case where completion-base-position feels
>> more suited than completion-base-affixes...
>
> Can you get the same info about positions by calculating the
> lengths of prefix/choice/suffix?

Hm I have thought about it but I can't see a simple heuristic.

It's not actually clear what behavior we want, anyway.  When TAB
completes a string fully, it sends point to the end of the buffer.  This
happens even if completion-cycle-threshold is non-nil, and
completion-cycle-threashold feels like a pretty similar feature to
minibuffer-{previous,next}-completion. So maybe that's correct for us to
do here too?

But a different behavior feels like it could also makes sense.  For
example, if I'm completing from ffap-|-path (| is point), I'm just
cycling between ffap-bib-path, ffap-c++-path, ffap-c-path, and it feels
like as I cycle through those, point should stay right before "-path",
like ffap-bib|-path, ffap-c++|-path, ffap-c|-path.  No idea how to
achieve this behavior though.

Anyway, the behavior with my earlier patch now feels fine to me, I don't
think we need any improvements to point's behavior for now.

Message #65 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> catern.com>
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Thu, 20 Apr 2023 21:18:57 +0300

>>>> It just needs more testing for different categories of completion.
>>>
>>> Which categories do you have in mind?
>>
>> Actually, I can't find categories where it could fail.
>> So your patch looks safe to push.
>
> Can we go ahead and push it to Emacs master, then?  I will work on the
> changing-only-new-code backport for Emacs 29 as Eli requested.

But your patch changes only new code.

>>>> Maybe you could find another heuristic for insertion of completion?
>>>> The code is located in the same function 'minibuffer-completion-help':
>>>>
>>>>   (if (and (stringp start) (stringp end))
>>>>       (progn
>>>>         (delete-minibuffer-contents)
>>>>         (insert start choice)
>>>>         ;; Keep point after completion before suffix
>>>>         (save-excursion (insert end)))
>>>>
>>>> Currently it keeps point before the suffix.
>>>
>>> I will try. Although this is a case where completion-base-position feels
>>> more suited than completion-base-affixes...
>>
>> Can you get the same info about positions by calculating the
>> lengths of prefix/choice/suffix?
>
> Hm I have thought about it but I can't see a simple heuristic.
>
> It's not actually clear what behavior we want, anyway.  When TAB
> completes a string fully, it sends point to the end of the buffer.  This
> happens even if completion-cycle-threshold is non-nil, and
> completion-cycle-threashold feels like a pretty similar feature to
> minibuffer-{previous,next}-completion. So maybe that's correct for us to
> do here too?
>
> But a different behavior feels like it could also makes sense.  For
> example, if I'm completing from ffap-|-path (| is point), I'm just
> cycling between ffap-bib-path, ffap-c++-path, ffap-c-path, and it feels
> like as I cycle through those, point should stay right before "-path",
> like ffap-bib|-path, ffap-c++|-path, ffap-c|-path.  No idea how to
> achieve this behavior though.

This also makes sense: ffap-|bib-path, ffap-|c++-path, ffap-|c-path.
I tried it with this tentative patch and it feels quite natural,
so maybe could be turned into an option:

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index a6af65dfa14..733f7710378 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2366,6 +2371,7 @@ minibuffer-completion-help
   (let* ((start (or start (minibuffer--completion-prompt-end)))
          (end (or end (point-max)))
          (string (buffer-substring start end))
+         (pos (1- (point)))
          (md (completion--field-metadata start))
          (completions (completion-all-completions
                        string
@@ -2493,7 +2503,8 @@ minibuffer-completion-help
                                        (delete-minibuffer-contents)
                                        (insert start choice)
                                        ;; Keep point after completion before suffix
-                                       (save-excursion (insert end)))
+                                       (save-excursion (insert end))
+                                       (move-to-column pos))
                                    (unless (or (zerop (length prefix))
                                                (equal prefix
                                                       (buffer-substring-no-properties

> Anyway, the behavior with my earlier patch now feels fine to me, I don't
> think we need any improvements to point's behavior for now.

Maybe your patch still could be pushed to emacs-29 because it fixes
the new feature.

Message #68 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> catern.com>
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Thu, 20 Apr 2023 14:46:45 -0400

Juri Linkov <juri <at> linkov.net> writes:
>>>>> It just needs more testing for different categories of completion.
>>>>
>>>> Which categories do you have in mind?
>>>
>>> Actually, I can't find categories where it could fail.
>>> So your patch looks safe to push.
>>
>> Can we go ahead and push it to Emacs master, then?  I will work on the
>> changing-only-new-code backport for Emacs 29 as Eli requested.
>
> But your patch changes only new code.

Ah, I thought Eli still wanted a backport version because this changes
code which has been on Emacs 29 for over a year.

I'm happy either way.  (well, of course I prefer to not make a backport
version, but happy to do it if Eli wants one)

>>>>> Maybe you could find another heuristic for insertion of completion?
>>>>> The code is located in the same function 'minibuffer-completion-help':
>>>>>
>>>>>   (if (and (stringp start) (stringp end))
>>>>>       (progn
>>>>>         (delete-minibuffer-contents)
>>>>>         (insert start choice)
>>>>>         ;; Keep point after completion before suffix
>>>>>         (save-excursion (insert end)))
>>>>>
>>>>> Currently it keeps point before the suffix.
>>>>
>>>> I will try. Although this is a case where completion-base-position feels
>>>> more suited than completion-base-affixes...
>>>
>>> Can you get the same info about positions by calculating the
>>> lengths of prefix/choice/suffix?
>>
>> Hm I have thought about it but I can't see a simple heuristic.
>>
>> It's not actually clear what behavior we want, anyway.  When TAB
>> completes a string fully, it sends point to the end of the buffer.  This
>> happens even if completion-cycle-threshold is non-nil, and
>> completion-cycle-threashold feels like a pretty similar feature to
>> minibuffer-{previous,next}-completion. So maybe that's correct for us to
>> do here too?
>>
>> But a different behavior feels like it could also makes sense.  For
>> example, if I'm completing from ffap-|-path (| is point), I'm just
>> cycling between ffap-bib-path, ffap-c++-path, ffap-c-path, and it feels
>> like as I cycle through those, point should stay right before "-path",
>> like ffap-bib|-path, ffap-c++|-path, ffap-c|-path.  No idea how to
>> achieve this behavior though.
>
> This also makes sense: ffap-|bib-path, ffap-|c++-path, ffap-|c-path.

Agreed.

> I tried it with this tentative patch and it feels quite natural,
> so maybe could be turned into an option:
>
> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
> index a6af65dfa14..733f7710378 100644
> --- a/lisp/minibuffer.el
> +++ b/lisp/minibuffer.el
> @@ -2366,6 +2371,7 @@ minibuffer-completion-help
>    (let* ((start (or start (minibuffer--completion-prompt-end)))
>           (end (or end (point-max)))
>           (string (buffer-substring start end))
> +         (pos (1- (point)))
>           (md (completion--field-metadata start))
>           (completions (completion-all-completions
>                         string
> @@ -2493,7 +2503,8 @@ minibuffer-completion-help
>                                         (delete-minibuffer-contents)
>                                         (insert start choice)
>                                         ;; Keep point after completion before suffix
> -                                       (save-excursion (insert end)))
> +                                       (save-excursion (insert end))
> +                                       (move-to-column pos))
>                                     (unless (or (zerop (length prefix))
>                                                 (equal prefix
>                                                        (buffer-substring-no-properties

Interesting idea.  Although it breaks down with ?, I notice:
1. C-h v ff-|-p
2. ? to pop up completions
3. M-<down> to select diff-font-lock-prettify
4. Get dif|f-font-lock-prettify which seems fairly wrong

>> Anyway, the behavior with my earlier patch now feels fine to me, I don't
>> think we need any improvements to point's behavior for now.
>
> Maybe your patch still could be pushed to emacs-29 because it fixes
> the new feature.

Agreed.

Message #71 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, sbaugh <at> catern.com
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively
 when point is not at end of buffer
Date: Thu, 20 Apr 2023 21:51:58 +0300

> Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> catern.com>
> From: Juri Linkov <juri <at> linkov.net>
> Date: Thu, 20 Apr 2023 21:18:57 +0300
> 
> >>>> It just needs more testing for different categories of completion.
> >>>
> >>> Which categories do you have in mind?
> >>
> >> Actually, I can't find categories where it could fail.
> >> So your patch looks safe to push.
> >
> > Can we go ahead and push it to Emacs master, then?  I will work on the
> > changing-only-new-code backport for Emacs 29 as Eli requested.
> 
> But your patch changes only new code.

For some definition of "new", yes.

> Maybe your patch still could be pushed to emacs-29 because it fixes
> the new feature.

Whether this is a bugfix is arguable.

In any case, we need to hold Spencer's contributions until his legal
paperwork is finished.  So we cannot yet install any of this, not even
on master.

Message #74 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively
 when point is not at end of buffer
Date: Thu, 20 Apr 2023 22:00:16 +0300

> Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> catern.com>
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Thu, 20 Apr 2023 14:46:45 -0400
> 
> Juri Linkov <juri <at> linkov.net> writes:
> >>>>> It just needs more testing for different categories of completion.
> >>>>
> >>>> Which categories do you have in mind?
> >>>
> >>> Actually, I can't find categories where it could fail.
> >>> So your patch looks safe to push.
> >>
> >> Can we go ahead and push it to Emacs master, then?  I will work on the
> >> changing-only-new-code backport for Emacs 29 as Eli requested.
> >
> > But your patch changes only new code.
> 
> Ah, I thought Eli still wanted a backport version because this changes
> code which has been on Emacs 29 for over a year.

Indeed, that's what I would like to see on the release branch.  Mainly
because even if this is deemed a bug, it happens in a relatively rare
situation, so I'd like to avoid risking breakage in code which affects
other situations.

Message #77 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: sbaugh <at> catern.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> janestreet.com>,
 juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion
 behave unintuitively when point is not at end of buffer
Date: Fri, 21 Apr 2023 18:56:35 +0000 (UTC)

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> catern.com>
>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Date: Thu, 20 Apr 2023 14:46:45 -0400
>> 
>> Juri Linkov <juri <at> linkov.net> writes:
>> >>>>> It just needs more testing for different categories of completion.
>> >>>>
>> >>>> Which categories do you have in mind?
>> >>>
>> >>> Actually, I can't find categories where it could fail.
>> >>> So your patch looks safe to push.
>> >>
>> >> Can we go ahead and push it to Emacs master, then?  I will work on the
>> >> changing-only-new-code backport for Emacs 29 as Eli requested.
>> >
>> > But your patch changes only new code.
>> 
>> Ah, I thought Eli still wanted a backport version because this changes
>> code which has been on Emacs 29 for over a year.
>
> Indeed, that's what I would like to see on the release branch.  Mainly
> because even if this is deemed a bug, it happens in a relatively rare
> situation, so I'd like to avoid risking breakage in code which affects
> other situations.

Here's the backport for the release branch.  (FYI, my papers have been
signed and the FSF copyright clerk has approved accepting my
contributions again)

[0001-Handle-point-not-at-EOB-in-minibuffer-choose-complet.patch (text/x-patch, inline)]

From a159cfb8ee80e24de180d002caa61119edc7afc1 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> catern.com>
Date: Fri, 21 Apr 2023 14:55:00 -0400
Subject: [PATCH] Handle point not at EOB in minibuffer-choose-completion

Without this change, only the minibuffer contents before point are
cleared when a completion is chosen, which results in stray text when
point is in the middle of the minibuffer.

After this change, we heuristically decide either to clear the whole
buffer or only part of it, taking into account the location of point.

This is a backport for the Emacs 29 release branch of a simpler fix in
minibuffer-completion-help.

* lisp/minibuffer.el (minibuffer-next-completion):
(minibuffer-choose-completion):
Recalculate completion-base-affixes with point
---
 lisp/minibuffer.el | 26 +++++++++++++++++++++-----
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index dfb06b5b88f..86946ec9ce1 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -4464,13 +4464,21 @@ minibuffer-next-completion
 When `minibuffer-completion-auto-choose' is non-nil, then also
 insert the selected completion to the minibuffer."
   (interactive "p")
-  (let ((auto-choose minibuffer-completion-auto-choose))
+  (let* ((auto-choose minibuffer-completion-auto-choose)
+         ;; Backported fix for bug#62700
+         (md (completion--field-metadata (minibuffer--completion-prompt-end)))
+         (base-suffix
+          (if (eq (alist-get 'category (cdr md)) 'file)
+              (buffer-substring (save-excursion (search-forward "/" nil t) (point))
+                                (point-max))
+            "")))
     (with-minibuffer-completions-window
       (when completions-highlight-face
         (setq-local cursor-face-highlight-nonselected-window t))
       (next-completion (or n 1))
       (when auto-choose
-        (let ((completion-use-base-affixes t))
+        (let ((completion-use-base-affixes t)
+              (completion-base-affixes (list (car completion-base-affixes) base-suffix)))
           (choose-completion nil t t))))))
 
 (defun minibuffer-previous-completion (&optional n)
@@ -4489,9 +4497,17 @@ minibuffer-choose-completion
 If NO-QUIT is non-nil, insert the completion at point to the
 minibuffer, but don't quit the completions window."
   (interactive "P")
-  (with-minibuffer-completions-window
-    (let ((completion-use-base-affixes t))
-      (choose-completion nil no-exit no-quit))))
+  ;; Backported fix for bug#62700
+  (let* ((md (completion--field-metadata (minibuffer--completion-prompt-end)))
+         (base-suffix
+          (if (eq (alist-get 'category (cdr md)) 'file)
+              (buffer-substring (save-excursion (search-forward "/" nil t) (point))
+                                (point-max))
+            "")))
+    (with-minibuffer-completions-window
+      (let ((completion-use-base-affixes t)
+            (completion-base-affixes (list (car completion-base-affixes) base-suffix)))
+        (choose-completion nil no-exit no-quit)))))
 
 (defun minibuffer-complete-history ()
   "Complete the minibuffer history as far as possible.
-- 
2.38.0

Message #80 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: sbaugh <at> catern.com
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion
 behave unintuitively when point is not at end of buffer
Date: Sat, 22 Apr 2023 13:48:47 +0300

> From: sbaugh <at> catern.com
> Date: Fri, 21 Apr 2023 18:56:35 +0000 (UTC)
> Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 62700 <at> debbugs.gnu.org,
> 	juri <at> linkov.net
> 
> >> Ah, I thought Eli still wanted a backport version because this changes
> >> code which has been on Emacs 29 for over a year.
> >
> > Indeed, that's what I would like to see on the release branch.  Mainly
> > because even if this is deemed a bug, it happens in a relatively rare
> > situation, so I'd like to avoid risking breakage in code which affects
> > other situations.
> 
> Here's the backport for the release branch.

Thanks, but I'd like to make this still safer for the release branch:

> --- a/lisp/minibuffer.el
> +++ b/lisp/minibuffer.el
> @@ -4464,13 +4464,21 @@ minibuffer-next-completion
>  When `minibuffer-completion-auto-choose' is non-nil, then also
>  insert the selected completion to the minibuffer."
>    (interactive "p")
> -  (let ((auto-choose minibuffer-completion-auto-choose))
> +  (let* ((auto-choose minibuffer-completion-auto-choose)
> +         ;; Backported fix for bug#62700
> +         (md (completion--field-metadata (minibuffer--completion-prompt-end)))
> +         (base-suffix
> +          (if (eq (alist-get 'category (cdr md)) 'file)
> +              (buffer-substring (save-excursion (search-forward "/" nil t) (point))
> +                                (point-max))
> +            "")))
>      (with-minibuffer-completions-window
>        (when completions-highlight-face
>          (setq-local cursor-face-highlight-nonselected-window t))
>        (next-completion (or n 1))
>        (when auto-choose
> -        (let ((completion-use-base-affixes t))
> +        (let ((completion-use-base-affixes t)
> +              (completion-base-affixes (list (car completion-base-affixes) base-suffix)))
>            (choose-completion nil t t))))))

Here, the values used only when minibuffer-completion-auto-choose is
non-nil should be computed only when that variable is non-nil,
preferably inside the '(when auto-choose' clause.

> @@ -4489,9 +4497,17 @@ minibuffer-choose-completion
>  If NO-QUIT is non-nil, insert the completion at point to the
>  minibuffer, but don't quit the completions window."
>    (interactive "P")
> -  (with-minibuffer-completions-window
> -    (let ((completion-use-base-affixes t))
> -      (choose-completion nil no-exit no-quit))))
> +  ;; Backported fix for bug#62700
> +  (let* ((md (completion--field-metadata (minibuffer--completion-prompt-end)))
> +         (base-suffix
> +          (if (eq (alist-get 'category (cdr md)) 'file)
> +              (buffer-substring (save-excursion (search-forward "/" nil t) (point))
> +                                (point-max))
> +            "")))
> +    (with-minibuffer-completions-window
> +      (let ((completion-use-base-affixes t)
> +            (completion-base-affixes (list (car completion-base-affixes) base-suffix)))
> +        (choose-completion nil no-exit no-quit)))))

And here we seem to be modifying code that is not only for when
minibuffer-completion-auto-choose is non-nil, or what am I missing?

Message #83 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: sbaugh <at> catern.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion
 behave unintuitively when point is not at end of buffer
Date: Sat, 22 Apr 2023 12:57:57 +0000 (UTC)

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: sbaugh <at> catern.com
>> Date: Fri, 21 Apr 2023 18:56:35 +0000 (UTC)
>> Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 62700 <at> debbugs.gnu.org,
>> 	juri <at> linkov.net
>> 
>> >> Ah, I thought Eli still wanted a backport version because this changes
>> >> code which has been on Emacs 29 for over a year.
>> >
>> > Indeed, that's what I would like to see on the release branch.  Mainly
>> > because even if this is deemed a bug, it happens in a relatively rare
>> > situation, so I'd like to avoid risking breakage in code which affects
>> > other situations.
>> 
>> Here's the backport for the release branch.
>
> Thanks, but I'd like to make this still safer for the release branch:
>
>> --- a/lisp/minibuffer.el
>> +++ b/lisp/minibuffer.el
>> @@ -4464,13 +4464,21 @@ minibuffer-next-completion
>>  When `minibuffer-completion-auto-choose' is non-nil, then also
>>  insert the selected completion to the minibuffer."
>>    (interactive "p")
>> -  (let ((auto-choose minibuffer-completion-auto-choose))
>> +  (let* ((auto-choose minibuffer-completion-auto-choose)
>> +         ;; Backported fix for bug#62700
>> +         (md (completion--field-metadata (minibuffer--completion-prompt-end)))
>> +         (base-suffix
>> +          (if (eq (alist-get 'category (cdr md)) 'file)
>> +              (buffer-substring (save-excursion (search-forward "/" nil t) (point))
>> +                                (point-max))
>> +            "")))
>>      (with-minibuffer-completions-window
>>        (when completions-highlight-face
>>          (setq-local cursor-face-highlight-nonselected-window t))
>>        (next-completion (or n 1))
>>        (when auto-choose
>> -        (let ((completion-use-base-affixes t))
>> +        (let ((completion-use-base-affixes t)
>> +              (completion-base-affixes (list (car completion-base-affixes) base-suffix)))
>>            (choose-completion nil t t))))))
>
> Here, the values used only when minibuffer-completion-auto-choose is
> non-nil should be computed only when that variable is non-nil,
> preferably inside the '(when auto-choose' clause.
>
>> @@ -4489,9 +4497,17 @@ minibuffer-choose-completion
>>  If NO-QUIT is non-nil, insert the completion at point to the
>>  minibuffer, but don't quit the completions window."
>>    (interactive "P")
>> -  (with-minibuffer-completions-window
>> -    (let ((completion-use-base-affixes t))
>> -      (choose-completion nil no-exit no-quit))))
>> +  ;; Backported fix for bug#62700
>> +  (let* ((md (completion--field-metadata (minibuffer--completion-prompt-end)))
>> +         (base-suffix
>> +          (if (eq (alist-get 'category (cdr md)) 'file)
>> +              (buffer-substring (save-excursion (search-forward "/" nil t) (point))
>> +                                (point-max))
>> +            "")))
>> +    (with-minibuffer-completions-window
>> +      (let ((completion-use-base-affixes t)
>> +            (completion-base-affixes (list (car completion-base-affixes) base-suffix)))
>> +        (choose-completion nil no-exit no-quit)))))
>
> And here we seem to be modifying code that is not only for when
> minibuffer-completion-auto-choose is non-nil, or what am I missing?

The bug happens regardless of the value of
minibuffer-completion-auto-choose.  It doesn't relate to
minibuffer-completion-auto-choose.

Message #86 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: sbaugh <at> catern.com
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion
 behave unintuitively when point is not at end of buffer
Date: Sat, 22 Apr 2023 16:15:02 +0300

> From: sbaugh <at> catern.com
> Date: Sat, 22 Apr 2023 12:57:57 +0000 (UTC)
> Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > And here we seem to be modifying code that is not only for when
> > minibuffer-completion-auto-choose is non-nil, or what am I missing?
> 
> The bug happens regardless of the value of
> minibuffer-completion-auto-choose.  It doesn't relate to
> minibuffer-completion-auto-choose.

I asked for the changes to affect only code specific to M-<UP> and
M-<DOWN>, but the patch you posted doesn't limit itself to that,
AFAICT.  Or what am I missing?

Message #89 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: sbaugh <at> catern.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion
 behave unintuitively when point is not at end of buffer
Date: Sat, 22 Apr 2023 21:38:52 +0000 (UTC)

Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: sbaugh <at> catern.com
>> Date: Sat, 22 Apr 2023 12:57:57 +0000 (UTC)
>> Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > And here we seem to be modifying code that is not only for when
>> > minibuffer-completion-auto-choose is non-nil, or what am I missing?
>> 
>> The bug happens regardless of the value of
>> minibuffer-completion-auto-choose.  It doesn't relate to
>> minibuffer-completion-auto-choose.
>
> I asked for the changes to affect only code specific to M-<UP> and
> M-<DOWN>, but the patch you posted doesn't limit itself to that,
> AFAICT.  Or what am I missing?

Ah, I didn't realize that was what you were asking for.  I can do that,
certainly, but why not also cover M-RET?  The bug exists in the exact
same form for M-RET and it will be confusing (though better than
nothing, definitely) if the fix applies to M-<UP> and M-<DOWN> but not
M-RET.

Message #92 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: sbaugh <at> catern.com
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion
 behave unintuitively when point is not at end of buffer
Date: Sun, 23 Apr 2023 09:13:18 +0300

> From: sbaugh <at> catern.com
> Date: Sat, 22 Apr 2023 21:38:52 +0000 (UTC)
> Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > I asked for the changes to affect only code specific to M-<UP> and
> > M-<DOWN>, but the patch you posted doesn't limit itself to that,
> > AFAICT.  Or what am I missing?
> 
> Ah, I didn't realize that was what you were asking for.  I can do that,
> certainly, but why not also cover M-RET?  The bug exists in the exact
> same form for M-RET and it will be confusing (though better than
> nothing, definitely) if the fix applies to M-<UP> and M-<DOWN> but not
> M-RET.

If the issue exists for M-RET, then fixing that case as well is okay.
The request was not to affect any code that handles also other
situation and other keys.

Message #95 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: sbaugh <at> catern.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion
 behave unintuitively when point is not at end of buffer
Date: Sun, 23 Apr 2023 11:48:50 +0000 (UTC)

Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: sbaugh <at> catern.com
>> Date: Sat, 22 Apr 2023 21:38:52 +0000 (UTC)
>> Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> > I asked for the changes to affect only code specific to M-<UP> and
>> > M-<DOWN>, but the patch you posted doesn't limit itself to that,
>> > AFAICT.  Or what am I missing?
>> 
>> Ah, I didn't realize that was what you were asking for.  I can do that,
>> certainly, but why not also cover M-RET?  The bug exists in the exact
>> same form for M-RET and it will be confusing (though better than
>> nothing, definitely) if the fix applies to M-<UP> and M-<DOWN> but not
>> M-RET.
>
> If the issue exists for M-RET, then fixing that case as well is okay.
> The request was not to affect any code that handles also other
> situation and other keys.

M-RET is bound to minibuffer-choose-completion, so then why the
objection to a patch which affects minibuffer-choose-completion?

Message #98 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: sbaugh <at> catern.com
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion
 behave unintuitively when point is not at end of buffer
Date: Mon, 24 Apr 2023 14:22:56 +0300

> From: sbaugh <at> catern.com
> Date: Sun, 23 Apr 2023 11:48:50 +0000 (UTC)
> Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> From: sbaugh <at> catern.com
> >> Date: Sat, 22 Apr 2023 21:38:52 +0000 (UTC)
> >> Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> > I asked for the changes to affect only code specific to M-<UP> and
> >> > M-<DOWN>, but the patch you posted doesn't limit itself to that,
> >> > AFAICT.  Or what am I missing?
> >> 
> >> Ah, I didn't realize that was what you were asking for.  I can do that,
> >> certainly, but why not also cover M-RET?  The bug exists in the exact
> >> same form for M-RET and it will be confusing (though better than
> >> nothing, definitely) if the fix applies to M-<UP> and M-<DOWN> but not
> >> M-RET.
> >
> > If the issue exists for M-RET, then fixing that case as well is okay.
> > The request was not to affect any code that handles also other
> > situation and other keys.
> 
> M-RET is bound to minibuffer-choose-completion, so then why the
> objection to a patch which affects minibuffer-choose-completion?

Because we never talked about M-RET until now?

Message #101 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: sbaugh <at> catern.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion
 behave unintuitively when point is not at end of buffer
Date: Tue, 02 May 2023 15:13:21 +0000 (UTC)

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: sbaugh <at> catern.com
>> Date: Fri, 21 Apr 2023 18:56:35 +0000 (UTC)
>> Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 62700 <at> debbugs.gnu.org,
>> 	juri <at> linkov.net
>> 
>> >> Ah, I thought Eli still wanted a backport version because this changes
>> >> code which has been on Emacs 29 for over a year.
>> >
>> > Indeed, that's what I would like to see on the release branch.  Mainly
>> > because even if this is deemed a bug, it happens in a relatively rare
>> > situation, so I'd like to avoid risking breakage in code which affects
>> > other situations.
>> 
>> Here's the backport for the release branch.
>
> Thanks, but I'd like to make this still safer for the release branch:
>
>> --- a/lisp/minibuffer.el
>> +++ b/lisp/minibuffer.el
>> @@ -4464,13 +4464,21 @@ minibuffer-next-completion
>>  When `minibuffer-completion-auto-choose' is non-nil, then also
>>  insert the selected completion to the minibuffer."
>>    (interactive "p")
>> -  (let ((auto-choose minibuffer-completion-auto-choose))
>> +  (let* ((auto-choose minibuffer-completion-auto-choose)
>> +         ;; Backported fix for bug#62700
>> +         (md (completion--field-metadata (minibuffer--completion-prompt-end)))
>> +         (base-suffix
>> +          (if (eq (alist-get 'category (cdr md)) 'file)
>> +              (buffer-substring (save-excursion (search-forward "/" nil t) (point))
>> +                                (point-max))
>> +            "")))
>>      (with-minibuffer-completions-window
>>        (when completions-highlight-face
>>          (setq-local cursor-face-highlight-nonselected-window t))
>>        (next-completion (or n 1))
>>        (when auto-choose
>> -        (let ((completion-use-base-affixes t))
>> +        (let ((completion-use-base-affixes t)
>> +              (completion-base-affixes (list (car completion-base-affixes) base-suffix)))
>>            (choose-completion nil t t))))))
>
> Here, the values used only when minibuffer-completion-auto-choose is
> non-nil should be computed only when that variable is non-nil,
> preferably inside the '(when auto-choose' clause.

OK, here's the patch with this change.

(As discussed elsewhere in the thread, the patch includes changes to
minibuffer-choose-completion because that function also is affected by
the bug and also needs to be fixed)

[0001-Handle-point-not-at-EOB-in-minibuffer-choose-complet.patch (text/x-patch, inline)]

From d446bec7d59944e25f478a63bd6c980ca7ce48d6 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> catern.com>
Date: Fri, 21 Apr 2023 14:55:00 -0400
Subject: [PATCH] Handle point not at EOB in minibuffer-choose-completion

Without this change, only the minibuffer contents before point are
cleared when a completion is chosen, which results in stray text when
point is in the middle of the minibuffer.

After this change, we heuristically decide either to clear the whole
buffer or only part of it, taking into account the location of point.

This is a backport for the Emacs 29 release branch of a simpler fix in
minibuffer-completion-help.

* lisp/minibuffer.el (minibuffer-next-completion):
(minibuffer-choose-completion):
Recalculate completion-base-affixes with point
---
 lisp/minibuffer.el | 30 +++++++++++++++++++++++++-----
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 21d4607e7cf..f457ecfcf7d 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -4460,13 +4460,25 @@ minibuffer-next-completion
 When `minibuffer-completion-auto-choose' is non-nil, then also
 insert the selected completion to the minibuffer."
   (interactive "p")
-  (let ((auto-choose minibuffer-completion-auto-choose))
+  (let ((auto-choose minibuffer-completion-auto-choose)
+         (buf (current-buffer)))
     (with-minibuffer-completions-window
       (when completions-highlight-face
         (setq-local cursor-face-highlight-nonselected-window t))
       (next-completion (or n 1))
       (when auto-choose
-        (let ((completion-use-base-affixes t))
+        (let* ((completion-use-base-affixes t)
+               ;; Backported fix for bug#62700
+               (md
+                (with-current-buffer buf
+                  (completion--field-metadata (minibuffer--completion-prompt-end))))
+               (base-suffix
+                (if (eq (alist-get 'category (cdr md)) 'file)
+                    (with-current-buffer buf
+                      (buffer-substring (save-excursion (search-forward "/" nil t) (point))
+                                        (point-max)))
+                  ""))
+              (completion-base-affixes (list (car completion-base-affixes) base-suffix)))
           (choose-completion nil t t))))))
 
 (defun minibuffer-previous-completion (&optional n)
@@ -4485,9 +4497,17 @@ minibuffer-choose-completion
 If NO-QUIT is non-nil, insert the completion at point to the
 minibuffer, but don't quit the completions window."
   (interactive "P")
-  (with-minibuffer-completions-window
-    (let ((completion-use-base-affixes t))
-      (choose-completion nil no-exit no-quit))))
+  ;; Backported fix for bug#62700
+  (let* ((md (completion--field-metadata (minibuffer--completion-prompt-end)))
+         (base-suffix
+          (if (eq (alist-get 'category (cdr md)) 'file)
+              (buffer-substring (save-excursion (search-forward "/" nil t) (point))
+                                (point-max))
+            "")))
+    (with-minibuffer-completions-window
+      (let ((completion-use-base-affixes t)
+            (completion-base-affixes (list (car completion-base-affixes) base-suffix)))
+        (choose-completion nil no-exit no-quit)))))
 
 (defun minibuffer-complete-history ()
   "Complete the minibuffer history as far as possible.
-- 
2.38.0

Message #106 received at 62700-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: sbaugh <at> catern.com
Cc: 62700-done <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion
 behave unintuitively when point is not at end of buffer
Date: Tue, 02 May 2023 20:57:27 +0300

> From: sbaugh <at> catern.com
> Date: Tue, 02 May 2023 15:13:21 +0000 (UTC)
> Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, juri <at> linkov.net
> 
> OK, here's the patch with this change.
> 
> (As discussed elsewhere in the thread, the patch includes changes to
> minibuffer-choose-completion because that function also is affected by
> the bug and also needs to be fixed)

Thanks, installed on the emacs-29 branch, and closing the bug.

Please in the future try to remember to mention the bug number in the
commit log messages, once the number is known.  You forgot that in the
two changesets I just installed, so I needed to amend that manually.

Message #109 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com, sbaugh <at> janestreet.com
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Mon, 08 May 2023 18:48:12 +0300

> Thanks, installed on the emacs-29 branch, and closing the bug.

Should the original patch be installed to master now?
That is the simpler fix mentioned in the commit
e338a8ac41d4a9fd798dda90275abe75ac071335:

  This is a backport for the Emacs 29 release branch of a simpler
  fix in minibuffer-completion-help.

Message #112 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com, sbaugh <at> janestreet.com
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Mon, 08 May 2023 19:11:58 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: sbaugh <at> catern.com,  62700 <at> debbugs.gnu.org,  sbaugh <at> janestreet.com
> Date: Mon, 08 May 2023 18:48:12 +0300
> 
> > Thanks, installed on the emacs-29 branch, and closing the bug.
> 
> Should the original patch be installed to master now?

It's up to you.

Message #115 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Fri, 02 Jun 2023 20:58:52 -0400

[Message part 1 (text/plain, inline)]

It turns out my patch doesn't fully fix the issue, when doing completion
at the end of a file path.  For example:

1. C-x C-f ~/src/emacs/emacs-29/lisp/.el
2. TAB to trigger completion, moving point to before .el
3. M-<down>
4. The filenames are inserted before the .el, so one gets for example
   ~/src/emacs/emacs-29/lisp/abbrev.el.el

The attached patch for the Emacs 29 branch fixes this remaining case.

[0001-Handle-point-in-last-file-path-component-in-minibuff.patch (text/x-patch, inline)]

From 33f9cfa6afb7ae232ed6d5bbc4692a463f57a7a8 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Fri, 2 Jun 2023 20:57:32 -0400
Subject: [PATCH] Handle point in last file path component in minibuffer
 completion

This is a followup to commit e338a8ac41d4a9fd798dda90275abe75ac071335
(Handle point not at EOB in minibuffer-choose-completion).

That added a heuristic, but the heuristic was insufficient: It still
had the original wrong behavior when completing the last file path
component (i.e., the completion category is 'file and there's no /
after point).  This patch makes the heuristic cover that case too.

* lisp/minibuffer.el (minibuffer-next-completion)
(minibuffer-choose-completion): If in file completion and there's no /
after point, clear what's after point when we complete.  (Bug#62700)
---
 lisp/minibuffer.el | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 298f3f8728d..a873e5f9747 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -4498,8 +4498,9 @@ minibuffer-next-completion
                (base-suffix
                 (if (eq (alist-get 'category (cdr md)) 'file)
                     (with-current-buffer buf
-                      (buffer-substring (save-excursion (search-forward "/" nil t) (point))
-                                        (point-max)))
+                      (buffer-substring
+                       (save-excursion (or (search-forward "/" nil t) (point-max)))
+                       (point-max)))
                   ""))
               (completion-base-affixes (list (car completion-base-affixes) base-suffix)))
           (choose-completion nil t t))))))
@@ -4524,8 +4525,9 @@ minibuffer-choose-completion
   (let* ((md (completion--field-metadata (minibuffer--completion-prompt-end)))
          (base-suffix
           (if (eq (alist-get 'category (cdr md)) 'file)
-              (buffer-substring (save-excursion (search-forward "/" nil t) (point))
-                                (point-max))
+              (buffer-substring
+               (save-excursion (or (search-forward "/" nil t) (point-max)))
+               (point-max))
             "")))
     (with-minibuffer-completions-window
       (let ((completion-use-base-affixes t)
-- 
2.39.3

Message #118 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com, juri <at> linkov.net
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Sun, 04 Jun 2023 10:09:16 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: Juri Linkov <juri <at> linkov.net>,  62700 <at> debbugs.gnu.org,  sbaugh <at> catern.com
> Date: Fri, 02 Jun 2023 20:58:52 -0400
> 
> It turns out my patch doesn't fully fix the issue, when doing completion
> at the end of a file path.  For example:
> 
> 1. C-x C-f ~/src/emacs/emacs-29/lisp/.el
> 2. TAB to trigger completion, moving point to before .el
> 3. M-<down>
> 4. The filenames are inserted before the .el, so one gets for example
>    ~/src/emacs/emacs-29/lisp/abbrev.el.el
> 
> The attached patch for the Emacs 29 branch fixes this remaining case.

Thanks, installed.

Please in the future try to avoid using "path" for anything other than
PATH-style directory lists: the GNU Coding Standards frown on such
usage.  (I fixed a couple of such uses in the commit log message
before pushing.)

Message #121 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: sbaugh <at> janestreet.com
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Sat, 10 Jun 2023 13:51:49 +0300

> Date: Mon, 08 May 2023 19:11:58 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com, sbaugh <at> janestreet.com
> 
> > From: Juri Linkov <juri <at> linkov.net>
> > Cc: sbaugh <at> catern.com,  62700 <at> debbugs.gnu.org,  sbaugh <at> janestreet.com
> > Date: Mon, 08 May 2023 18:48:12 +0300
> > 
> > > Thanks, installed on the emacs-29 branch, and closing the bug.
> > 
> > Should the original patch be installed to master now?
> 
> It's up to you.

I don't know what you did after this message, but today I merged from
emacs-29 to master and got conflicts in minibuffer.el.  The conflicts
were strange: they seemed to be caused by gitmerge.el attempting to
merge backported changes?  That should not happen.

Would you please look at minibuffer.el on the master branch and see if
anything there needs fixing?

Thanks.

Message #124 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, sbaugh <at> catern.com
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Mon, 12 Jun 2023 21:27:11 +0300

>> > > Thanks, installed on the emacs-29 branch, and closing the bug.
>> > 
>> > Should the original patch be installed to master now?
>> 
>> It's up to you.
>
> I don't know what you did after this message,

I didn't install on master anything because I refrain from developing
new features on master until emacs-29 is released to avoid merge conflicts.

> but today I merged from emacs-29 to master and got conflicts in
> minibuffer.el.  The conflicts were strange: they seemed to be caused
> by gitmerge.el attempting to merge backported changes?  That should
> not happen.

The merge conflict occurred because the first commit e338a8ac41d
was pushed to emacs-29 with the keyword "backport", but 2a84ab905c8
without any keyword that would prevent an attempt of its merge to master.

> Would you please look at minibuffer.el on the master branch and see if
> anything there needs fixing?

I checked that no problems occurred in minibuffer.el on the master branch.

So probably I will continue installing postponed patches to master
since merge conflicts are really not a problem.

Message #127 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, sbaugh <at> catern.com
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Tue, 13 Jun 2023 05:32:10 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: sbaugh <at> janestreet.com,  62700 <at> debbugs.gnu.org,  sbaugh <at> catern.com
> Date: Mon, 12 Jun 2023 21:27:11 +0300
> 
> > but today I merged from emacs-29 to master and got conflicts in
> > minibuffer.el.  The conflicts were strange: they seemed to be caused
> > by gitmerge.el attempting to merge backported changes?  That should
> > not happen.
> 
> The merge conflict occurred because the first commit e338a8ac41d
> was pushed to emacs-29 with the keyword "backport", but 2a84ab905c8
> without any keyword that would prevent an attempt of its merge to master.
> 
> > Would you please look at minibuffer.el on the master branch and see if
> > anything there needs fixing?
> 
> I checked that no problems occurred in minibuffer.el on the master branch.

Thanks.  I wasn't sure that my manual resolution of the merge conflict
in this case was correct.

Message #130 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, sbaugh <at> catern.com
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Tue, 13 Jun 2023 19:54:04 +0300

>> > but today I merged from emacs-29 to master and got conflicts in
>> > minibuffer.el.  The conflicts were strange: they seemed to be caused
>> > by gitmerge.el attempting to merge backported changes?  That should
>> > not happen.
>>
>> The merge conflict occurred because the first commit e338a8ac41d
>> was pushed to emacs-29 with the keyword "backport", but 2a84ab905c8
>> without any keyword that would prevent an attempt of its merge to master.
>>
>> > Would you please look at minibuffer.el on the master branch and see if
>> > anything there needs fixing?
>>
>> I checked that no problems occurred in minibuffer.el on the master branch.
>
> Thanks.  I wasn't sure that my manual resolution of the merge conflict
> in this case was correct.

I looked at the patch that should be pushed to master, and noticed
that probably it needs the same change that was applied in emacs-29.
Maybe Spencer could confirm what would be the right patch for master.

Message #133 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> janestreet.com, sbaugh <at> catern.com
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Tue, 13 Jun 2023 19:59:04 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: sbaugh <at> janestreet.com,  62700 <at> debbugs.gnu.org,  sbaugh <at> catern.com
> Date: Tue, 13 Jun 2023 19:54:04 +0300
> 
> >> I checked that no problems occurred in minibuffer.el on the master branch.
> >
> > Thanks.  I wasn't sure that my manual resolution of the merge conflict
> > in this case was correct.
> 
> I looked at the patch that should be pushed to master, and noticed
> that probably it needs the same change that was applied in emacs-29.
> Maybe Spencer could confirm what would be the right patch for master.

Yes, Spencer, please take a look.

Message #136 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Tue, 13 Jun 2023 16:59:19 -0400

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Juri Linkov <juri <at> linkov.net>
>> Cc: sbaugh <at> janestreet.com,  62700 <at> debbugs.gnu.org,  sbaugh <at> catern.com
>> Date: Tue, 13 Jun 2023 19:54:04 +0300
>> 
>> >> I checked that no problems occurred in minibuffer.el on the master branch.
>> >
>> > Thanks.  I wasn't sure that my manual resolution of the merge conflict
>> > in this case was correct.
>> 
>> I looked at the patch that should be pushed to master, and noticed
>> that probably it needs the same change that was applied in emacs-29.
>> Maybe Spencer could confirm what would be the right patch for master.
>
> Yes, Spencer, please take a look.

Indeed it needs the same change.  Here's the version of the patch that
should be pushed to master.

[0001-Handle-point-not-at-EOB-in-minibuffer-choose-complet.patch (text/x-patch, inline)]

From 4769e70e2e9af6eb68947d6c2ed0dcff0831def0 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Mon, 24 Apr 2023 10:05:24 -0400
Subject: [PATCH] Handle point not at EOB in minibuffer-choose-completion

Without this change, only the minibuffer contents before point are
cleared when a completion is chosen, which results in stray text when
point is in the middle of the minibuffer.

After this change, we heuristically decide either to clear the whole
buffer or only part of it, taking into account the location of point.

* lisp/minibuffer.el (minibuffer-completion-help): Use point when
calculating completion-base-affixes. (Bug#62700)
---
 lisp/minibuffer.el | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 539206a19e4..d079dc0bcdf 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2395,7 +2395,11 @@ minibuffer-completion-help
              (prefix (unless (zerop base-size) (substring string 0 base-size)))
              (base-prefix (buffer-substring (minibuffer--completion-prompt-end)
                                             (+ start base-size)))
-             (base-suffix (buffer-substring (point) (point-max)))
+             (base-suffix
+              (if (eq (alist-get 'category (cdr md)) 'file)
+                  (buffer-substring (save-excursion (or (search-forward "/" nil t) (point-max)))
+                                    (point-max))
+                ""))
              (all-md (completion--metadata (buffer-substring-no-properties
                                             start (point))
                                            base-size md
-- 
2.39.3

Message #139 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Wed, 14 Jun 2023 20:32:27 +0300

>>> I looked at the patch that should be pushed to master, and noticed
>>> that probably it needs the same change that was applied in emacs-29.
>>> Maybe Spencer could confirm what would be the right patch for master.
>>
>> Yes, Spencer, please take a look.
>
> Indeed it needs the same change.  Here's the version of the patch that
> should be pushed to master.

Thanks, now pushed to master.

Message #148 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Sun, 03 Sep 2023 20:37:15 +0300

> Without this change, only the minibuffer contents before point are
> cleared when a completion is chosen, which results in stray text when
> point is in the middle of the minibuffer.
>
> After this change, we heuristically decide either to clear the whole
> buffer or only part of it, taking into account the location of point.
>
> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
> index 539206a19e4..d079dc0bcdf 100644
> --- a/lisp/minibuffer.el
> +++ b/lisp/minibuffer.el
> @@ -2395,7 +2395,11 @@ minibuffer-completion-help
>               (prefix (unless (zerop base-size) (substring string 0 base-size)))
>               (base-prefix (buffer-substring (minibuffer--completion-prompt-end)
>                                              (+ start base-size)))
> -             (base-suffix (buffer-substring (point) (point-max)))
> +             (base-suffix
> +              (if (eq (alist-get 'category (cdr md)) 'file)
> +                  (buffer-substring (save-excursion (or (search-forward "/" nil t) (point-max)))
> +                                    (point-max))
> +                ""))

As was found in bug#64903, this change broke completion-in-region.
For example, with (setq completion-use-base-affixes t)
if there is some text in the current buffer after point,
then typing 'M-C-i' and selecting a candidate to insert to the buffer,
it replaces all the text after point with an empty string.

Before this change, the suffix was set to the text after point,
and after inserting the selected candidate the suffix was
re-inserted to the same buffer.

Message #151 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: sbaugh <at> catern.com
To: Juri Linkov <juri <at> linkov.net>
Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> janestreet.com>
Subject: Re: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion
 behave unintuitively when point is not at end of buffer
Date: Mon, 04 Sep 2023 00:30:16 +0000 (UTC)

Juri Linkov <juri <at> linkov.net> writes:

>> Without this change, only the minibuffer contents before point are
>> cleared when a completion is chosen, which results in stray text when
>> point is in the middle of the minibuffer.
>>
>> After this change, we heuristically decide either to clear the whole
>> buffer or only part of it, taking into account the location of point.
>>
>> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
>> index 539206a19e4..d079dc0bcdf 100644
>> --- a/lisp/minibuffer.el
>> +++ b/lisp/minibuffer.el
>> @@ -2395,7 +2395,11 @@ minibuffer-completion-help
>>               (prefix (unless (zerop base-size) (substring string 0 base-size)))
>>               (base-prefix (buffer-substring (minibuffer--completion-prompt-end)
>>                                              (+ start base-size)))
>> -             (base-suffix (buffer-substring (point) (point-max)))
>> +             (base-suffix
>> +              (if (eq (alist-get 'category (cdr md)) 'file)
>> +                  (buffer-substring (save-excursion (or (search-forward "/" nil t) (point-max)))
>> +                                    (point-max))
>> +                ""))
>
> As was found in bug#64903, this change broke completion-in-region.
> For example, with (setq completion-use-base-affixes t)
> if there is some text in the current buffer after point,
> then typing 'M-C-i' and selecting a candidate to insert to the buffer,
> it replaces all the text after point with an empty string.
>
> Before this change, the suffix was set to the text after point,
> and after inserting the selected candidate the suffix was
> re-inserted to the same buffer.

How can this be the cause of bug#64903?  Wasn't that bug reproduced on
Emacs 28?  This change only went in to 29.

Message #154 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: sbaugh <at> catern.com
Cc: 62700 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> janestreet.com>
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Mon, 04 Sep 2023 09:51:04 +0300

>>> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
>>> index 539206a19e4..d079dc0bcdf 100644
>>> --- a/lisp/minibuffer.el
>>> +++ b/lisp/minibuffer.el
>>> @@ -2395,7 +2395,11 @@ minibuffer-completion-help
>>>               (prefix (unless (zerop base-size) (substring string 0 base-size)))
>>>               (base-prefix (buffer-substring (minibuffer--completion-prompt-end)
>>>                                              (+ start base-size)))
>>> -             (base-suffix (buffer-substring (point) (point-max)))
>>> +             (base-suffix
>>> +              (if (eq (alist-get 'category (cdr md)) 'file)
>>> +                  (buffer-substring (save-excursion (or (search-forward "/" nil t) (point-max)))
>>> +                                    (point-max))
>>> +                ""))
>>
>> As was found in bug#64903, this change broke completion-in-region.
>> For example, with (setq completion-use-base-affixes t)
>> if there is some text in the current buffer after point,
>> then typing 'M-C-i' and selecting a candidate to insert to the buffer,
>> it replaces all the text after point with an empty string.
>>
>> Before this change, the suffix was set to the text after point,
>> and after inserting the selected candidate the suffix was
>> re-inserted to the same buffer.
>
> How can this be the cause of bug#64903?  Wasn't that bug reproduced on
> Emacs 28?  This change only went in to 29.

bug#64903 is a related but completely separate case.

The patch above went in to master, so in-buffer completion
with non-nil completion-use-base-affixes is broken only
in master, but fortunately not broken in emacs-29.

Message #157 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Tue, 14 Nov 2023 09:39:49 +0200

[Message part 1 (text/plain, inline)]

> For example, with (setq completion-use-base-affixes t)
> if there is some text in the current buffer after point,
> then typing 'M-C-i' and selecting a candidate to insert to the buffer,
> it replaces all the text after point with an empty string.
>
> Before this change, the suffix was set to the text after point,
> and after inserting the selected candidate the suffix was
> re-inserted to the same buffer.

Here is a patch that should support 'completion-in-region':

[minibuffer-completion-help-base-suffix.patch (text/x-diff, inline)]

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 07a284134d6..a2d0fabd9c5 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2405,9 +2410,14 @@ minibuffer-completion-help
              (base-prefix (buffer-substring (minibuffer--completion-prompt-end)
                                             (+ start base-size)))
              (base-suffix
-              (if (eq (alist-get 'category (cdr md)) 'file)
-                  (buffer-substring (save-excursion (or (search-forward "/" nil t) (point-max)))
-                                    (point-max))
+              (if (or (eq (alist-get 'category (cdr md)) 'file)
+                      completion-in-region-mode-predicate)
+                  (buffer-substring
+                   (save-excursion
+                     (if completion-in-region-mode-predicate
+                         (point)
+                       (or (search-forward "/" nil t) (point-max))))
+                   (point-max))
                 ""))
              (all-md (completion--metadata (buffer-substring-no-properties
                                             start (point))

Message #160 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 62700 <at> debbugs.gnu.org, sbaugh <at> catern.com
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Wed, 15 Nov 2023 19:42:26 +0200

close 62700 30.0.50
thanks

>> For example, with (setq completion-use-base-affixes t)
>> if there is some text in the current buffer after point,
>> then typing 'M-C-i' and selecting a candidate to insert to the buffer,
>> it replaces all the text after point with an empty string.
>>
>> Before this change, the suffix was set to the text after point,
>> and after inserting the selected candidate the suffix was
>> re-inserted to the same buffer.
>
> Here is a patch that should support 'completion-in-region':

Pushed to master now.

Message #169 received at 62700 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 62700 <at> debbugs.gnu.org
Subject: Re: bug#62700: 29.0.60;
 minibuffer-{previous,next,choose}-completion behave unintuitively when
 point is not at end of buffer
Date: Sun, 07 Apr 2024 20:16:03 +0300

>>> 6. C-h v -path
>>> 7. C-a to move point to before -path
>>> 8. <tab> to show completions of variables ending in -path
>>> 9. Use M-<up> and M-<down> to switch between completions.  Now as you
>>> switch completions, they are inserted at point, *without* replacing the
>>> text already in the buffer.  So e.g. the minibuffer will contain
>>> "load-path-path".
>>> 10. Likewise, if you (setq minibuffer-completion-auto-choose nil), M-RET
>>> inserts the completion string at point, without replacing the text in
>>> the minibuffer, so you will get "load-path-path".
>>>
>>> I think this is basically just a bug.  Hopefully we can fix this before
>>> Emacs 29 is released, because this is the last thing which stops these
>>> new commands from being a really great improvement to the Emacs
>>> completion defaults.
>>
>> I agree that it would be nice to fix this in Emacs 29.
>> But the problem is that this would require non-trivial changes.
>> We need to apply a small part of the patch mentioned in
>> bug#47711, bug#48356, bug#48841, bug#60313 and located at
>> https://lists.gnu.org/archive/html/emacs-devel/2021-08/msg00412.html
>> that implements the following FIXME item in 'completion-all-completions':
>>
>>   ;; FIXME: We need to additionally return the info needed for the
>>   ;; second part of completion-base-position.
>>
>> When it will return from 'completion-all-completions' not only the start
>> position of a completion, but also its end, then we could use this
>> additional information for M-<up> and M-<down>.
>
> BTW: do you know if anyone has done any more work on resolving this
> FIXME?

I'm not aware of anyone working on this FIXME.
The last complete patch was posted by Daniel Mendler to
https://lists.gnu.org/archive/html/emacs-devel/2021-08/msg00412.html
and to bug#47711.

> Maybe there's an open bug for it, or some work I could start
> from?

There are two open bug reports: bug#47711 and bug#48356.

> I'm running into bug#62700 again for completion tables which use
> boundaries but aren't file completion.  The heuristic I added only works
> for file completion, but I'm working on a completion table which uses
> boundaries for completing dotted.field.paths in OCaml, and so completing
> at dotted.fie|.paths inserts "dotted.field." and deletes the "paths"
> part.  To fix this, I think I should just fix this FIXME once and for
> all (and then we can delete the heuristic I added)

The patch created by Daniel Mendler should resolve this FIXME,
maybe after some minor updates.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.