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.