Suggestion: Use whatis summary for completion desc

[alicealysia]

presently Flyline uses the same description behaviour as ble.sh when listing completions, which leads to most commands simply showing where they are located rather than how they work or what they do. However, it's possible to get a brief description of what the command is by replacing the logic that fetches the path to the file in ble/complete/action:command/get-desc with whatis $CAND 2>/dev/null

[akinomyoga]

What is non-trivial is that there is no way to tell that the entry found by whatis is actually about the command name. whatis shows the result for any man entries. Even when we try to use the section number [such as (1) of bash(1)] to filter the command name, the entries in e.g. section 1 aren't necessarily a command name. For example, whatis zshparam shows the result even though there isn't a command named zshparam.

[akinomyoga]

I thought about it again, and I now think if the command exists, and if the man entry of the same name exists, it is reasonable to assume that the man entry describes the command. There is still a possibility that they are unrelated, but such a setup would anyway confuse the user even if it is not suggested in the completion. I implemented the (opt-in) feature in ble.sh in commit akinomyoga/ble.sh@40f50e3, which can be enabled by

# blerc

bleopt complete_source_command_opts+=apropos

I can recommend this for implementing in HalFrgrd/flyline. Here are some points to be considered in implementation: In ble.sh's implementation, only the man entries of categories 1 and 8 are used (lib/core-complete.sh:6159 - akinomyoga/ble.sh @40f50e3). When the entry is found but the subject is not found, man seems to output a locale-specific variant of (unknown subject), so they should be excluded. The locale-specific string can be extracted by gettext with TEXTDOMAIN=man-db (lib/core-complete.sh:6070 - akinomyoga/ble.sh @40f50e3).

[HalFrgrd]

Thanks for the tip! I will look into this when I have some capacity