* bug#26661: compile, shell etc. should use bash-completion !
@ 2017-04-25 23:36 積丹尼 Dan Jacobson
2020-09-01 23:14 ` Stefan Kangas
0 siblings, 1 reply; 10+ messages in thread
From: 積丹尼 Dan Jacobson @ 2017-04-25 23:36 UTC (permalink / raw)
To: 26661
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#26661: compile, shell etc. should use bash-completion !
2017-04-25 23:36 bug#26661: compile, shell etc. should use bash-completion ! 積丹尼 Dan Jacobson
@ 2020-09-01 23:14 ` Stefan Kangas
2020-09-02 22:10 ` Kévin Le Gouguec
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Kangas @ 2020-09-01 23:14 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: 26661
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#26661: compile, shell etc. should use bash-completion !
2020-09-01 23:14 ` Stefan Kangas
@ 2020-09-02 22:10 ` Kévin Le Gouguec
2020-09-02 22:34 ` Stefan Kangas
0 siblings, 1 reply; 10+ messages in thread
From: Kévin Le Gouguec @ 2020-09-02 22:10 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 26661, 積丹尼 Dan Jacobson
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".
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#26661: compile, shell etc. should use bash-completion !
2020-09-02 22:10 ` Kévin Le Gouguec
@ 2020-09-02 22:34 ` Stefan Kangas
2020-09-04 11:05 ` Kévin Le Gouguec
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Kangas @ 2020-09-02 22:34 UTC (permalink / raw)
To: Kévin Le Gouguec; +Cc: 26661, 積丹尼 Dan Jacobson
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#26661: compile, shell etc. should use bash-completion !
2020-09-02 22:34 ` Stefan Kangas
@ 2020-09-04 11:05 ` Kévin Le Gouguec
2020-09-04 13:28 ` Stefan Kangas
0 siblings, 1 reply; 10+ messages in thread
From: Kévin Le Gouguec @ 2020-09-04 11:05 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 26661, 積丹尼 Dan Jacobson
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#26661: compile, shell etc. should use bash-completion !
2020-09-04 11:05 ` Kévin Le Gouguec
@ 2020-09-04 13:28 ` Stefan Kangas
2020-10-21 17:05 ` Bhavin Gandhi
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Kangas @ 2020-09-04 13:28 UTC (permalink / raw)
To: Kévin Le Gouguec; +Cc: 26661, 積丹尼 Dan Jacobson
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#26661: compile, shell etc. should use bash-completion !
2020-09-04 13:28 ` Stefan Kangas
@ 2020-10-21 17:05 ` Bhavin Gandhi
2020-10-29 1:16 ` Stefan Kangas
0 siblings, 1 reply; 10+ messages in thread
From: Bhavin Gandhi @ 2020-10-21 17:05 UTC (permalink / raw)
To: Stefan Kangas
Cc: 26661, szermatt, Kévin Le Gouguec,
積丹尼 Dan Jacobson
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#26661: compile, shell etc. should use bash-completion !
2020-10-21 17:05 ` Bhavin Gandhi
@ 2020-10-29 1:16 ` Stefan Kangas
2020-10-29 6:31 ` Kévin Le Gouguec
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Kangas @ 2020-10-29 1:16 UTC (permalink / raw)
To: Bhavin Gandhi
Cc: 26661, szermatt, Kévin Le Gouguec,
積丹尼 Dan Jacobson
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#26661: compile, shell etc. should use bash-completion !
2020-10-29 1:16 ` Stefan Kangas
@ 2020-10-29 6:31 ` Kévin Le Gouguec
2020-10-29 18:15 ` Stefan Kangas
0 siblings, 1 reply; 10+ messages in thread
From: Kévin Le Gouguec @ 2020-10-29 6:31 UTC (permalink / raw)
To: Stefan Kangas
Cc: 26661, szermatt, Bhavin Gandhi,
積丹尼 Dan Jacobson
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#26661: compile, shell etc. should use bash-completion !
2020-10-29 6:31 ` Kévin Le Gouguec
@ 2020-10-29 18:15 ` Stefan Kangas
0 siblings, 0 replies; 10+ messages in thread
From: Stefan Kangas @ 2020-10-29 18:15 UTC (permalink / raw)
To: Kévin Le Gouguec
Cc: 26661, szermatt, Bhavin Gandhi,
積丹尼 Dan Jacobson
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-10-29 18:15 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-04-25 23:36 bug#26661: compile, shell etc. should use bash-completion ! 積丹尼 Dan Jacobson
2020-09-01 23:14 ` Stefan Kangas
2020-09-02 22:10 ` Kévin Le Gouguec
2020-09-02 22:34 ` Stefan Kangas
2020-09-04 11:05 ` Kévin Le Gouguec
2020-09-04 13:28 ` Stefan Kangas
2020-10-21 17:05 ` Bhavin Gandhi
2020-10-29 1:16 ` Stefan Kangas
2020-10-29 6:31 ` Kévin Le Gouguec
2020-10-29 18:15 ` Stefan Kangas
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).