bug#26661: compile, shell etc. should use bash-completion !

bug#26661: compile, shell etc. should use bash-completion !

[積丹尼 Dan Jacobson]

M-x compile prompt,
Compile command: cat --<TAB>

M-x shell,
$ cat --<TAB>

etc. etc.
should all use bash-completion !

If the user has it turned on in his shell, emacs should recognize it.
https://www.google.com/search?q=bash-completion+emacs

bug#26661: compile, shell etc. should use bash-completion !

[Stefan Kangas]

tags 26661 + notabug wontfix
close 26661
thanks

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> M-x compile prompt,
> Compile command: cat --<TAB>
>
> M-x shell,
> $ cat --<TAB>
>
> etc. etc.
> should all use bash-completion !
>
> If the user has it turned on in his shell, emacs should recognize it.
> https://www.google.com/search?q=bash-completion+emacs

Note that `shell' already supports pcomplete, which extends to
`compile' (and `shell-command', etc.) AFAICT.  Try typing:

    M-x compile RET make SPC TAB

and enjoy...

I'm also not exactly sure how integrating bash completion with Emacs
would work.  Bash completion consists of a number of highly
bash-specific scripts.  It would take significant effort to write an
Emacs parser for them.

It seems like a better idea for people to spend time on making pcomplete
extensions for more commands.  But that would be outside the scope of
this feature request, I think.

I'm therefore closing this bug report.

bug#26661: compile, shell etc. should use bash-completion !

[Kévin Le Gouguec]

Stefan Kangas <stefan@marxist.se> writes:

> I'm also not exactly sure how integrating bash completion with Emacs
> would work.  Bash completion consists of a number of highly
> bash-specific scripts.  It would take significant effort to write an
> Emacs parser for them.
>
> It seems like a better idea for people to spend time on making pcomplete
> extensions for more commands.  But that would be outside the scope of
> this feature request, I think.

Out of curiosity, couldn't shell-mode (and M-x compile et al.) do what
python-mode does, i.e. ask the interpreter's "completion API" for
candidates when the user hits TAB?

I think that's what the "bash-completion" package from MELPA does[1];
this approach would allow Emacs to leverage Bash's programmable
completion with no special support for specific commands.


(Apologies if I've misunderstood something, I've only very quickly
glanced at python.el and bash-completion's internals.)


[1] https://raw.githubusercontent.com/szermatt/emacs-bash-completion/master/bash-completion.el

See e.g. bash-completion--setup-bash-common which runs "complete -p".

bug#26661: compile, shell etc. should use bash-completion !

[Stefan Kangas]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Out of curiosity, couldn't shell-mode (and M-x compile et al.) do what
> python-mode does, i.e. ask the interpreter's "completion API" for
> candidates when the user hits TAB?
>
> I think that's what the "bash-completion" package from MELPA does[1];
> this approach would allow Emacs to leverage Bash's programmable
> completion with no special support for specific commands.
>
>
> (Apologies if I've misunderstood something, I've only very quickly
> glanced at python.el and bash-completion's internals.)
>
>
> [1] https://raw.githubusercontent.com/szermatt/emacs-bash-completion/master/bash-completion.el
>
> See e.g. bash-completion--setup-bash-common which runs "complete -p".

Interesting, I didn't know about that package.  I tested it, and it
seems to do the job.

I think it's interesting as an alternative, but is it suitable as a
default?  For example what happens if you don't have bash-completion
installed on your machine.  IIRC it is a separate package in Debian.

Also, I doubt that it could ever be as powerful as pcomplete.

My preference is that for this use-case we point users to use the
third-party package, but I guess YMMV.  Any other opinions?

bug#26661: compile, shell etc. should use bash-completion !

[Kévin Le Gouguec]

Stefan Kangas <stefan@marxist.se> writes:

> I think it's interesting as an alternative, but is it suitable as a
> default?  For example what happens if you don't have bash-completion
> installed on your machine.  IIRC it is a separate package in Debian.

IIUC Debian's bash-completion package merely provides configuration for
Bash's native completion facilities (`complete' is just a Bash builtin);
I expect that if it's not installed, the MELPA package will just end up
with an empty list of completion candidates.

> Also, I doubt that it could ever be as powerful as pcomplete.

It would probably have better program coverage though.  Lots of authors
of CLI tools now maintain their own completion configuration for
e.g. Bash and/or Zsh, so by supporting Bash's native completion
facilities we would leverage their efforts instead of re-developing
ad-hoc completion functions.

> My preference is that for this use-case we point users to use the
> third-party package, but I guess YMMV.  Any other opinions?

All I can say is that I enjoy python.el offering the interpreter's
native completions, and I wish shell-mode et al. could work the same
way.  Philosophically speaking, it would make sense IMO for one GNU
project (Emacs) to leverage the API offered by another GNU project
(Bash).


I'm not saying pcomplete doesn't deserve some love and we could not
implement smarter completions with it; I just think the benefit/cost
ratio of enabling native Bash completions by default seems high.

bug#26661: compile, shell etc. should use bash-completion !

[Stefan Kangas]

reopen 26661
tags 26661 - notabug wontfix
thanks

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Lots of authors of CLI tools now maintain their own completion
> configuration for e.g. Bash and/or Zsh, so by supporting Bash's native
> completion facilities we would leverage their efforts instead of
> re-developing ad-hoc completion functions.
[...]
> I just think the benefit/cost ratio of enabling native Bash
> completions by default seems high.

OK, those are indeed compelling arguments, so I'm re-opening the bug
report.

Maybe we could convince the authors of the bash-completion package to
assign their copyright to the FSF.

bug#26661: compile, shell etc. should use bash-completion !

[Bhavin Gandhi]

On Fri, 4 Sep 2020 at 18:59, Stefan Kangas <stefan@marxist.se> wrote:
>
> Maybe we could convince the authors of the bash-completion package to
> assign their copyright to the FSF.
>

I reached out to the author of bash-completion over GitHub, they are
willing to do that if there is enough interest. Adding them in CC.

https://github.com/szermatt/emacs-bash-completion/issues/45#issuecomment-706671531

-- 
Warm Regards,
Bhavin Gandhi (bhavin192) | https://geeksocket.in

bug#26661: compile, shell etc. should use bash-completion !

[Stefan Kangas]

Bhavin Gandhi <bhavin7392@gmail.com> writes:

> On Fri, 4 Sep 2020 at 18:59, Stefan Kangas <stefan@marxist.se> wrote:
>>
>> Maybe we could convince the authors of the bash-completion package to
>> assign their copyright to the FSF.
>
> I reached out to the author of bash-completion over GitHub, they are
> willing to do that if there is enough interest. Adding them in CC.
>
> https://github.com/szermatt/emacs-bash-completion/issues/45#issuecomment-706671531

I found the comment on that page interesting:

   I have to say that I personally find bash-completion a bit hackish
   and fragile (by nature) to be something that'd come as part of
   standard Emacs, but that's something for Emacs maintainers to decide.

So perhaps this should better be part of GNU ELPA for users that want
it as optional behavior.

bug#26661: compile, shell etc. should use bash-completion !

[Kévin Le Gouguec]

Stefan Kangas <stefan@marxist.se> writes:

>> https://github.com/szermatt/emacs-bash-completion/issues/45#issuecomment-706671531
>
> I found the comment on that page interesting:
>
>    I have to say that I personally find bash-completion a bit hackish
>    and fragile (by nature) to be something that'd come as part of
>    standard Emacs, but that's something for Emacs maintainers to decide.
>
> So perhaps this should better be part of GNU ELPA for users that want
> it as optional behavior.

I'd be interested in knowing what makes bash-completion inherently more
hackish and fragile than say, python.el's native completion?  AFAICT
both essentially use a dedicated buffer to send completion queries to an
inferior process.

I may not have been thorough enough when reading either library's code
though, so maybe I missed something.

bug#26661: compile, shell etc. should use bash-completion !

[Stefan Kangas]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>>> https://github.com/szermatt/emacs-bash-completion/issues/45#issuecomment-706671531
>>
>> I found the comment on that page interesting:
>>
>>    I have to say that I personally find bash-completion a bit hackish
>>    and fragile (by nature) to be something that'd come as part of
>>    standard Emacs, but that's something for Emacs maintainers to decide.
>>
>> So perhaps this should better be part of GNU ELPA for users that want
>> it as optional behavior.
>
> I'd be interested in knowing what makes bash-completion inherently more
> hackish and fragile than say, python.el's native completion?  AFAICT
> both essentially use a dedicated buffer to send completion queries to an
> inferior process.

The comparison should rather be to the existing pcomplete support, I
think.

I suppose it's hackish and fragile because it can break at any time due
to third-party changes outside of our control.  But you're likely to get
a better answer from the author of the emacs-bash-completion package,
who wrote that remark in the first place.