Re: Metafication in error messages (Was: [PATCH] unmetafy Re: $var not expanded in ${x?$var})

[Stephane Chazelas <stephane@chazelas.org>]

2024-02-24 22:05:26 -0800, Bart Schaefer:
> On Sat, Feb 24, 2024 at 6:17 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > The actual tradeoff to make %l do the raw output is:
> > + fix the width calculation in math.c, then use %s *
> > + add one call to metafy() in parse.c, to use %s instead of %l **
> > + add one call to unmetafy() in subst.c, to use %l instead of %s
> > - remove metalen(), zhalloc(), memcpy(), and nicezputs() from utils.c
> > + add one call to fwrite() in place of the above
> 
> Stephane, if you really still think it preferable to add %S (thus
> moving the unmetafy() from subst.c to utils.c) then I think we should
> just do away with %l entirely.  Either way we're ending up with a
> branch in zerrmsg() that's used for exactly one special case.

I don't have a strong opinion on it. Either way, the internal
documentation should make it clear the metafy and nicezputs
expectations.

Like:

%s expects metafied string, prints it nicezputs'ed

%l expects non-metafied string and byte length, prints it raw.
   it's the caller's responsibility to make sure the string is
   not truncated in the middle of a character.

Note that there's truncating in between  the bytes of a
character and there's truncating between the characters of a
grapheme cluster like decomposed Hangul syllables (or
$'Ste\u301phane'). I don't think we'd want to try and address
that.

Other option could be to have %s, %S and %*s %*S and let
nicezputs do the truncation and ellipsis in %*s case which might
be a cleaner interface if (likely) more cumbersome to implement.

-- 
Stephane