Re: [PATCH] Handle case where `beg` and `end` are strings instead of markers

[Stefan Monnier]

James N. V. Cash [2022-04-29 10:07:33] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> +  (let ((beg (if (number-or-marker-p beg)
>>> +                 beg
>>> +               (save-excursion
>>> +                 (goto-char (minibuffer-prompt-end))
>>> +                 (search-forward beg))))
>>> +        (end (if (number-or-marker-p end)
>>> +                 end
>>> +               (save-excursion
>>> +                 (goto-char (point-max))
>>> +                 (search-backward end)))))
>>
>> What if there are several matches for `beg` and/or for `end` in
>> the buffer?  How do we know we got the intended one?
>
> A good question; as far as I can tell though, `beg` and `end` are only
> strings when called via `choose-completion` in `simple.el`, when it
> passes in `base-affixes`. `base-affixes` is in turn set to
> `completion-base-affixes`, which gets set in
> `minibuffer-completion-help`. There, the value that becomes `beg` is
> `(buffer-substring (minibuffer--completion-prompt-end) (+ start base-size))`
> and `end` is `(buffer-substring (point) (point-max))`, so I think that 
> changing
> `minibuffer-prompt-end` in my patch to
> `minibuffer--completion-prompt-end` would suffice to ensure that it is
> always matching from the correct point to match the intended positions.

I think rather than (minibuffer--completion-prompt-end) and (point-max),
we should be using "the beginning of the completion area" and "the end
of the completion area".  In a typical minibuffer completion, that's
exactly the same, but in `completing-read-multiple` or
`complete-in-region` the difference can be significant.


        Stefan