Re: Feature request: ${(l[-3][0])var} to do left padding *without truncation*

[Stephane Chazelas <stephane@xxxxxxxxxxxx>]

2024-08-04 20:56:19 -0700, Bart Schaefer:
> On Sun, Aug 4, 2024 at 7:15 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> >
> > I have a slight preference for leaving get_intarg() as it is, and
> > instead have the caller check for a leading '-' before calling it.
> 
> ... but that depends on whether "-" is supposed to be a signifier like
> in printf, or whether a negative is meant to be computable.  Hm.

It being a l[arithmetic-expression][padding], the latter would
make more sense I'd think.

Like in width=-3, ${(l[width][pad])array}.

In the case of the "I" flag (also using get_intarg), the
${(I[-1])var/x/y} (not implemented in my patch, just a TODO
there) would be consistent with $array[-1] (I guess a
${(I[2,-3])var/x/y} could also be added and then get_intarg()
could no longer be used).

If requiring a prefix to the number, then maybe using:

${(l[<arith][pad])var}: pad+truncate (default if <, > ommitted)
${(l[>arith][pad])var}: pad only

would be better, as a leading </> is otherwise not valid in an
arithmetic expression.

Now, beside the issue with prefix/suffix, my patch was also
wrong when s and r are combined as then two halves of the string
are padded+truncated separately. It's not just a matter of
leaving the string (+prefix+suffix) alone if it would fit in the
total padding length, as halves could still end up being
truncated then. Looks like I'll need to give it more thought.

-- 
Stephane