cli: complete: complete -T template aliases

[jakobhellermann]

based on #5539

It would be nice to filter them down to only applicable ones, but I don't think that type information is present in the toml definitions.

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 tests to cover my changes

[jakobhellermann]

We could also emit a description for the template, but it would only have room for one line, and I don't think that provides much value.

I suppose another option would be only to display the help text for one-line templates, which is better, but probably not worth the visual clutter over the simple horizontal list of all templates.

[ilyagr]

I'm not sure how major this is, but these suggestions include things like jj log -T builtin_op_log_compact that result in an error.

A hacky and impefect solution might be to filter the log templates by the regex ^builtin_log.

I wonder if we could/should reorganize templates by the kind of object they take, so that this would be op_log.builtin_compact. This might be a bit of a project, it would also raise the questions of what to do about template aliases, and whether that should be referred to as jj op log -T op_log.builtin_compact or whether jj op log should assume the op_log. prefix.

[jakobhellermann]

A hacky and imperfect solution might be to filter the log templates by the regex ^builtin_log.

Could do that, although you would lose user defined template aliases with another prefix (how common is that?) and you'd still get invalid builtin_log_node*.

I wonder if we could/should reorganize templates by the kind of object they take, so that this would be op_log.builtin_compact

Hm. My gut reaction says that I would prefer to have flat template-aliases, that makes it easier to think about them. It's just a set of defined variables/functions.
It's non-obvious that you should use [template-aliases.op_log] my_custom_log = '...' so users might just not do that and miss out on completion.

Another option would be to introduce some understanding of types to the functions and symbol, but that would be an even larger undertaking and it's not clear that it is worth the complexity

Sketch of adding type information to templates

'commit_timestamp(commit)' = 'commit.committer().timestamp()'

could be written as

'commit_timestamp(commit: Commit)' = 'commit.committer().timestamp()'

and

builtin_log_compact = '''
if(root,
  format_root_commit(self),
  ...
)
'''

might become

'builtin_log_compact(self: Commit)' = '''
if(root,
  format_root_commit(self),
  foo # implicitly self.foo
  ...
)
'''

And then, only aliases that have a type specified and match the expected type are completed.
This would potentially useful for other features (autocomplete in the config file via LSP injection?, better error messages due to earlier type checking, ??).

[yuja]

It might make sense to add some metadata (e.g. self type, short documentation, etc.) to the builtin templates, but I don't have any concrete idea right now.

[jakobhellermann]

I've opened a followup issues for potential type metadata in the aliases: #5551