New word-wrap function will be implemented in two passes. The first pass
splits byte slice to lines, and the second pass inserts "\n" based on that
while interleaving push/pop_label() calls and text fragments. Since the second
pass combines multiple data sources, byte indices are more convenient than
slices there.
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().
I keep calling it `underline` by mistake, so that probably means that
it's a more natural name for it. We haven't made a release of it yet,
so I didn't mention it in the changelog.
I didn't update all variables to also use `underline`, because I felt
that `underlined` was usually more natural there, plus crossterm calls
it `Attribute::Underlined`.
This makes us sanitize ANSI escape bytes in the output if it goes to
the terminal, even when it's not colored (by us), such as when using
`--color=never`. That means that e.g. `jj cat
tests/test_commit_template.rs` will not be colored, but `jj cat
tests/test_commit_template.rs | cat` will be. Sanitizing output sent
to the terminal might help reduce some security threats based on
hiding content by using ANSI escapes.
We could add a config option for sanitizing the output, but I'm not
sure it'll be useful.
Since `ColorFormatter` itself outputs ANSI escape codes, we should not
let the caller also include ANSI escape codes. This commit makes
`ColorFormatter` replace them by a unicode "␛".
For graphlog output, we use a separate formatter for each commit. The
output from the formatter is written to a buffer in memory. Then we
write it to graphlog renderer. Since the buffer already has any color
codes, we should not pass it through the top-level formatter (the one
bound to stdout). It hasn't mattered much so far, but it will when we
start sanitizing output written to formatters. This commit adds a
method to the `Formatter` trait for getting access to the raw
underlying output. It also starts passing that output to the graphlog
renderer.
There are several reasons for this:
* We can more easily skip styling a trailing blank line, which other
internal code then can correctly detect as having a trailing
newline. This fixes the TODO in tests/test_commit_template.rs.
* Some tools (like `less -R`) add an extra newline if the final
character is not a newline (e.g. if there's a color reset after
it), which led to an annoying blank line after the diff summary in
e.g. `jj status`.
* Since each line is styled independently, you get all the necessary
escapes even when grepping through the output.
* Some terminals extend background color to the end of the terminal
(i.e. past the newline character), which is probably not what the
user wanted.
* Some tools (like `less -R`) get confused and lose coloring of lines
after a newline.
We often end up writing escape codes for one style and then
immediately after, we write escape codes for another style. That seems
harmless, but it's a little ugly. More importantly, it prepares for
not emitting any escapes for turning off attributes at the end of
formatted contents across multiple lines (see next commit).
So far, configured color rules only support specifying foreground
color, and a better-matching rule completely overrides a worse
match. I'm about to add support for specifying other style attributes,
and I want a rule setting a background color not to be overridden by a
rule setting a foreground color. For that to work, it's not enough to
just find the best match, so this commit rewrites the algorithm for
finding the desired style so it finds all matching rules instead. It
then starts with the worst match and applies the other matches on top
of it in order or priority. I've implemented that priority to be in
order of the depth of matching labels, starting with deeper (more
specific) labels. The new algorithm doesn't care about how many labels
match.
We want to be able combine styles by replacing only some of the
attributes (foreground color, underlining, etc.) in the config. We
could implement that having keeping the current style and then update
it based on what we find in the config for a label we just
added. However, it's simpler if we can parse a configured style
without knowing the current style and just return a `Style` with some
fields blank. This commit prepares for that by making the foreground
color field optional.
I'd like to add support for at least bold font, background color, and
underlining. This commit adds a `struct Style` to store that
information. For now, it just contains the foreground color.
Let's use `crossterm` to make `ColorFormatter` a little more readable,
and maybe also more portable.
This uses the `SetForegroundColor()` function, which uses the escapes
for 256-color support (code 38) instead of the 8-color escapes (codes
30-37) combined with bold/bright (code 1) we were using before. IIUC,
most terminals support the 16 base colors when using the 256-color
escape even if they don't support all the 256 colors. It seems like an
improvement to use actual color codes for the bright colors too,
instead of assuming that terminals render bold as bright (even though
most terminals do).
Before this commit, we relied on ANSI escape 1 - which is specified to
make the font bold - to make the color brighter. That's why we call
the colors "bright blue" etc. When we switch from using code 30-37 to
using 38 to let our color config just control the color (not using
escape1), we therefore lose the bold font on many terminals (at least
in iTerm2 and in the terminal application on my Debian work
computer). As a workaround, I made us still use escape 1 when the
bright colors are used. I'll make boldness a separately configurable
attribute soon. Then we'll be able to remove this hack.
With the switch to `crossterm`, we also reset just the foreground
color (code 39) instead of resetting all attributes (code 0). That
also seems like an improvement, probably making it easier for us to
later support different background colors, underlining, etc.
The implementations of `add_label()` and `remove_label()` had a lot of
duplicated code, and we would soon have more duplication if we didn't
extract it to shared function.
It's common to write a formatted error/warning message, but we can't use
writeln!() with the current ui.write_*() API, and sometimes we forget to
add "\n" to the message. With this wrapper, ui.write_error("message\n")
will be writeln!(ui.error(), "message"), and trivial formatter.with_label()
call can be replaced with write!(formatter.labeled(...), ...).
I don't see a good reason to let e.g. "added diff" to match added text
inside a diff when we already allow "diff added" for that. Allowing
both means that we have to decide which should take precedence. With
the recent change to add labels for methods, we no longer depend on it
for the "timestamp author" case ("author timestamp" now
matches). Thanks to @yuja for noticing that dependency.
UserSettings will be instantiated after both user and repo configs are
loaded. We might want to add a wrapper for CLI settings, but I have no idea
how that should be structured. Let's use bare config::Config until then.
Let's acknowledge everyone's contributions by replacing "Google LLC"
in the copyright header by "The Jujutsu Authors". If I understand
correctly, it won't have any legal effect, but maybe it still helps
reduce concerns from contributors (though I haven't heard any
concerns).
Google employees can read about Google's policy at
go/releasing/contributions#copyright.
There's a risk of forgetting to call `remove_label()` and I've wanted
to reduce that risk for a long time. I considered creating RAII
adapters that implement `Drop`, but I didn't like that that would
ignore errors (such as `BrokenPipe`) that can happen while emitting an
escape sequence in `remove_label()`. I would ideally have liked
Python's context managers here, but Rust doesn't have that. Instead,
we get to use closures. That works pretty well, except that we can't
return other errors than `io::Error` inside the closures. Even with
that limitation, we can use the new `with_label()` method in all but a
few cases.
We can't define the `with_label()` method directly in the trait
because `&mut self` is not a trait object, so we can't pass it on to
the closure (which expects a trait object). The solution is to use
`impl dyn Formatter` (thanks to @kupiakos for figuring that
out!). That unfortunately means that we can *only* call the function
on trait objects, so if `f` is a concrete formatter type
(e.g. `PlainTextFormatter`), then `f.with_label()` won't
compile. Since we only ever access the formatters as trait objects,
that's not really a problem, however.
Since the concrete Formatter type is hidden behind the Ui, there wouldn't
be many reasons to use dyn Write at the formatter layer. This allows us
to create a formatter against MutexGuard<Box<dyn Write>> without one more
Box<dyn Write> wrapper.
This should help to create a temporary ColorFormatter instantly.
A cached_colors table could also be shared across formatters, but doing that
would require some locking mechanism. Since commands like cmd_log/diff()
use a single formatter instance, I don't think shared mutable cache would be
needed for the moment.
It seems helpful to show in the log output which commit is checked out
in which workspace, so let's try that. I made it only show the
information if there are multiple checkouts for now.
I wanted to have all the documentation available on the command line,
but that makes it harder to maintain and link to. Let's move it to
markdown instead. We may later be able to add some way of presenting
the markdown in the terminal (or maybe by first converting it to
reStructuredText).
It's useful to know which commit is checked out in the underlying Git
repo (if there is one), so let's show that. This patch indicates that
commit with `HEAD@git` in the log output. It's probably not very
useful when the Git repo is "internal" (i.e. stored inside `.jj/`),
because then it's unlikely to change often. I therefore considered not
showing it when the Git repo is internal. However, it turned out that
`HEAD` points to a non-existent branch in the repo I use, so it won't
get imported anyway (by the function added in the previous patch). We
can always review this decision later.
This is part of #44.
