Markus Kuhn wrote:
> You can probably add here even a widely used English punctuation that is
> usually transliterated into "--" (double HYPHEN-MINUS) on typewriters:
>
> U+2014 EM DASH
>
> I see actually no big problem to make all the circled and parenthesised
> numbers and letters doublewidth in the standard wcwidth, or even the EM
> DASH. It would just mean that the definition of wcwidth becomes an
> actual design issue, and not just like it is at the moment a function
> rather strictly derived from a Unicode database property. I also suspect
> that Japanese users will not really want to insist on doublewidth
> European letters. The only point of conflict that I see are the block
> graphics characters, as they are used in both communities widely with
> their respective widths. (Under Linux most notably the simple line
> drawing symbols that are present in the DEC VT100 graphics set.)
I'm confused. I thought that the width of a Unicode character was fixed.
Thus when I take a Unicode character, it is either defined to be single-width
or double-width.
If this is not true, I won't be able to edit Unicode with Vim reliably. I'm
using the current version of wcwidth(). When someone decides to make a font
with different widths, the display will be messed up. I suppose xterm has the
same problem. Running Vim in a xterm has a double problem (Vim can only guess
which characters will end up double-width in the xterm).
Perhaps using wcwidth() is wrong and it should be deleted? Should the width
of a character be obtained from the font information? Either that or the
results of wcwidth() should be set in stone.
--
A meeting is an event at which the minutes are kept and the hours are lost.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.moolenaar.net \\\
((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
\\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
