moin!
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". 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.
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.
- there is the wip/better-stderr branch, which puts the output
completely upside down. it would be probably a good idea to finalize
that branch (which may mean completely changing the approach) before
making the output more fancy. or at least plan out how adding things
now would affect the later refactoring.
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.
for the color scheme, i'd use journalctl's "ladder": dark grey ("bold
black" in SGR terms) for debug, (bold) white for info, (bold) yellow for
warning, and (bold) red for error.
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. it's ok
to silently accept --colour to not break people's finger memory, but
documenting it just adds noise that adds cognitive load.
(yes, i realize the irony of using "grey" instead of "gray" above. ;-P)
---
a few notes on process:
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.
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.
conversely, i need to be more pro-active in pushing out what is cooking.
i pushed wip/master-next for that purpose (expect it to be force-pushed
at any time). you'll find something that looks familiar in there ...
so far ... ^^
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
