Re: [dev] [st] Strange behaviour of backspace under csh under st
Jinsong Zhao wrote in
<09350f56-59c1-4a2f-b7cc-9063e0c241b2_AT_yeah.net>:
|I was trying to use st on a FreeBSD workstation, and my shell is csh.
|When I use backspace to delete the Chinese character, I observe strange
|behavior.
|
|On the first,
|zjs_AT_freebsd:~ % 中文|
|
|After pressing a backspace key,
|zjs_AT_freebsd:~ % |
|
|After pressing ctrl + l to refresh st,
|zjs_AT_freebsd:~ % 中|
|
|The vertical bar indicates the cursor position.
|
|This behavior is observed under bash, but not under sh.
|
|Any hint would be greatly appreciated.
Which locale is it that you are using? I think (pretty sure) st
supports only UTF-8 locales, so that is one thing. Cannot be any
of those
zh_CN.GB18030.src
zh_CN.GB2312.src
zh_CN.GBK.src
zh_CN.eucCN.src
zh_TW.Big5.src
that i see in origin/main:share/colldef; try locale -a aka
zh_CN.utf8 or better BSD-style zh_CN.UTF-8.
Also .. now looking .. st simply assumes it can hand-join UTF-8 to
UTF-32 and take that as a wchar_t for using the wcwidth(3)
function that is part of FreeBSD. Now letting aside the fact that
the Citrus library they used when i was looking for real last
(many years ago after which Daroussin then implemented something
to be able to generate actualized character mapping tables and
more from Unicode aka ICU releases *if* i get that right) had some
special things which violate(d) that assumption back in the day,
i cannot tell whether (a) this is still true (b) this has ever
been true for zh_, especially not with UTF-8. (Likely not.)
The issue as such seems to me pretty known in that backspace does
not seem to erase all bytes for real, so that a repaint brings
back garbage.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|And in Fall, feel "The Dropbear Bard"s ball(s).
|
|The banded bear
|without a care,
|Banged on himself fore'er and e'er
|
|Farewell, dear collar bear
Received on Thu Nov 07 2024 - 02:37:34 CET
This archive was generated by hypermail 2.3.0
: Thu Nov 07 2024 - 02:48:10 CET