On Tue, Feb 15, 2022, 6:57 PM Philippe Mathieu-Daudé <f4bug@amsat.org>
wrote:
On 16/2/22 00:53, John Snow wrote:
> On Tue, Feb 15, 2022 at 5:55 PM Eric Blake <eblake@redhat.com>
wrote:
>>
>> On Tue, Feb 15, 2022 at 05:08:50PM -0500, John Snow wrote:
>>>>>> print(enboxify(msg, width=72, name="commit message"))
>>> ┏━ commit message
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
>>> ┃ enboxify() takes a chunk of text and wraps it in a text art
box that ┃
>>> ┃ adheres to a specified width. An optional title label may
be given, ┃
>>> ┃ and any of the individual glyphs used to draw the box may
be ┃
>>
>> Why do these two lines have a leading space,
>>
>>> ┃ replaced or specified as well. ┃
>>
>> but this one doesn't? It must be an off-by-one corner case
when your
>> choice of space to wrap on is exactly at the wrap column.
>>
>
> Right, you're probably witnessing the right-pad *and* the actual
space.
>
>>>
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
>>>
>>> Signed-off-by: John Snow <jsnow@redhat.com>
>>> ---
>>> python/qemu/utils/__init__.py | 58
+++++++++++++++++++++++++++++++++++
>>> 1 file changed, 58 insertions(+)
>>> + def _wrap(line: str) -> str:
>>> + return os.linesep.join([
>>> + wrapped_line.ljust(lwidth) + suffix
>>> + for wrapped_line in textwrap.wrap(
>>> + line, width=lwidth, initial_indent=prefix,
>>> + subsequent_indent=prefix, replace_whitespace=False,
>>> + drop_whitespace=False,
break_on_hyphens=False)
>>
>> Always nice when someone else has written the cool library
function to
>> do all the hard work for you ;) But this is probably where you
have the off-by-one I called out above.
>>
>
> Yeah, I just didn't want it to eat multiple spaces if they were
> present -- I wanted it to reproduce them faithfully. The tradeoff is
> some silliness near the margins.
>
> Realistically, if I want something any better than what I've done
> here, I should find a library to do it for me instead -- but for the
> sake of highlighting some important information, this may be
> just-enough-juice.
's/^┃ /┃ /' on top ;D
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.