Re: Add completion to compilation-read-command

[Spyros Roum <spyros.roum@posteo.net>]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

Philip Kaludercic wrote:
> Spyros Roum<spyros.roum@posteo.net> writes:
>
>> Juri Linkov wrote:
>>>> I'm trying to get the compile prompt to suggest completion based on past
>>>> commands I've run.
>>> You can use 'C-x <up>' in the compile prompt to complete on past commands.
>> This is indeed a lot closer to what I want, however it still lacks a
>> lot of things compared to my solution.
>>
>> Unless there is some package/mode I don't know about, It's a lot less
>> dynamic, for instance I can't keep typing to reduce
>> possible items.
> One should keep in mind that completion is not the same as narrowing.
> The former expands substrings, while the latter is more like a system
> for selecting an option from a list, that usually comes with some query
> system.
>                
> Confusing these two can lead to uncomfortable edge-cases for both sides,
> and sadly a lot of packages assume that completing-read is the same as a
> hypothetical selecting-read.
I was 100% confusing these two, thanks for clearing it up.
To make sure I understand correctly, when using `completing-read` to 
read user input, that is narrowing,
while the `C-x <up>` and *Completions* buffer is completion. And from 
this thread I learned that Icicles can be used to enhance completion
similarly to how narrowing frameworks (like vertico) enhance narrowing.
>> My solution can leverage all of vertico and friend, and in general
>> provides an experience that's the same as other minibuffer prompts,
>> like M-x.
> But for someone like me who doesn't use a selecting-narrowing framework
> like vertico, it suddenly means that SPC is rebound to
> `minibuffer-complete-word' and entering new commands becomes *a lot* more
> cumbersome.
And this is where the user option for the function would come in useful.

[-- Attachment #2: Type: text/html, Size: 3019 bytes --]