Add completion to compilation-read-command

Add completion to compilation-read-command

[Spyros Roum]

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

Hello all,

Recently, I started using `M-x compile` more but as I was used to my 
shell suggesting past commands as I type (and tools like atuin), I was 
missing auto-complete a lot.
I managed to add this functionality by writing a simple function based 
on compilation-read-command that uses completing-read instead of 
read-shell-command.
Then I used advice-add to overwrite the 
original compilation-read-command with mine.

So far this works well, and as far as I can tell there is no good reason 
not to make compile auto-completing, it already has a history that you 
can navigate anyway.

With that said, this is the first time I write here and the first time 
I'm trying to contribute to emacs, so I'm not sure what the best way to 
go from here would be.
I think some decisions would need to be taken, for once I am not sure if 
it's acceptable to change the default and make it completing or if there 
should be an option for it.

Looking forward to your feedback, thanks

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

Re: Add completion to compilation-read-command

[Philip Kaludercic]

Spyros Roum <spyros.roum@posteo.net> writes:

> Hello all,
>
> Recently, I started using `M-x compile` more but as I was used to my
> shell suggesting past commands as I type (and tools like atuin)

In case anyone else hasn't heard of this, it describes itself as

  Atuin replaces your existing shell history with a SQLite database, and
  records additional context for your commands. Additionally, it
  provides optional and fully encrypted synchronisation of your history
  between machines, via an Atuin server.

(https://github.com/atuinsh/atuin)

>                                                                , I was
> missing auto-complete a lot.
> I managed to add this functionality by writing a simple function based
> on compilation-read-command that uses completing-read instead of
> read-shell-command.

Do you know about the `bash-completion' package?  It enhances
`read-shell-command' completion with completion data provided by bash.
It is very easy to set up,

  (use-package bash-completion :ensure t
    :init (bash-completion-setup))

should do it.

> Then I used advice-add to overwrite the
> original compilation-read-command with mine.
>
> So far this works well, and as far as I can tell there is no good
> reason not to make compile auto-completing, it already has a history
> that you can navigate anyway.
>
> With that said, this is the first time I write here and the first time
> I'm trying to contribute to emacs, so I'm not sure what the best way
> to go from here would be.
> I think some decisions would need to be taken, for once I am not sure
> if it's acceptable to change the default and make it completing or if
> there should be an option for it.

I am not sure if you meant to attach any code, but that would probably
be the best place to start.

> Looking forward to your feedback, thanks

Re: Add completion to compilation-read-command

[Spyros Roum]

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


Philip Kaludercic wrote:
> Spyros Roum<spyros.roum@posteo.net> writes:
>
>> Hello all,
>>
>> Recently, I started using `M-x compile` more but as I was used to my
>> shell suggesting past commands as I type (and tools like atuin)
> In case anyone else hasn't heard of this, it describes itself as
>
>    Atuin replaces your existing shell history with a SQLite database, and
>    records additional context for your commands. Additionally, it
>    provides optional and fully encrypted synchronisation of your history
>    between machines, via an Atuin server.
>
> (https://github.com/atuinsh/atuin)

Thanks for adding the description, I should have done that myself.


>>                                                                 , I was
>> missing auto-complete a lot.
>> I managed to add this functionality by writing a simple function based
>> on compilation-read-command that uses completing-read instead of
>> read-shell-command.
> Do you know about the `bash-completion' package?  It enhances
> `read-shell-command' completion with completion data provided by bash.
> It is very easy to set up,
>
>    (use-package bash-completion :ensure t
>      :init (bash-completion-setup))
>
> should do it.

I was not aware of this, but it doesn't seem to do what I'm looking for.
For once, I am not using bash, but even ignoring that it doesn't seem to 
have the effect I'm looking for.

I'm trying to get the compile prompt to suggest completion based on past 
commands I've run.


>> Then I used advice-add to overwrite the
>> original compilation-read-command with mine.
>>
>> So far this works well, and as far as I can tell there is no good
>> reason not to make compile auto-completing, it already has a history
>> that you can navigate anyway.
>>
>> With that said, this is the first time I write here and the first time
>> I'm trying to contribute to emacs, so I'm not sure what the best way
>> to go from here would be.
>> I think some decisions would need to be taken, for once I am not sure
>> if it's acceptable to change the default and make it completing or if
>> there should be an option for it.
> I am not sure if you meant to attach any code, but that would probably
> be the best place to start.
>
>> Looking forward to your feedback, thanks

You are right I should have posted code, so here is what I have:

   (defun compilation-read-command-with-autocomplete (command)
     "Use `completing-read` to add autocomplete powers to compilation read"
     (completing-read "Compile command: " compile-history
       nil nil command
       (if (equal (car compile-history) command)
         '(compile-history . 1)
         'compile-history)))

   (advice-add
     #'compilation-read-command
     :override #'compilation-read-command-with-autocomplete)

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

Re: Add completion to compilation-read-command

[Philip Kaludercic]

Spyros Roum <spyros.roum@posteo.net> writes:

> Philip Kaludercic wrote:
>> Spyros Roum<spyros.roum@posteo.net> writes:
>>
>>> Hello all,
>>>
>>> Recently, I started using `M-x compile` more but as I was used to my
>>> shell suggesting past commands as I type (and tools like atuin)
>> In case anyone else hasn't heard of this, it describes itself as
>>
>>    Atuin replaces your existing shell history with a SQLite database, and
>>    records additional context for your commands. Additionally, it
>>    provides optional and fully encrypted synchronisation of your history
>>    between machines, via an Atuin server.
>>
>> (https://github.com/atuinsh/atuin)
>
> Thanks for adding the description, I should have done that myself.

No worries.

>>>                                                                 , I was
>>> missing auto-complete a lot.
>>> I managed to add this functionality by writing a simple function based
>>> on compilation-read-command that uses completing-read instead of
>>> read-shell-command.
>> Do you know about the `bash-completion' package?  It enhances
>> `read-shell-command' completion with completion data provided by bash.
>> It is very easy to set up,
>>
>>    (use-package bash-completion :ensure t
>>      :init (bash-completion-setup))
>>
>> should do it.
>
> I was not aware of this, but it doesn't seem to do what I'm looking for.
> For once, I am not using bash, but even ignoring that it doesn't seem
> to have the effect I'm looking for.
>
> I'm trying to get the compile prompt to suggest completion based on
> past commands I've run.

My bad.  In that case, why not use C-r to search `compile-history'?

>
>>> Then I used advice-add to overwrite the
>>> original compilation-read-command with mine.
>>>
>>> So far this works well, and as far as I can tell there is no good
>>> reason not to make compile auto-completing, it already has a history
>>> that you can navigate anyway.
>>>
>>> With that said, this is the first time I write here and the first time
>>> I'm trying to contribute to emacs, so I'm not sure what the best way
>>> to go from here would be.
>>> I think some decisions would need to be taken, for once I am not sure
>>> if it's acceptable to change the default and make it completing or if
>>> there should be an option for it.
>> I am not sure if you meant to attach any code, but that would probably
>> be the best place to start.
>>
>>> Looking forward to your feedback, thanks
>
> You are right I should have posted code, so here is what I have:
>
>   (defun compilation-read-command-with-autocomplete (command)
>     "Use `completing-read` to add autocomplete powers to compilation read"
>     (completing-read "Compile command: " compile-history
>       nil nil command
>       (if (equal (car compile-history) command)
>         '(compile-history . 1)
>         'compile-history)))
>
>   (advice-add
>     #'compilation-read-command
>     :override #'compilation-read-command-with-autocomplete)

If this were added to Emacs, we probably wouldn't use advice.  I think
the best strategy for you would be to prepare a patch against compile.el
and add a user option that allows prompting the user with
completing-read.  What do you think?

Re: Add completion to compilation-read-command

[Spyros Roum]

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

Philip Kaludercic wrote:
>>>>                                                                  , I was
>>>> missing auto-complete a lot.
>>>> I managed to add this functionality by writing a simple function based
>>>> on compilation-read-command that uses completing-read instead of
>>>> read-shell-command.
>>> Do you know about the `bash-completion' package?  It enhances
>>> `read-shell-command' completion with completion data provided by bash.
>>> It is very easy to set up,
>>>
>>>     (use-package bash-completion :ensure t
>>>       :init (bash-completion-setup))
>>>
>>> should do it.
>> I was not aware of this, but it doesn't seem to do what I'm looking for.
>> For once, I am not using bash, but even ignoring that it doesn't seem
>> to have the effect I'm looking for.
>>
>> I'm trying to get the compile prompt to suggest completion based on
>> past commands I've run.
> My bad.  In that case, why not use C-r to search `compile-history'?

I'm not sure if you are suggesting that I should be able to use C-r in 
the compile prompt, if so there might be a keybind issue as I'm using 
evil and C-r does not do that for me.
If that's the case, could you name the function that does that? It could 
be what I'm looking for.

>>>> Then I used advice-add to overwrite the
>>>> original compilation-read-command with mine.
>>>>
>>>> So far this works well, and as far as I can tell there is no good
>>>> reason not to make compile auto-completing, it already has a history
>>>> that you can navigate anyway.
>>>>
>>>> With that said, this is the first time I write here and the first time
>>>> I'm trying to contribute to emacs, so I'm not sure what the best way
>>>> to go from here would be.
>>>> I think some decisions would need to be taken, for once I am not sure
>>>> if it's acceptable to change the default and make it completing or if
>>>> there should be an option for it.
>>> I am not sure if you meant to attach any code, but that would probably
>>> be the best place to start.
>>>
>>>> Looking forward to your feedback, thanks
>> You are right I should have posted code, so here is what I have:
>>
>>    (defun compilation-read-command-with-autocomplete (command)
>>      "Use `completing-read` to add autocomplete powers to compilation read"
>>      (completing-read "Compile command: " compile-history
>>        nil nil command
>>        (if (equal (car compile-history) command)
>>          '(compile-history . 1)
>>          'compile-history)))
>>
>>    (advice-add
>>      #'compilation-read-command
>>      :override #'compilation-read-command-with-autocomplete)
> If this were added to Emacs, we probably wouldn't use advice.  I think
> the best strategy for you would be to prepare a patch against compile.el
> and add a user option that allows prompting the user with
> completing-read.  What do you think?

I agree advice is not a good solution if this gets merged, this is just 
what I have in my config to make it work.

I believe an option defaulting to the current behavior is fine, assuming 
we don't want to just change it to the completing version all together.
However, I am somewhat lost on what that option might look like. 
Probably some customizable option based on which 
compilation-read-command's internals change to either the current or my 
version?

If so, I will need to figure out how the customizable system works 
internally in order to use it. Any pointers on that would be appreciated.

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

Re: Add completion to compilation-read-command

[Philip Kaludercic]

Spyros Roum <spyros.roum@posteo.net> writes:

> Philip Kaludercic wrote:
>>>>>                                                                  , I was
>>>>> missing auto-complete a lot.
>>>>> I managed to add this functionality by writing a simple function based
>>>>> on compilation-read-command that uses completing-read instead of
>>>>> read-shell-command.
>>>> Do you know about the `bash-completion' package?  It enhances
>>>> `read-shell-command' completion with completion data provided by bash.
>>>> It is very easy to set up,
>>>>
>>>>     (use-package bash-completion :ensure t
>>>>       :init (bash-completion-setup))
>>>>
>>>> should do it.
>>> I was not aware of this, but it doesn't seem to do what I'm looking for.
>>> For once, I am not using bash, but even ignoring that it doesn't seem
>>> to have the effect I'm looking for.
>>>
>>> I'm trying to get the compile prompt to suggest completion based on
>>> past commands I've run.
>> My bad.  In that case, why not use C-r to search `compile-history'?
>
> I'm not sure if you are suggesting that I should be able to use C-r in
> the compile prompt, if so there might be a keybind issue as I'm using
> evil and C-r does not do that for me.
> If that's the case, could you name the function that does that? It
> could be what I'm looking for.

Oh, sorry about that.  C-r is just the regular `isearch-backward'
binding.

>>>>> Then I used advice-add to overwrite the
>>>>> original compilation-read-command with mine.
>>>>>
>>>>> So far this works well, and as far as I can tell there is no good
>>>>> reason not to make compile auto-completing, it already has a history
>>>>> that you can navigate anyway.
>>>>>
>>>>> With that said, this is the first time I write here and the first time
>>>>> I'm trying to contribute to emacs, so I'm not sure what the best way
>>>>> to go from here would be.
>>>>> I think some decisions would need to be taken, for once I am not sure
>>>>> if it's acceptable to change the default and make it completing or if
>>>>> there should be an option for it.
>>>> I am not sure if you meant to attach any code, but that would probably
>>>> be the best place to start.
>>>>
>>>>> Looking forward to your feedback, thanks
>>> You are right I should have posted code, so here is what I have:
>>>
>>>    (defun compilation-read-command-with-autocomplete (command)
>>>      "Use `completing-read` to add autocomplete powers to compilation read"
>>>      (completing-read "Compile command: " compile-history
>>>        nil nil command
>>>        (if (equal (car compile-history) command)
>>>          '(compile-history . 1)
>>>          'compile-history)))
>>>
>>>    (advice-add
>>>      #'compilation-read-command
>>>      :override #'compilation-read-command-with-autocomplete)
>> If this were added to Emacs, we probably wouldn't use advice.  I think
>> the best strategy for you would be to prepare a patch against compile.el
>> and add a user option that allows prompting the user with
>> completing-read.  What do you think?
>
> I agree advice is not a good solution if this gets merged, this is
> just what I have in my config to make it work.
>
> I believe an option defaulting to the current behavior is fine,
> assuming we don't want to just change it to the completing version all
> together.

I think that would be to invasive.

> However, I am somewhat lost on what that option might look
> like. Probably some customizable option based on which
> compilation-read-command's internals change to either the current or
> my version?

The easiest choice is just a user option that holds function, presumably
without taking any argument The default value would use regular
shell-read-command, and a suggested alternative could be your
suggestion.

> If so, I will need to figure out how the customizable system works
> internally in order to use it. Any pointers on that would be
> appreciated.

It will probably look something like this

        (defcustom compilation-prompt-function 
          #'complation-prompt-using-read-shell-command
          "[document the user option here]."
          :version "31.0"
          :type 'function)

Re: Add completion to compilation-read-command

[Juri Linkov]

> 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.

Re: Add completion to compilation-read-command

[Spyros Roum]

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

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.
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.

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

Re: Add completion to compilation-read-command

[Juri Linkov]

>> 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. 

There were many proposals how to implement `eager-update' to update
*Completions* as you type.  We just need to put together all parts.

Re: Add completion to compilation-read-command

[Spyros Roum]

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

Juri Linkov wrote:
>>> 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.
> There were many proposals how to implement `eager-update' to update
> *Completions* as you type.  We just need to put together all parts.

I'm probably out of my depth here, as I'm not very familiar with 
*Completions*.
Is there a good reason to stick to it when `completing-read` works well 
and as far as I can tell
does a very similar/the same job?

I have a patch almost ready based on Philip's feedback that I will be 
sharing today or tomorrow.
If, however, the consensus is that it's not a good fit and that `C-x 
<up>` and *Completions* is good enough,
that's fine by me.

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

Re: Add completion to compilation-read-command

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: philipk@posteo.net,  emacs-devel@gnu.org
> Date: Tue, 24 Dec 2024 19:03:50 +0200
> 
> > 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.

Why the heck is this useful command completely undocumented??

RE: [External] : Re: Add completion to compilation-read-command

[Drew Adams]

> >> 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.
> 
> There were many proposals how to implement `eager-update' to update
> *Completions* as you type.  We just need to put together all parts.

Taking me back...

Icicles has had all of that since 2006.

https://www.emacswiki.org/emacs/Icicles_-_History_Enhancements

https://www.emacswiki.org/emacs/Icicles_-_Nutshell_View#ProgressiveCompletion

https://www.emacswiki.org/emacs/Icicles_-_Nutshell_View#ChippingAway

https://www.emacswiki.org/emacs/Icicles_-_Icompletion#IncrementalCompletion

https://www.emacswiki.org/emacs/Icicles_-_Progressive_Completion

Re: Add completion to compilation-read-command

[Philip Kaludercic]

Spyros Roum <spyros.roum@posteo.net> writes:

> Juri Linkov wrote:
>>>> 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.
>> There were many proposals how to implement `eager-update' to update
>> *Completions* as you type.  We just need to put together all parts.
>
> I'm probably out of my depth here, as I'm not very familiar with
> *Completions*.
> Is there a good reason to stick to it when `completing-read` works
> well and as far as I can tell
> does a very similar/the same job?

*Completions* is just the buffer that pops up by default when
completing-read cannot expand the input unambiguously anymore?

> I have a patch almost ready based on Philip's feedback that I will be
> sharing today or tomorrow.
> If, however, the consensus is that it's not a good fit and that `C-x
> <up>` and *Completions* is good enough,
> that's fine by me.

I don't see a harm in having an additional user option.  Why, it might
even be a popular thing to allow all shell commands prompts to fall back
onto completing-read, considering how evil users apparently cannot make
use of C-r?

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Juri Linkov <juri@linkov.net>
>> Cc: philipk@posteo.net,  emacs-devel@gnu.org
>> Date: Tue, 24 Dec 2024 19:03:50 +0200
>> 
>> > 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.
>
> Why the heck is this useful command completely undocumented??

I second this confusion, and want to mention that the binding is not
that convenient + might be shadowed for windmove users.

Re: Add completion to compilation-read-command

[Philip Kaludercic]

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.

> 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.