aboutsummaryrefslogtreecommitdiffstats
path: root/java
diff options
context:
space:
mode:
authorSpencer Baugh2025-08-14 15:15:29 -0400
committerJuri Linkov2025-10-09 20:50:30 +0300
commite2567eab108aa0b452fe7d84f501ef05b16429bb (patch)
treeeda7c9a70456fa48c98b5ca7ef9cf11e2a65bba2 /java
parent7c7bfa625ee3cc0e7ae8aec2a989e1dc14bfe6a7 (diff)
downloademacs-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