bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors

[Paul Eggert]

On 06/01/2015 07:34 AM, Eli Zaretskii wrote:
>  They use UTF-8 encoded characters, and so will require a suitable 
> 'coding:' cookie in the affected files, or some equivalent setting 
> (perhaps in .dir-locals.el?), otherwise they might not be decoded 
> correctly in non-UTF-8 locales.

Good point, and this raises a related issue with all text files in the 
Emacs repository that aren't ASCII.  The way I've been testing this sort 
of thing is to visit a source file in a Latin-9 locale, and if it is 
correctly decoded as UTF-8 then I don't bother with adding a coding: 
cookie.  To be honest I've been hoping that use of non-UTF-8 locales 
would be dying off among Emacs developers, so that we wouldn't need to 
worry about sprinkling coding: cookies everywhere.  But if it's really 
needed I suppose someone should make a pass over the source code....

> Doing so might remove at least part of the need for using the u8 
> qualifier, I think.

The u8 prefix is for C compilers, not for Emacs, and the C compilers 
won't know about coding: cookies.

Come to think of it, though, perhaps we can dispense with u8.  As far as 
I know u8 is needed only for MS-Windows compilers when the source code 
is in UTF-16 or suchlike but you want the string to be UTF-8.  Emacs 
source code is never in UTF-16 so this shouldn't be an issue.  Getting 
rid of u8 would remove the need for uLSQM and uRSQM which would be nice.

> 'error' calls 'verror', which calls 'make_string' to actually produce 
> the message string. However, 'make_string' is not reliable enough wrt 
> whether it produces unibyte or multibyte strings

Hmm, why isn't make_string reliable enough?  If the string is validly 
encoded UTF-8 (a safe assumption here), then make_string should produce 
a unibyte string if its ASCII only, and a multibyte string otherwise, 
and either way the string value should be OK. What am I missing?