You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, template aliases (builtin_op_log_compact) and template alias functions ('format_short_id(id)' = 'id.shortest(8)') are defined without any type information available.
If you could (optionally) describe what type they expect, that would enable a few potential use cases:
jj log -T <tab> could only suggest template aliases that accept a commit
if there was an LSP for the template it would benefit from having this information available
How could this look like?
Functions could simply be extended with the obvious syntax for declaring types:
nit: Aliases are kinda syntactic macro, so f() and f are different. Suppose : Type would be processed as a comment during alias substitution, it's weird that the implicit self type is annotated as a function argument.
the idea came up in #5541 (review)
Currently, template aliases (
builtin_op_log_compact
) and template alias functions ('format_short_id(id)' = 'id.shortest(8)'
) are defined without any type information available.If you could (optionally) describe what type they expect, that would enable a few potential use cases:
jj log -T <tab>
could only suggest template aliases that accept a commitHow could this look like?
Functions could simply be extended with the obvious syntax for declaring types:
Pure symbols like
builtin_log_compact
that still take aself
parameter (with implicit property access) could maybe look like this:If you wanted to add a docstring, maybe you could just have a comment in the first line (given #5317 is implemented)
That's basically how python does it: https://realpython.com/documenting-python-code/#basics-of-commenting-code
The text was updated successfully, but these errors were encountered: