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

[James N . V . Cash]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> This makes it specific to CRM.  I think we should try and think more
> locally, without paying too much attention about the various possible
> external cases: what do we want the `beg` and `end` strings to *mean*?
>
> Maybe instead of strings, they should be functions, so CRM can set them
> to functions that first look for the separator and then search for some
> leading/trailing string?

Upon further inspection, I see that `minibuffer-completion-help` is setting
`completion-list-insert-choice-function` to a function that checks if the `beg`
and `end` arguments are strings, in which case it just replaces the
minibuffer contents with "beg" + "choice" + "end". Indeed, when doing
`completing-read` instead of `completing-read-multiple`,
`completion--replace` doesn't get called at all in this case.

On one hand, that *might* mean that this particular code path
(completion--replace being called with `beg` and `end` strings)
necessarily means it's a completing-read-multiple, so searching for the
crm-separator is justifiable. On the other, a better solution than my
patch then might be to figure out why that function is being "lost" in
the completion-read-multiple case, so the "replace minibuffer contents
with beg + selection + end" behaviour happens there too (maybe,
arguably, in the CRM case in particular, deleting part of the prefix
then selecting a completion makes sense, but in the normal case, the
current behaviour (essentially, ignoring edits that have happened in the
prefix) seems like the only sensible thing to do).

James