jj icon indicating copy to clipboard operation
jj copied to clipboard

FR: Make node symbols in graphs configurable

Open martinvonz opened this issue 11 months ago • 4 comments

Is your feature request related to a problem? Please describe.

It would be nice to be able to customize the symbols in the jj log, jj obslog, and jj op log. One reason is that different users have different fonts installed, or maybe they use a font size where some symbols look too similar.

Describe the solution you'd like

Maybe we can use templating to customize the graph symbols, so the user can choose a different graph symbol depending on anything related to the commit. Maybe they want a different symbol for hidden commits, for example.

Describe alternatives you've considered

Have a config value for each kind of symbol.

Additional context

Mentioned in https://github.com/martinvonz/jj/issues/3111#issuecomment-1957855885

martinvonz avatar Mar 08 '24 17:03 martinvonz

Support for this was added in #3263. I'm not sure if that means we should close and open a new bug about adding template support for the node (seems like something we want, right?)

martinvonz avatar Mar 09 '24 21:03 martinvonz

a new bug about adding template support for the node (seems like something we want, right?)

Templater support will help to colorize node symbols without adding too many options, yes. One problem we'll need to figure out is that the elided node has no template context (= &Commit).

yuja avatar Mar 09 '24 23:03 yuja

After continuing work on #3234 I was thinking that it actually would be nice if users could configure any node symbol for any revset (immutable_heads(), mine(), etc.). Perhaps, default and elided node symbols can stay as is?

zummenix avatar Mar 11 '24 15:03 zummenix

After continuing work on #3234 I was thinking that it actually would be nice if users could configure any node symbol for any revset (immutable_heads(), mine(), etc.).

Oh, that has come up before but I had forgotten. I agree!

Perhaps, default and elided node symbols can stay as is?

We talked on Discord a bit about templating the node symbol. I think it would be nice if one could e.g. if(elided, "◌", "◉"). One tricky aspect is that elided nodes are not commits. Maybe the simplest way to model it is to use the root commit as placeholder for them. It's a bit hacky but probably good enough.

To support revsets, I suppose we would add a new revset function. Maybe something like if(elided, "◌", if(in("::immutable_heads()"), "✦", "◉")).

Maybe we should even allow templating the working copy differently? It's currently hard-coded as "@". The reason for that is of course that "@" has special meaning in revsets. But maybe we can still let users override the graph node if they really want to, hopefully after they've learned what the "@" symbol means.

martinvonz avatar Mar 11 '24 16:03 martinvonz

Maybe for elided nodes there should be their own template that would allow to style the text label (elided revisions) too?

On somewhat unrelated note: I was thinking lately about having an ability to move the graph from the left to the middle of the screen. For example, for jj log I'd have date, author, change id to the left, then the graph in the middle and then – the rest (commit description, heads, etc.). Something like this:

2024-03-12 08:27 zummenix xoozvwzw  @     (empty) (no description set)
2024-03-12 08:25 zummenix oykkrsuq  ◈     graphlog: refactor out node symbols from GraphLog main* HEAD@git
2024-03-12 03:39 dploch   pqmnsqrk  │ ◉   commit_templater: add an AnyMap for extensions to cache their own info dploch/any-map@upstream
2024-03-12 03:39 dploch   tstrzosx  │ ◉   any_map: create a type-safe container for arbitrary objects
                                    ├─╯           
2024-03-12 01:22 aseipp   wwyoupor  │ ◉   cli: new `jj docs` command aseipp/push-kvwumrwrpywu@upstream
2024-03-12 01:22 aseipp   uvokrvxw  │ ◉   docs: initialize new `jj-docs` crate
                                    ├─╯          
2024-03-12 01:22 aseipp   mlnyyuyw  │ ◉   cli: basic `jj gerrit send` implementation aseipp/push-uytvkxyqyspn@upstream
2024-03-12 01:22 aseipp   oywvsknz  │ ◉   lib: add `footer` module for commit footers
                                    ├─╯         
2024-03-12 01:36 aseipp   mznmwxoq  │ ◉   cli: global `--show-heap-stats` argument for EOL heap stats aseipp/push-mupwvrwmxuvm@upstream
2024-03-12 01:36 aseipp   kltyvtwz  │ ◉   cli: use mimalloc from `jj-cbits` as the default memory allocator
2024-03-12 01:36 aseipp   zkzsnqvu  │ ◉   cbits: implement `MiMalloc` for use with `#[global_allocator]`
2024-03-12 01:36 aseipp   vtmklstv  │ ◉   cbits: import and build mimalloc v2.1.2
2024-03-12 01:22 aseipp   mkzvyskk  │ ◉   cbits: initialize new `jj-cbits` library

Is this something that could be of interest? Is it doable in the current architecture? I imagine, configurable node symbols could fit nicely there with the graph position set in a template alias. There is another FR of mine (#3183) about allowing padding and truncation of "fields" in templates which if implemented, would allow to properly prepare "columns" to the left of the graph.

zummenix avatar Mar 12 '24 16:03 zummenix

Maybe for elided nodes there should be their own template that would allow to style the text label (elided revisions) too?

Oh, that seems like a good idea! That avoids both the hacks for elided nodes and makes it possible to set the text, as you say.

Is this something that could be of interest?

Maybe :) I'm not convinced it's worth the added complexity (to the user and in the code).

Is it doable in the current architecture?

I suppose the easiest solution would be to have separate templates for "left of graph" and "right of graph". The user would need to specify the width of the left side (or we can have templates for it and just let it get rendered uglily if the user doesn't specify a fixed-width template). The graphlog code gets a multi-line description and renders the graph and the descriptions together. We could write that to a buffer and split it up on newlines and combine it with the left side.

martinvonz avatar Mar 12 '24 16:03 martinvonz

Maybe :) I'm not convinced it's worth the added complexity (to the user and in the code).

Yeah, I agree, it's hard to justify the added complexity.

zummenix avatar Mar 12 '24 16:03 zummenix

I believe the FR is completed

zummenix avatar Mar 24 '24 09:03 zummenix