On Mon, 13 Apr 2026 at 12:33:42 +0200, Oswald Buddenhagen via isync-devel wrote:
> i had that thought as well, but i'm actually thinking yet more radically
> minimalistic:
>
> ...
> #define COLOR_WARNING "\x1b[33m"
> #define COLOR_ERROR "\x1b[31m"
> #define RESET_COLOR "\x1b[0m"
The main disadvantage to this approach is if you want to check or change
these values (e.g. change warnings from yellow to bright yellow), you'd
have to look up the SGR escape codes, find the desired values, add them,
and test to ensure they were correct. As opposed to just changing a
flag on a function.
Of course, I assume it's unlikely the colour scheme would change much in
the future, so this isn't by itself an argument against this approach;
it's just something I think important to note.
Btw, if using this approach, you can shorten consecutive escape
sequences by separating the parameter values with semicolons. For
example, to specify "bold and red", rather than using "\x1b[1m\x1b[31m",
you can use "\x1b[1;31m".
> > xprintf( "%?hello!%?\n", SGR_BOLD, SGR_NO_BOLD );
> >
> yes, something like that, with automatic handling of disabled coloring.
If we're going to be auto-disabling display attributes with (presumably)
the "\x1b[0m" escape sequence, then that does limit the use of nested
coloured messages. One of the reasons for my per-attribute disabling
was to allow some amount of these nestings. Where, for example, msg1 is
bold and msg2 is red, and msg2 contains msg1. By working per-attribute,
the end of msg1 would not remove the red colouring of msg2.
Btw, you can actually shorten the escape sequence "\x1b[0m" to just
"\x1b[m". If you don't give a parameter, it just assumes zero.
> however, another feature would actually make a lot of sense, to enable
> elegant (and slightly more efficient) wrapping of messages: recursive format
> strings. think
[...]
> i have wanted this so many times already that i wonder why the standard
> doesn't have it in some form.
If I had to guess, probably because it sounds like a security nightmare
for implementors and users. To be clear, I'm not at all a security
expert or anything. But it feels like something that could open a
plethora of possible attacks that would need to be accounted for.
Things like injecting %s and %n sequences, and misusing or miscounting
the nested variadic arguments come to mind, for instance.
I think recursive format strings should definitely be something we
should stay away from for this reason. At least not until there's some
_strong_ confirmation that they are indeed safe to use. I personally
would not be too comfortable using them without such confirmation.
> > Sure, I was just trying to avoid the situation where errors or warnings
> > may occur before and after parsing the --color option, which would cause
> > the former output to not be coloured, while the latter output would be
> > (or vice versa).
> >
> the whole point of the coloring is to make it easier to spot significant
> information in large amounts of output. so let's consider the cases:
> if there is an error, the run ends right at startup. there isn't any other
> output.
That's a good point; I hadn't considered that. So the only
inconsistency would be between separate program executions with
different command-line options, which doesn't nearly matter as much (if
at all, arguably).
> config parsing starts only now. that might become a minor problem if
> somebody really needs a persistent version of the option, but for the time
> being i have no intention of adding that.
For persistent coloured output, if the default auto-detection doesn't
detect support for the tty, you can just define a shell alias:
alias mbsync="mbsync --color"
That's what I do for grep, ls, etc.
> looking at patches can be a useful way to familiarize oneself with a
> project, because they offer a narrow, directed entry point.
Nice idea. I'll have a look at the patches associated with relevant
code (identified via git-blame or git-log). There's also the mailing
list archives I can check out.
Though for specific queries about the code, is this list appropriate for
asking? Things like "what's the purpose of this variable?" or "why use
this rather than that?". Asked after RTFM, of course.
Also, it's probably becoming apparent that I'm generally not able to
reply quickly due to the difference in time zones. Hopefully that isn't
too much of a problem :)
Take care,
Seth McDonald.
--
E9D1 26A5 F0D4 9DF7 792B C2E2 B4BF 4530 D39B 2D51
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
