diff options
| author | Spencer Baugh | 2025-08-14 15:15:29 -0400 |
|---|---|---|
| committer | Juri Linkov | 2025-10-09 20:50:30 +0300 |
| commit | e2567eab108aa0b452fe7d84f501ef05b16429bb (patch) | |
| tree | eda7c9a70456fa48c98b5ca7ef9cf11e2a65bba2 /java | |
| parent | 7c7bfa625ee3cc0e7ae8aec2a989e1dc14bfe6a7 (diff) | |
| download | emacs-e2567eab108aa0b452fe7d84f501ef05b16429bb.tar.gz emacs-e2567eab108aa0b452fe7d84f501ef05b16429bb.zip | |
Treat a completion boundary change as completion
In completion--do-completion, check if completion-try-completion
moved point out of the old completion boundaries. If that
happened, then we did non-trivial completion even if the string
is otherwise unchanged.
For example,
~/src/emacs/trunk/lisp|/progmodes/project.el
hitting TAB moves us to:
~/src/emacs/trunk/lisp/|progmodes/project.el
then hitting TAB again moves us to
~/src/emacs/trunk/lisp/progmodes/|project.el
Both of these completions are successful, but we previously ran
code for completion failure (the t branch of the cond in
completion--do-completion) in the second case. In particular,
we would always run minibuffer-completion-help, ignoring the
specific value of completion-auto-help which controls whether or
not to run minibuffer-completion-help. Now we correctly run
code for successful completion for both cases.
We also always have checked that we're in the same boundaries
before doing completion cycling; that check is now more
accurate (bug#79238).
* lisp/minibuffer.el (completion--in-boundaries-p): Add.
(completion--do-completion): Check completion--in-boundaries-p.
Diffstat (limited to 'java')
0 files changed, 0 insertions, 0 deletions