Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Unicode problem
- X-seq: zsh-workers 24417
- From: "Mikael Magnusson" <mikachu@xxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: Unicode problem
- Date: Mon, 21 Jan 2008 15:29:48 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=IvG4i/ebINx2O10jtT+xiKeaCbfBFoiG+mEHjLt3rq0=; b=yE41VjlJIjn4mDX1cwvgQmIuXJVoPClc4PgBJe1EnxYrHUmyWE+YB/yqy5QqFvBpdcGTf1VEn29VSpumGLIAXSXr5dcykomxRLyWeya/H4eL059HmRwcicI2RWdpizD/5uTpK0dTSLhnC9poZ5VU6S9IlpivtAZyrY1DkSCXAu0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HBvEdrIpRb6NutCxIPNoURWatrc+UrXKtUoHRhOqBS1mufIK1KnyOt/ueHtbWX5lL45jfmUnQTN7my0lnlmzFldAO+hKj0NUlSqicROqwRiqAs16GluOdSNLgVCejyLbw2iPJkwNlwjtH/QSpdo5wbWisk73h5mk7VuEVDSWmw8=
- In-reply-to: <200801211415.m0LEFbbU017355@xxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <slrnfouc3r.6ea.joerg@xxxxxxxxxxxx> <20080117120932.4458d35a@news01> <slrnfp97q5.dvv.joerg@xxxxxxxxxxxx> <200801211415.m0LEFbbU017355@xxxxxxxxxxxxxx>
On 21/01/2008, Peter Stephenson <pws@xxxxxxx> wrote:
> > The zero width character is drawn with width one?
>
> Yes, that's what gnome-terminal is doing. It seems to agree with the
> screen width the library code is reporting (I didn't check explicitly
> but the behaviour is consistent with that).
>
> I think there are actually two widths involved here: the screen width
> used with a fixed-size font for editing (applicable to zsh), and the
> logical width of the character that would appear in a document. The
> latter is typically different to the former (in particular when a
> variable width font is in use), and it's the latter case where it needs
> to be zero width. There's a kind of hybrid case for a WYSIWYG word
> processor where it needs to flag up the space for editing even though
> pretending it's behaving as zero-width, but this is a special case of
> variable-width fonts. The information in the library as returned by
> wcwidth() is only applicable to fixed width fonts, where "zero width" is
> essentially meaningless; a character width must be 1, 2, ... So I think
> gnome-terminal is doing the right thing here, although I can understand
> the confusion.
Combining characters combine with the character(s) that come before
them. So if you write an feff or 336 or whatever, they will combine.
The terminal doesn't know where the prompt ends and the input line
starts, so when you give it a space and a combining char, it will draw
the combining char on top of the space before it. The combining char
always has width 0 because nothing has moved from drawing it. The
space with the combining char on top is of course width 1. If you
write a double width space and then a combining char, it will
similarily appear to have width 2.
I guess what you want to do in zsh is just count them as width 0, and
have the cursor skip over them, so if you are on the right of a<336>
and press left you should end up to the left of a. If the user types
one at the start of the line, i think you should _draw_ an extra space
before it, but not insert the space into the actual commandline
(because everything should work if a binary is named with a combining
character first i think). Alternatively you could disallow it and have
the user type out \u0336 instead (if that's the right syntax), or
maybe autoconvert it?
I don't know what do do with the zero width space though. :)
--
Mikael Magnusson
Messages sorted by:
Reverse Date,
Date,
Thread,
Author