Tomohiro KUBOTA wrote on 2001-06-12 02:52 UTC:
> My wonder is how wcwidth() can give the right value with SCW.
One purpose of SCW is to override the remote wcwidth convention with
that of the local host application, in particular in situations where
the default behaviour is not desired (mostly for Japanese people who
want double-width Cyrrilic and box drawings).
> There is one more problem with wcwidth(). It does not work well
> for remote terminal.
You mixed up problem and solution here. A luit/screen-like tool can be
used to export in a state-less way the local wcwidth convention to the
remote terminal. SCW is used to annotate a stream of UTF-8 characters
with explicit width information.
> This is because wcwidth() is controlled by
> remote system (OS and library) while the actual width is determined
> by local system (terminal). SCW cannot solve this problem.
It was specifically designed to solve that problem.
> I think it is possible. For example, application softwares can
> know the size of the terminal (ex. 80x24). However, it is nonsense
> that terminals will send the width information for all UCS characters
> on invocation. Thus, how about having a few modes?
Did you miss the discussion we had about that topic here a few weeks
ago? No more modes. Modes considered harmful! We want to reduce terminal
state as much as possible. Also no additional state query commands,
since their replies are difficult to separate from keyboard data.
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
