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

[James N . V . Cash]

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.

James