Add bash completion

[scop]

Closes #1010

This implementation is self contained and does not require https://github.com/scop/bash-completion. If a dependency on it would be ok, adding it would make it possible to clean this up some, and would gain easy support for completing long options separated by = (which this one doesn't currently, and I'd rather not duplicate the code for that). Let me know if that would be desirable and I can adjust this.

[sharkdp]

Thank you very much for your contribution!

I am not familiar with shell completion scripts myself. Maybe @eth-p?

(sorry for the accidental close)

[eth-p]

@sharkdp I'm not too familiar with Bash completions, but I'll give it a look. I'll need to give it a proper review later, but this seems good from a quick glance.

This implementation is self contained and does not require https://github.com/scop/bash-completion. If a dependency on it would be ok, adding it would make it possible to clean this up some, and would gain easy support for completing long options separated by = (which this one doesn't currently, and I'd rather not duplicate the code for that). Let me know if that would be desirable and I can adjust this.

I would actually say this is one of those cases where it's fine to add an external dependency. From my understanding, a ton of other programs use bash-completion for their completions as well, and there's probably a good chance it will be installed already.

In the cases where it isn't (e.g. Mac), it shouldn't be too hard for package managers to simply add a dependency.

@Shark, thoughts?

[scop]

FWIW I do support adding the dependency, but I may also be quite heavily biased. In any case, the changes that I'd make if the dependency would be desirable are quite small and easy to review, so if the decision is not immediately clear, starting to review this in its current shape wouldn't be throwaway work if the dep+changes were introuced later.

[sharkdp]

Adding that dependency sounds good to me if it helps with the implementation.

[scop]

Ok, implementation adjusted to depend on it.

[sharkdp]

Thank you very much. This looks good to me.

I think this would be worth an entry in the CHANGELOG.md file. It would be great if you could add one (https://github.com/sharkdp/bat/blob/master/CONTRIBUTING.md#add-an-entry-to-the-changelog), otherwise I can also do it myself.

[scop]

Sure, added to the Other section.

[ds2606]

Just commented in #1010 that completions seem to re-surface the original issues for me (generic fliename completions are failing in zsh for bat) so I'll need to manually remove the completion scripts for the time being. The other completions are nice, but my primary use case for bat is just the default command with a completion filename (often in some deeply nested directory), so filename completion functionality is the most important for me. Could we perhaps add a command to disable completion files?

[scop]

For completeness, noting here too: as refined and discussed in #1010, this particular completion does not cause the above mentioned breakage to occur in bash.

[sharkdp]

Thank you!

[eggbean]

Not a big problem, but curious to know why I cannot get this to work.

I added bat.bash.in to etc/bash_completion.d/ (actually a stow symlink, as that is how I install bat) and sourced ~/.profile but I get no indication anything has changed. This way works for several other programs I install using stow, so I suspect the unusual .in suffix has something to do with it?

Also, the file does not seem to be included in the latest .deb packages.

[sharkdp]

I added bat.bash.in to etc/bash_completion.d/

Ah, that won't work. bat.bash.in is just a template for a bash completion file (hence the .in suffix). The actual bat.bash completion file will be generated when you build the project with cargo. Alternatively, download one of the tarballs / Debian packages from the release page. They also contain the generated files.

[sharkdp]

Oh - they're actually not part of the Debian packages (but the tarballs). That should be fixed in .github/workflows/CICD.yml => #1733.

[michaelblyons]

Is this also missing from Homebrew?