I have to admit that this function is actually very fragile. Last night, I did some reading on unicode and emoji encodings and discovered that it's *basically impossible* to predict the "visual width" of a sequence of unicode codepoints.
So, this function as written will only really work if we stick to single-codepoint glyphs that can be rendered 1:1 in a monospace font.
I could probably improve it to work with "some" (but certainly not all) wide glyphs and emoji, but it's a very complex topic and far outside my specialty. Support for multi-codepoint narrow/halfwidth glyphs is also an issue. (This affects some Latin characters outside of ascii if they are encoded using combining codepoints.)
So I must admit that this function has some very serious limitations to it. I want to explain why I wrote it, though.
First: Tracebacks make people's eyes cross over. It's a very long sequence of mumbo jumbo that most people don't read, because it's program debug information. I don't blame them. Setting apart the error summary visually is a helpful tool for drawing one's eyes to the most critical pieces of information.
Second: In my AQMP library, I use the ascii vertical bar | as a left-hand border decoration to provide a kind of visual quoting mechanism to illustrate in the logfile which subsequent confusing lines of jargon belong to the same log entry. I really like this formatting mechanism, but...
Third: If a line of text becomes so long that it wraps in your terminal, the visual quote mechanism breaks, making the output messy and hard to read. Forcibly re-wrapping the text in a virtual box is a necessary mechanism to preserve readability in this circumstance - the lines from qemu-img et al may be much wider than your terminal column width.
And so, I drew a box instead of just a left border, because I needed to re-wrap the text anyway. Visually, I believed it to help explain that the output was being re-formatted to fit in a certain dimensionality. Unfortunately, it's inadequate.
So ... what to do.
(1) I can just remove the right margin decoration and call the function visual_quote or something. If any of the lines get too "long" because of emoji/日本語, it MAY break the indent line, but occasional uses of one or two wide characters probably won't cause wrapping that breaks the "visual quote line" on a terminal with at least 85 columns. Essentially it'd still be broken, but without a solid right border it'd be harder to notice *small* breakages.
(2) If there is a genuine interest in using visual highlighting techniques to make iotest failures easier to diagnose (and making sure it is properly multilingual), I could use the urwid helper library to estimate visual text width to make drawing terminal boxes more resilient than what I could do on my own power. Downside is a new third party dependency. I already use urwid for the aqmp tui that we're working on, but it's remained an optional dependency so far.
(3) I can take a swing at improving this text decoration utility and having it account for the most basic cases. East Asian language support is a low hanging fruit, though I have only rudimentary familiarity with Hangul. (And virtually no exposure to Thai or other south-eastern Asian scripts.)
(4) Just leave it alone for now, don't you have IDE/FDC patches to work on?
Sigh. The punishment for trying to do something nice is swift.
--js