[Bug tui/28800] non-ascii character cannot display correctly in tui-mode's extended-prompt

["aburgess at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28800

Andrew Burgess <aburgess at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-01-27
                 CC|                            |aburgess at redhat dot com

--- Comment #2 from Andrew Burgess <aburgess at redhat dot com> ---
Andreas,

This is a slightly different issue you are seeing.  I'm guessing you have
gdb.prompt_hook set.  This ends up calling gdbpy_before_prompt_hook in
python.c.

If we assume Python 3 for a moment, then in this function we convert the prompt
to a unicode object, assuming UTF-8 encoding.  This unicode object is then
passed to the users python code.

If the user returns the same prompt unchanged, or even some other utf-8 encoded
prompt string, we then convert that string back to bytes using the
host_charset.

>From the error message you see, it would appear your hostchar set is maybe
'ascii'?  I'm guessing it's certainly not utf-8.

You could try: 'set host-charset UTF8' and see if the problem is resolved.

The asymmetry in our use of different unicode encodings seems like a bad thing
to me ... I wonder if we should just fix on one particular scheme, maybe utf-8
for some of the cases like this?

However, we should probably spin this conversation into a separate bug as this
is different to the original unicode within tui bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.