Re: [PATCH 2/2] Allow check-mark to be changed for CLI

Pedro Alves
2025-06-25T19:11:54Z

Hi,

On 2025-05-16 17:16, Eli Zaretskii wrote:
>> From: Tom Tromey <tromey@adacore.com>
>> Cc: Tom Tromey <tromey@adacore.com>, gdb-patches@sourceware.org
>> Date: Fri, 16 May 2025 08:20:03 -0600
>>
>>>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:
>>
>> Andrew> Tom Tromey <tromey@adacore.com> writes:
>>>> In keeping with the emojification of gdb, this patch changes the
>>>> default "current" marker to be a check-mark. It adds a knob to allow
>>>> the character to be changed, and, as always, reverts to the old output
>>>> when emojis are disabled.
>>
>> Andrew> I haven't tested this patch just yet (short of time), but I wonder if I
>> Andrew> set the check-mark character to a multi-character string, does that
>> Andrew> corrupt the output? I'm guessing so as I don't think table columns
>> Andrew> auto-adjust.
>>
>> Andrew> So my real question: at a minimum, should the docs mention that the
>> Andrew> STRING should only be a single character. And better yet, can we check
>> Andrew> that the string is only a single character in width somewhere?
>>
>> Yeah, I will update the docs in v2.
>>
>> I don't think there's any way to figure out what the display width of a
>> string might be. At least, not unless gdb adds a dependency on
>> something like libicu.
>
> I don't think even libicu will be enough, because the terminal
> emulators vary in this respect.
>
> There's some recent protocol to help with this, but I don't think it's
> supported widely enough for GDB to rely on it.

I'm curious on what protocol is this, and what it addresses.

If we assume monospace font in the terminal, what goes wrong?

I mean, if someone uses a non-monospace font, then everything will be unaligned anyhow.

Is there a downside to using the number of columns wcwidth says the character occupies,
and default to 1 if wcwidth returns -1?