Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Core dump with latest CVS
- X-seq: zsh-workers 22714
- From: Peter Stephenson <pws@xxxxxxx>
- To: zsh-workers@xxxxxxxxxx (Zsh hackers list)
- Subject: Re: Core dump with latest CVS
- Date: Fri, 15 Sep 2006 16:36:53 +0100
- In-reply-to: <060915081653.ZM9804@xxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20a807210609141402v31714a98wab9b75ff7736327@xxxxxxxxxxxxxx> <200609150957.k8F9v4uq021513@xxxxxxxxxxxxxx> <200609151308.k8FD8IGQ025083@xxxxxxxxxxxxxx> <060915081653.ZM9804@xxxxxxxxxxxxxxxxxxxxxx>
Bart Schaefer wrote:
> My concern is that "printability" shouldn't have anything to do with it.
> Programmatically, the expression
>
> (( ${#:-X} == 1 && ${#(pl.width..X.)} == width ))
>
> should always be true.
OK, you're interpreting "width" differently... to me, that's a string
length, not a width at all. It doesn't really matter as long as it's
documented.
So that would be the last option I posted, treat multibyte characters
but assume they have width 1 (or, in better English, use string lengths
rather than character widths for padding) unless there's an additional
flag. I would propose to supply such a flag, if we go this way.
> I could see an argument that ${#(%pl.width.X)} could compute the padding
> based on printable width, because the presence of % means we're expanding
> prompt escapes so presumably we want printable values
I don't really see why a normal user would assume the expression
*didn't* deal with printable widths, but, again, that's mostly a matter
of documentation.
--
Peter Stephenson <pws@xxxxxxx> Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php
Messages sorted by:
Reverse Date,
Date,
Thread,
Author