cli: aliases: support multi-word alias names

[avamsi]

#6611

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added/updated tests to cover my changes
• I fully understand the code that I am submitting (what it does,
  how it works, how it's organized), including any code drafted by an LLM.
• For any prose generated by an LLM, I have proof-read and copy-edited with
  an eye towards deleting anything that is irrelevant, clarifying anything
  that is confusing, and adding details that are relevant. This includes,
  for example, commit descriptions, PR descriptions, and code comments.

[josephlou5]

Thanks for working on this! I'm pretty excited for this feature :)

[josephlou5]

Is this hard to handle? For example I personally would like a jj git sync alias that implements #/1039 until it's merged upstream, but does that mean that I'll always get a jj git: unrecognized subcommand 'sync' error?

Given that your test examples have shown that foo bar is chosen over foo, I think it makes intuitive sense that log mine should resolve an alias if present, and then fall back to log (with args) if not. But also, your example was when foo bar and foo are both defined as aliases, and maybe it's harder to check all the built-in commands?

Anyway, if this is possible, that'd be cool :) And if it's not, then I guess nothing needs to change here.

[yuja]

Perhaps we'll need to set allow_external_subcommands(true) recursively to all subcommands. See hide_short_subcommand_aliases() for a recursion example.

Then, we can probably substitute arguments normally based on prefix matching. For example, ws rm would be substituted to workspace rm by "ws" = ["workspace"], and then by "workspace rm" = [...]. Aliases like "ws rm" = [...] will never match. A warning can be added if needed.

[avamsi]

I intentionally wanted to avoid overlap with the builtin commands, at least for the initial version -- I think this has some overlap with #1509, on letting users redefine the behaviour of builtin commands.

Basically, should users be able to define aliases like jj log mine? I'm inclined to say no. That doesn't mean we couldn't still let people define jj git sync, of course (as git is a pure "container" command).

What do you guys think?

[yuja]

should users be able to define aliases like jj log mine? I'm inclined to say no. That doesn't mean we couldn't still let people define jj git sync, of course (as git is a pure "container" command).

No and yes. The latter will allow us to move 1-char jj bookmark subcommands to predefined aliases.

[aliases]
b = ["bookmark"]
"bookmark a" = ["bookmark", "advance"]

EDIT: Oh, it's unclear whether jj b --quiet a should be expanded.

[josephlou5]

That doesn't mean we couldn't still let people define jj git sync, of course (as git is a pure "container" command).

That makes sense to me. A follow-up question I have then is: Is it necessarily the case that if jj git has subcommands, then jj git will never have its own behavior? If clap enforces this, then allowing aliases of sub-sub-commands sounds good (e.g., jj git sync as an alias), but if not then we're left with the same problem as jj log my-alias.

I also really like being able to move the single-character built-in aliases to the default config (or being able to define your own).

[josephlou5]

How does this feature interact with completions? I described some ideas in #9047 (closed as a duplicate of the issue that you linked). Might help to also add some tests so that the behavior is clear.

[josephlou5]

Can you also add a test with .run_jj(["ws ls"]) to ensure that the quoted versions still work for backward compatibility? I think they should but just want to make sure. (It's probably not a huge deal since I wouldn't imagine many people are depending on quoted alias names, but good to be thorough.)