Support custom ordering in command name completion

[notramo]

Completion function is configurable for arguments, but not for executable/function names.
Elvish should have a command completion command, similar to the ones given in edit:arg-completer. I think edit:command-completer would be a good name for it.

[zzamboni]

@notramo What would be a possible use for this? (I'm genuinely curious) One possibility I can think of is to have directory-specific completions, e.g. for project-specific scripts. Do you have others?

[xiaq]

This sounds logical but it's not going to be very useful. Elvish has fixed rules for resolving commands and there is no customization point in changing that; this is a delibrate design choice. Since you cannot customize the rules for finding commands, customizing how to complete commands doesn't make much sense.

Do you have a particular use case in mind?

[notramo]

I want to make a tool that completes command by recency, frequency, and $pwd.
I am coding a lot with Crystal, and I would like to see the compiler as the first suggestion. (When I type c, the suggestions fills my terminal, when I type cr, still there are lots of suggestion, but even with cry there are some)
$pwd based command name completion can also be handy if someone codes in e.g. Crystal and Rust. When $pwd is a Rust project dir, typing c<Tab> would put cargo in the first place, but when $pwd is a Crystal project dir, c<Tab> would give crystal in the first place.

My idea to solve the command resolution problem:
There should be a builtin Elvish command that lists all resolved commands (functions, external executables, variables, etc.).
Then the user could write a function that converts it e.g. JSON, or build a command line with the candidates. In these examples, the edit:list-commands function lists all the possible commands.

fn my-custom-command-completer [command]{ edit:list-commands | to-json | completer-executable $command }

or

fn my-custom-command-completer [command]{ completer-executable --current $command --all ( edit:list-commands | each [i]{ print $i' ' ) }

[xiaq]

That is a very good use case, I like it.

Although instead of allowing the user to customize the entire completion for commands, I prefer to support this customization by adding an additional sorting phase and supporting customization for that. Elvish's completion is already divided into a candidate-generation phase and a matching phase, both of which can be customized separately. The motivation is orthogonality and flexibility for customization; adding a sorting phase (and relevant customization API) is coherent with the design.