On Mon, Apr 13, 2026 at 04:54:41PM +1000, Seth McDonald wrote:
It is true that sgr_attr_t isn't actually needed; the
ds_to_sgr function pointer could just return the escape sequence string
directly (e.g. returning "\x1b[31m" rather than 31).
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"
that's the big advantage of limiting ourselves to basic SGR sequences.
no abstractions needed.
xprintf( "%?hello!%?\n", SGR_BOLD, SGR_NO_BOLD );
yes, something like that, with automatic handling of disabled coloring.
but this is probably over-engineered; it doesn't really add much value
as-is.
however, another feature would actually make a lot of sense, to enable
elegant (and slightly more efficient) wrapping of messages: recursive
format strings. think
void err(const char *fmt, ...)
{
va_list va;
char date[32];
va_start( va, fmt );
fmt_date(date);
xprintf( "%s " COLOR_ERROR "error: %&" RESET_COLOR "\n", date, fmt, va
);
va_end( va );
}
i have wanted this so many times already that i wonder why the standard
doesn't have it in some form.
Though on the other hand, this would increase usage of a custom printf()
implementation over the standard library's. Which, since the library's
is likely much more optimised, may incur a slight performance hit.
the only thing one can do really badly in that context is to pass every
char separately to the output layer. or do lots of dynamic allocations.
we don't do either.
but realistically, performance differences in the printf implementation
are entirely negligible in this application.
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.
warnings are printed only after the parsing completed, at which point
coloring can be already enabled.
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.
i recommend that you take a look at all wip/ branches, [...]
I typically just look the master/main branch as it can sometimes be
difficult to determine which branches are still in development and which
are done or abandoned (in general, not this repo specifically). But I
can take a look at those wip branches if they're still open for
development.
everything in the repo should be still relevant somehow.
most branches are "indefinitely deferred" for one reason or another.
the commit message of the initial (and usually only) commit should
explain why, though this isn't always the case.
if you see anything that appears truly abandoned (or obsolete), let me
know.
Though I am still trying to wrap my head around much of the code in the
master branch, so it may be a bit before I rigorously examine some other
branches.
looking at patches can be a useful way to familiarize oneself with a
project, because they offer a narrow, directed entry point. it's
basically a bottom-up approach. of course, this isn't useful if the
topics handled there have little/no overlap with what actually interests
you.
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
