Re: PATCH: (large) initial support for combining characters in ZLE.

[Peter Stephenson <pws@csr.com>]

"Jun T." wrote:
> On 2008/04/18, at 18:40, Peter Stephenson wrote:
> >   so iswgraph() might be the thing.
> 
> There are about 15 characters for which "wcwidth() > 0 && ! iswgraph()"
> is true, all of them are a kind of white space (no tab or such).
> I personaly think "space + combining-char" is OK and
> just "wcwidth()>0" is enough for defining the base character.
> (wcwidth() is -1 for any control chars including tabs.)

It may well be OK from a standards point of view, but it's more
complicated in the shell, even if we restrict it to a space character
(which would still require an explicit test).  Space is a word delimiter
and without major surgery in the main shell any attached combining
character will be stripped off in lexical analysis; either that, or we
would need to ignore any spaces with combining characters.  This
fundamentally breaks the model that the main shell deals with an ASCII
byte stream with multibyte characters that aren't lexically significant.
Hence I'd prefer to make this clear from the manner of display.

A lexically non-significant (i.e. quoted) space in principle doesn't
need this special handling, but that would mean the line editor needs
lexical information, which I want to avoid:  this is one of the things
that makes the completion code so hard to handle.

(There's no general problem with elements of $IFS, by the way: the
initial command line is special and the delimiters have to be whitespace,
presumably to avoid just this sort of problem.)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070