-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bash-completion as part of GNU Emacs #45
Comments
Hi! Thank you for letting me know. I'm ok with transferring copyright assignment and dealing with the paperwork, if there's enough interest. 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. |
Hi, I don't know what the status of this is but what about ELPA or NonGNU ELPA? |
Nothing has happened so far. I haven't had much time to spend on emacs-bash-completion. Adding Emacs to ELPA or NonGNU ELPA are reasonable alternatives. |
Can I suggest then to contact @monnier to see how this can be done? :) |
(Apologies in advance for the ramblings @szermatt; I felt compelled to blurt all that out for some reason. It's certainly not a call to action, there's no emergency here as far as I am concerned; please don't bother with this unless you feel like you can spare the time) Hi folks, FWIW, in the long run, I really think it would make sense for Emacs to use Bash's native completion system, out-of-the-box. To rehash the thoughts I laid down in bug#26661 last year, and to add a couple more things I've ruminated since then:
(Granted, those are all solvable bugs; it's just more code that has to be piled into
Again, apologies for the ramblings. Even though I think it would make eminent sense for Emacs to use native Bash completions by default, it's fine if the package ends on (Non)GNU ELPA; that doesn't preclude an "out-of-the-box" inclusion later on AFAIK. Do let us know if there is anything we can do to help, though! |
Again, apologies for the ramblings. Even though I think it would make
eminent sense for Emacs to use native Bash completions by default, it's fine
if the package ends on (Non)GNU ELPA; that doesn't preclude an
"out-of-the-box" inclusion later on AFAIK.
I for one would welcome support in shell.el (or in a GNU ELPA package)
to delegate completion to bash (or to query bash for the completion
candidates, and then do the completion itself in Emacs).
|
Just to be sure it's clear: I'm not opposed to making this package part of Emacs. I just haven't gotten around to it. At this point, I don't have much time to change or maintain this package, but the situation should improve next year.
Completion in Bash is understandably tightly connected with readline, which handles the communication with the user. The To improve the situation, as you mentioned, would mean work on the bash side to make external (non-readline) completion a supported feature, fix any corner-cases, document it and make it an officially supported interface. I haven't contacted anyone from the bash project about that, but would expect it to be doable. It's just a matter of someone putting the required time and effort into this.
I have to say that it's hard for me to tell whether this means that the package is working and useful or whether people just give up on it without bothering with filing bugs.
Yes, exactly. Even just tracking the current directory is a problem much more difficult than it should really be, because the only channel of communication there is between the shell and Emacs is a terminal that's meant for human being to interact with, not machines. Again, this is solvable - and many solutions have been provided already - but it remains disappointingly fragile.
I agree that this is the strength of this elisp package. This is why I wrote |
(Crystal clear as far as I'm concerned. I hope my message didn't come across as pushy; I just wanted to write all those arguments down for the record. I'm confident the inexorable March Of Progress™ will resume in due course; there's no urgency as far as I'm concerned)
(Related: I've just remembered that Emacs 28 will add (opt-in) support the OSC 7 escape sequence, so that particular problem will be sort-of solved… as long as one configures their shell(s) to emit the sequence (cf. VTE's implementation), as suggested in the docstring of |
For the record, I agree with that this would be a welcome feature, in GNU ELPA or maybe even Emacs itself. Thanks to everyone who is working on it. |
ping? |
Stefan Monnier has just added bash-completion NonGNU ELPA 😄 ! On my side, there's been no progress on the full integration into GNU Emacs. |
On my side, there's been no progress on the full integration into GNU Emacs.
On an unrelated note, I wonder if it can be generalized to other shells
and/or other programs offering completion via readline.
|
I wish! The approach currently taken in bash-completion integrates at the bash level. It needs to know how Bash works and split lines into commands and arguments in exactly the right way. An approach that would integrate at the readline level would be much more efficient and robust - and it would generalize to other readline-based tools. That would be exactly the right thing to do! I don't know whether readline is capable of doing that, but it would be a nice extension to readline which other terminal emulators (others than Emacs) could make good use of. |
There was a mention of making emacs-bash-completion a part of GNU Emacs: https://debbugs.gnu.org/26661#24
@szermatt what do you think about it?
AFAIK this will also involve getting the copyright assignment papers signed by contributors who have contributed significant amount of changes to this repository.
The text was updated successfully, but these errors were encountered: