[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[screen-devel] [bug #55138] Bug: UTF-8 characters in hardstatus not work
From: |
Amadeusz Sławiński |
Subject: |
[screen-devel] [bug #55138] Bug: UTF-8 characters in hardstatus not working |
Date: |
Sun, 17 Feb 2019 18:06:45 -0500 (EST) |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0 |
Update of bug #55138 (project screen):
Status: None => Duplicate
_______________________________________________________
Follow-up Comment #14:
It's well known deficiency, there is quite few similar bug reports:
24208 hardcopy doesn't handle Unicode.
36172 hardstatus utf-8 padding
39330 Cannot :title ♬
44366 hardstatus lastline UTF-8 corruption
52296 Some unicode characters in hardstatus corrupt screen + hardstatus
There are things that can be done.
1. massage current encoding handling into hardstatus
2. rewrite whole encoding handling from scratch (noting where inputs come
from, and where outputs are)
Personally I prefer option 2, because currently due to legacy reasons, we keep
encoded character in 4 variables (image, font, fontx, mbcs), while we could
just use one uin32_t (/uct4_t) and decode all input to utf-32 and then encode
it to output format. In fact I already tried following this path, using
libunistring helpers (https://github.com/amade/screen/tree/encoding-rewrite),
but it got bit messy and I started thinking that maybe screen should have its
own set of encoding handling functions like it has now, but rewritten from
scratch.
Still it requires plugging a lot of input/output handling into correct places.
There is quite few input points as well as output.
input points are:
* disp_readev_fn - display input function (user input)
* win_readev_fn - everything we read from windows (program output)
* Input - input prompt (confirmation etc.)
* config file - .screenrc
* all variables read from command line
* getenv
output points are:
* disp_writeev_fn - display output function (screen output - composite of
program output)
* win_writeev_fn - everything we write to windows (user input - passed to
running program)
* logfiles
* setenv
* hardcopy
and probably few that I missed, but became obvious when you start working on
it.
Although now that I look again at work that I did, maybe it's not that bad,
could probably use rebasing on latest code, some cleanup and then fixing rest
of unfinished conversions and maybe rethinking some places where we convert
stuff if it can be done in better way.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?55138>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
- [screen-devel] [bug #55138] Bug: UTF-8 characters in hardstatus not working, Nicolas Schodet, 2019/02/14
- [screen-devel] [bug #55138] Bug: UTF-8 characters in hardstatus not working, Elof, 2019/02/14
- [screen-devel] [bug #55138] Bug: UTF-8 characters in hardstatus not working, Nicolas Schodet, 2019/02/15
- [screen-devel] [bug #55138] Bug: UTF-8 characters in hardstatus not working, Elof, 2019/02/16
- [screen-devel] [bug #55138] Bug: UTF-8 characters in hardstatus not working, Elof, 2019/02/16
- [screen-devel] [bug #55138] Bug: UTF-8 characters in hardstatus not working, Nicolas Schodet, 2019/02/17
- [screen-devel] [bug #55138] Bug: UTF-8 characters in hardstatus not working, Elof, 2019/02/17
- [screen-devel] [bug #55138] Bug: UTF-8 characters in hardstatus not working, Nicolas Schodet, 2019/02/17
- [screen-devel] [bug #55138] Bug: UTF-8 characters in hardstatus not working,
Amadeusz Sławiński <=
- [screen-devel] [bug #55138] Bug: UTF-8 characters in hardstatus not working, Nicolas Schodet, 2019/02/18
- [screen-devel] [bug #55138] Bug: UTF-8 characters in hardstatus not working, Elof, 2019/02/18
- [screen-devel] [bug #55138] Bug: UTF-8 characters in hardstatus not working, Nicolas Schodet, 2019/02/21