commit_templater: encode elided node as Option<Commit>

[yuja]

#3260

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

[martinvonz]

I'm not sure how I feel about this. I like the idea of having optional values in general, but I I'm not convinced the jj log template should have Option<Commit> as context object (I'm not convinced they shouldn't either).

[yuja]

but I I'm not convinced the jj log template should have Option<Commit> as context object (I'm not convinced they shouldn't either).

This is primarily designed for the graph node template. I thought it could apply to the text part, but I agree it wouldn't be that useful.

Regarding the context object, I hope we can eventually relax it to any types known to the template language. Perhaps, CommitTemplateLanguage will define all types dependent on the Repo, and renamed to RepoTemplateLanguage.

[yuja]

Regarding the context object, I hope we can eventually relax it to any types known to the template language.

Since self in templater is basically a property function that clones &Context, we can get rid of the Context type from the inner template during compilation, and inject self property as a placeholder property. It allows us to select arbitrary context type without exploding the number of the extension types.

impl TemplateLanguage for CommitTemplateLanguage {
    type Context = ();
}

let placehodler = ..; // Rc<RefCell<C>> stuff to insert arbitrary "self" variable
let make_self = || some_wrapping(placeholder);
ctx.local_variables.insert("self", &make_self);
let inner_template: Box<Template<()>> = build(language, &ctx, node)?;
let outer_template: Template<C> = Wrapper { inner_template, placeholder }

It's a bit messy, but seems doable.

FWIW, do you like the idea of using Context = Option<Commit> in graph node template?

[ilyagr]

I am mainly reacting to the title of the PR, so I could easily be missing the point, but I'd love for an elided node to eventually keep track of approximately how many commits were elided. Perhaps the type should be called something else, even if it's equivalent to Option<Commit> today.

[yuja]

for an elided node to eventually keep track of approximately how many commits were elided.

Yes. It suggests that the "(elided revisions)" text shouldn't be a part of the common commit template.

I still think Option<Commit> is good for a graph node template:

templates.log_node = 'if(self, if(current_working_copy, "@", "o"), "=")'

[yuja]

This is now ready for review.

• The log text template is unchanged, and its context is of Commit type.
• The log node template is changed to Option<Commit> type.

[martinvonz]

Makes sense. What do you think, @algmyr and @ilyagr?

[algmyr]

LGTM, eventually we would probably want to expose more things like ascii/non-ascii and at that point elided could maybe be a property. But until that point this simplifies things.

[yuja]

expose more things like ascii/non-ascii and at that point elided could maybe be a property.

For ascii/non-ascii, maybe we can add config_<type>(key) (or config(key).to_<type>()) accessor.