Open egmontkob opened 6 years ago
oh, thanks for this tricky tips.
i do not have time to test it, too many bug to fix. Delay to 3.1
The proposed solution is to set encoding to locale specific to match old behavior, but can we not just spawn and set the terminal's encoding to utf-8 if that's the way vte is going to move forward? Haven't begun on diving and writing yet so I might not have the full picture on this yet but unicode is presumably more complete than any of the locale specific encodings that the newer version is presumably moving away from. Do we have a picture of locales that are significantly negatively impacted by us using UTF-8?
VTE changed its encoding at one point. It used to default to the locale's one, now it defaults to UTF-8.
Since Guake doesn't have an option for the encoding and doesn't set it, this results in a visible change compared to gtk2-based Guake for those who don't use UTF-8.
In the gtk2 version, Guake started the terminal with the locale's encoding, and hence provided a consistent, working (albeit obsolete) experience to its users.
With the gtk3 version, the terminal's actual behavior is UTF-8, whereas the locale describes a legacy encoding towards the applications running inside, resulting in all the non-ASCII characters being broken.
In order to preserve the previous behavior and provide a consistent, working experience for legacy users, I recommend Guake to execute the python equivalent to
vte_terminal_set_encoding(..., nl_langinfo(CODESET), ...)
in its terminals.