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

Full log

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.

Previous Next

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