Obeli⚡️mo: A String Marking Library

Showcase
1

I am pleased to announce the initial release of obelizmo, a library for marking and printing strings.

Strings may be marked by slice-style regions (two offsets), length plus offset, using stdlib-style finding functions (indexOf-esque), or via regex matches with mvzr, or in fact, anything which implements its interface.

Marked regions are assigned a mark from the enum passed in at type creation.

The most fully-realized output for marked strings is terminal printing, with an XtermLinePrinter type available to handle the considerable amount of detail required to properly handle nested and overlapping marks using in-band signals.

There is also a somewhat bare-bones printing system for outputting HTML, this has received less attention but may be sufficient to some uses. Correct output for this mode will require that the marked regions be properly nested, which terminal printing does not need.

Also included is a standalone colors module, which could be convenient for constructing and printing xterm-style SGR codes. This is namespace-included in obelizmo proper.

More complete documentation may be found in the README linked above, or in the doc comment for colors.

13 Likes
2

Looks compact, neat and usable. Just today I was fighting with a ‘console’ output with colors and wondering how to html-ize it as well.
I will surely remember this one!

1 Like
3

bonjour, hello,
I’ve had a few problems over the years, as consoles evolve.
At first I used simple markers like
(“\x1b[38;{d}m”) , but today to be compatible with consoles like Gnome, or Kitty type consoles I’ve had to adapt my code. As shown below

/// Sets the terminal's foreground color.
fn setForegroundColor(color: ForegroundColor) void {
    stdout.print("\x1b[38;5;{d}m", .{@intFromEnum(color)}) catch {};
}

/// Sets the terminal's Background color.
fn setBackgroundColor(color: BackgroundColor) void {
    stdout.print("\x1b[48;5;{d}m", .{@intFromEnum(color)}) catch {};
}

Now, I haven’t dealt with the RGB code, since I’m only addressing the console (Linux terminal).

4

That would look something like this:

/// Sets the terminal's foreground color.
fn setForegroundColor(color: u8) void {
    const fg = obelizmo.fg256(color);
    fg.printOn(stdout) catch {};
}

/// Sets the terminal's Background color.
fn setBackgroundColor(color: u8) void {
    const bg = obelizmo.bg256(color)
    bg.printOn(stdout) catch {};
}

I didn’t add a .format to Colors, although I suppose I could.

5

Did you test, on several consoles or do you plan to make your own console, for example I also made my own console with libvte3, and I plan to switch to gtk4 libvte4.

The renderings were not the same.

for example with xfce and vte the terminals are identical with XTERM , but with gnome ( gnome or cinnamon) the renderings hummmm, I think that if I had done RGB that I would not have had any problem.

ps: this is just a discussion.

1 Like
6

Nope.

It implements a wide variety of SGR codes, but determining which of them will have a visible result on what platform is out-of-scope for the library.

It also uses colons for separation, which is correct and which most ‘modern’ terminals and consoles parse. But use of semicolons, while ‘incorrect’, is very widespread, and there might be platforms out there which only parse SGR with semicolons.

I’ve made no accommodation for this, but could, maybe, be talked into it. My general philosophy is that ‘fixing’ upstream bugs is the very reason they don’t get fixed, but at the same time, users can get stuck in the middle of that kind of spat. So if I’m persuaded that this an actual not-abstract problem which I can solve, I probably would.

2 Likes