FR: have jj log wrap text based on terminal width
#1043
Labels
polish🪒🐃
Make existing features more convenient and more consistent
Comments
avamsi
added
the
polish🪒🐃
|
For reference, Mercurial does this (as you probably know). It has |
yuja
added a commit
that referenced
this issue
Mar 4, 2023
Template functions like indent() or fill() need to manipulate labeled output. Since indent() is line oriented, it could be implemented as a post-processing filter. OTOH, fill()/wrap() inserts additional "\n"s. If we do that as a post process, colorized text could be split into multiple lines, and would mess up graph log output. By using FormatRecorder, we can apply text formatting in between labels. I thought we could disallow text wrapping of labeled template fragments, but the example in #1043 suggests that we do want to wrap(whole_template_output) rather than simple description.wrap().
yuja
added a commit
that referenced
this issue
Mar 10, 2023
The parameter order follows indent()/label() functions, but this might be a bad idea because fill() is more likely to have optional parameters. We can instead add template.fill(width) method as well as .indent(prefix). If we take this approach, we'll probably need to add string.fill()/indent() methods, and/or implicit cast at method resolution. The good thing about the method syntax is that we can add string.refill(), etc. for free, without inventing generic labeled template functions. For #1043, I think it's better to add a config like ui.log-word-wrap = true. We could add term_width/graph_width keywords to the templater, but the implementation would be more complicated, and is difficult to use for the basic use case. Unlike Mercurial, our templater doesn't have a context map to override the graph_width stub.
|
Woot, thanks @yuja! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current behavior --
Desired behavior (note the graph is not "broken" in this example) --
I picked a straightforward example but this makes even more sense for deeply nested commits (and more relevant if/when log templates are documented and people go for more compact representations in a single line e.t.c.)
All that said, this may not be desired by everyone, so maybe this could be a default-false flag to
jj log.The text was updated successfully, but these errors were encountered: