bug#56613: 29; minibuffer-complete-history throws an error for minibuffer-history-variable=t

[Daniel Mendler]

On 7/18/22 17:01, Stefan Monnier wrote:
>> But I can't find a function that would return the
>> current completion boundaries to use instead of hard-coding
>> minibuffer--completion-prompt-end and point-max.  Then
>> completing-read-multiple should set locally such a function
>> that will use crm-separator and return a cons (BEG . END).
> 
> I can't remember what hacks are used in CRM, but we do have "a function
> that would return the current completion boundaries to use": it's what
> `completion-at-point-functions` is for.
> 
> I think the long-term direction is clear: `completion-at-point` should
> be used not just "in buffer" but in the minibuffer as well.
> We could start that journey by making use of it for CRM.

Not sure if I agree with this in full generality. The question is if you
define completion only as completion of text or if you also accept the
selection paradigm, where are a bunch of candidates are offered and
filtered. The selection paradigm is used in most popular applications
(web browser history, form filling). In Emacs we have Icomplete, Ivy,
Vertico, etc. which implement that paradigm.

For CRM I agree that completion-at-point makes sense, since there we are
indeed doing step wise completion of multiple components. But I am not a
fan of CRM and I don't like its API design. It is not widely used and
the resulting UI is quite inconvenient. For example if you want to
select among a bunch of very long candidates the CRM UI doesn't work at
all. For this reason, org-cite and the Citar package instead call
completing-read in a loop to select multiple candidates. I've also
replaced most of my potential CRM use cases with completing-read in
combination with Embark. Embark can be used to act on multiple
candidates. Using single candidate completing-read as basis leads to a
system which is more composable overall.

Anyway because I am critical of CRM I would be cautious to use it as an
example which guides a potential redesign of the completion mechanism.

Daniel