Re: quotearg improvements [was: filenames in error messages]

[Bruno Haible]

Eric Blake wrote:
> Consider the original filename of `dir??/file'.  Before my patch, the
> c_quoting_style converted it to `"dir?\?/file"', since `??/' is a trigraph
> for `\', but that is not a valid C string.  Right now, the output is
> `"dir?""?/file"', i.e. two concatenated C strings, so that a C parser
> would unambiguously recognize the quoted output, even if it is parsing
> trigraphs.

Sorry, but you lost me here. Where did the C trigraphs come into play?

You started by pointing out an ambiguity in error message output. The
desire was to define a variant syntax that would be
  1. possible to parse unambiguously,
  2. still understandable to a human user.

And now you are talking about C trigraphs, this invention whose only
purpose is to write C in a character set that lacks brackets, braces,
backslash and similar characters? And that are not understood by 99.9%
of the human users?

> For C strings, the code already outputs \a, \b, \f, \n, \r, \t, \v, \\,
> \"; and for all other non-printable characters, a 3-digit \nnn octal

So you want to escape, in an UTF-8 locale, all non-ASCII characters or bytes?
So that a Japanese user, for an error in file をつけた時でも, gets to read
\343\202\222\343\201\244\343\201\221\343\201\237\346\231\202\343\201\247\343\202\202
 ?

This is far, far away from the original goal, and also neglects the principle
of minimal surprise. I mean, if the goal is to solve ambiguities, then please
add enough escapes to solve ambiguities, but not more than that!

Bruno