Hi Oswald,
On Sun, 12 Apr 2026 at 14:16:04 +0200, Oswald Buddenhagen via isync-devel wrote:
> On Sun, Apr 12, 2026 at 04:14:21PM +1000, Seth McDonald wrote:
> > This patchset aims to tick off the following from the TODO file.
> >
> > | possibly use ^[[1m to highlight error messages.
> >
> cool.
>
> my first reaction is "huh, this is completely over-engineered".
Yeah I can see that lol. My goal was to add an API (well, one function)
that's simple to use (hence the bitfield) and requires minimal change to
the existing codebase to use (hence the message "wrapping").
> i'd just go
> with a hard-coded SGR sequence #define for each message class and a common
> reset sequence rather than an elaborate attribute translation layer.
You're referring to the transition between display_attr_enum and
sgr_attr_t? 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 think I
initially included sgr_attr_t to make it easier to represent escape
sequences (it's easier to store integers than strings). But in
hindsight that benefit doesn't really manifest given I immediately
convert any sgr_attr_t values to their corresponding string
representation. So I think I agree that directly converting from
display_attr_enum values to escape strings (with #defines) is better.
> the wrapping of the "base calls" is a good (and somewhat obvious) idea. but
> for the implementation, we may end up with something rather different:
> - we may be able to inject the sequences more directly by virtue of having
> our own printf() implementation. that's just an idea, not an instruction.
xprintf()? I haven't yet looked too much into that, but it seems to be
similar to printf() but with extra format sequences and a trailing
callback. If this were the way to go, I would imagine a specific format
sequence to insert an escape sequence could work. Something like:
xprintf( "%?hello!%?\n", SGR_BOLD, SGR_NO_BOLD );
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.
That's just a guess though; I haven't done any benchmarking.
> there is no need for the init_colors() hack. coloring the command line
> parser output adds no value, so it's fine to just postpone coloring
> activation.
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). But if that's not a concern then the logic can
certainly be simplified.
> please use american english throughout. it's not that i like it, but that's
> what the "C" locale really is, and consistency is king.
Of course, forgot to include the US-defaultism ;)
> as you're certainly noticing at this point, i'm very particular about how
> things should be implemented. to avoid wasting time and mental energy, it's
> best to discuss designs in advance. i think the "show me the code" approach
> many projects go with is extremely disrespectful towards contributors for
> anything but the most trivial patches.
Good to know; I'm glad communication is welcomed :). And I'll be happy
to propose any ideas prior to fully implementing them (other than simple
typos/fixes, of course).
> i recommend that you take a look at all wip/ branches, to avoid redundancy
> and divergent developments (beyond what happened since the branches
> sprouted, anyway - some a rather old). these aren't a priority by any means,
> but it may make sense to drive some of them to completion before doing other
> stuff, not last because many of them are (based on) external contributions,
> so obviously somebody cared enough to give it a shot.
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.
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.
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
