Filename completions appear for sed expressions

[EmilyGraceSeville7cf]

ble version: 0.4.0-devel4+f4c973b
Bash version: 5.1.16(1)-release (x86_64-pc-linux-gnu)

At least it should not happen, at most sed commands (at least their names) should be completed. 😄 But ideally, be able to autocomplete existing sed labels, character classes.

[akinomyoga]

The completion for each command is out of the scope of ble.sh. ble.sh is primarily a line editor (like Readline) and provides the basic infrastructure for the completion, but the detailed completions for a specific command are supposed to be defined by users or other frameworks such as bash-completion. ble.sh already provides the support for the programmable completion that readline offers, so currently there is no plan to provide completions for each specific command.

ble.sh supports the parsing of the man page and help because it can be done for the general commands.

I actually have an idea of providing a new user interface for the programmable completion. But a careful design is needed, and also many things need to be upgraded to implement that. After settling the new programmable-completion interface, I would probably start to accept completions for specific commands in blesh-contrib, but I don't have enough time to do that soon.

[akinomyoga]

I've checked bash-completion. The implementation in bash-completion seems to be just the general _comp_longopt, which parses the output of sed --help for long options. Maybe you could issue a feature request for the sed commands there, but providing completions for single-character commands might not be so convincing.

[EmilyGraceSeville7cf]

I actually have an idea of providing a new user interface for the programmable completion.

Some thoughts about design. There is bashly framework for creating CLI apps and generating completions for them. What about allow users to write completions in YAML files and generate bash code for them automatically? Maybe even in the same way as bashly allows do it. I am personally tired of these short unreadable options of complete and related builtins.

[akinomyoga]

I think the idea is similar. I'm actually thinking of a shell-based interface like https://github.com/ko1nksm/getoptions so that we can generate not only the completions, but also the settings for programmable highlighting for each command, and the settings for generating hints/errors/warnings for the current command line. You might have already noticed that ble-0.4 has been in a development state for a very long time, but this is actually the main theme of 0.4 as written as "programmable highlighting" in the roadmap of README. Anyway, I don't have enough time for this big project now.

I intend to make it programmable. It is natural to provide the programmable settings with a shell language rather than introducing another programming/non-programming language. Also, ble.sh is intentionally implemented by Bash plus the POSIX commands so that it works in any (minimum) environment, I don't think it is a good idea to implement a YAML parser from scratch using Bash + POSIX commands unless there is a strong reason. For these reasons, I won't employ the YAML format.

[EmilyGraceSeville7cf]

What about to copy completion API design from Fish shell? User write completions via neat API, but behind the scenes it invokes not user-friendly (IMO) Bash API.

[akinomyoga]

I wouldn't make an exact copy of the interface because ble.sh also wants to cover programmable highlighting, validation, and other features also raised in ko1nksm/getoptions with a single interface, but I'll definitely take it into consideration of the API design.

User write completions via neat API, but behind the scenes it invokes not user-friendly (IMO) Bash API.

That hears like what can be done independent of ble.sh.

---

I think it would be useful to prepare an adapter for the fish completions so that we can reuse the database

• fish-shell/share/completions at master · fish-shell/fish-shell · GitHub

The Zsh interface seems like a CSV/DSV-type text format.

• zsh-completions/_openssl at master · zsh-users/zsh-completions · GitHub

There are also some discussions about the completion design by the author of Oil shell.

• Shell Autocompletion · oilshell/oil Wiki
• Shellac Protocol Proposal V2 · oilshell/oil Wiki

There is also a database by rsteube/carapace. It seems to be totally written in the Go language so not reusable, yet we can extract use cases of some utility functions defined and used there.

• carapace-bin/completers at master · rsteube/carapace-bin · GitHub

[EmilyGraceSeville7cf]

@akinomyoga, should I close this issue as not planned?

[akinomyoga]

I would like to keep this open. I currently don't have a plan to implement it soon, but I'd like to consider it if I have time. This issue contains a summary of useful references that may be considered in designing the interface. Could I keep this open?

[EmilyGraceSeville7cf]

Of course you can keep it open. 😀

[akinomyoga]

Thanks