From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 20707@debbugs.gnu.org
Subject: bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors
Date: Mon, 01 Jun 2015 10:55:44 -0700 [thread overview]
Message-ID: <556C9CA0.3090400@cs.ucla.edu> (raw)
In-Reply-To: <83bngzts46.fsf@gnu.org>
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?
next prev parent reply other threads:[~2015-06-01 17:55 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-01 7:39 bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors Paul Eggert
[not found] ` <mailman.4052.1433144480.904.bug-gnu-emacs@gnu.org>
2015-06-01 10:49 ` Alan Mackenzie
2015-06-01 16:01 ` Paul Eggert
2015-06-01 17:17 ` Alan Mackenzie
2015-06-01 18:50 ` Paul Eggert
2015-06-02 11:56 ` Alan Mackenzie
2015-06-02 13:25 ` Drew Adams
2015-06-02 15:39 ` Paul Eggert
2015-06-02 15:51 ` Dmitry Gutov
2015-06-02 20:05 ` Paul Eggert
2015-06-02 17:07 ` Alan Mackenzie
2015-06-02 20:44 ` Alan Mackenzie
2015-06-04 15:43 ` Paul Eggert
2015-06-06 15:54 ` Alan Mackenzie
2015-06-06 18:11 ` Paul Eggert
2015-06-06 20:50 ` Alan Mackenzie
2015-06-07 0:09 ` Paul Eggert
2015-06-08 17:18 ` Alan Mackenzie
2015-06-09 6:53 ` Paul Eggert
2015-06-09 13:34 ` Alan Mackenzie
2015-06-09 20:49 ` Paul Eggert
2015-06-09 22:46 ` Alan Mackenzie
2015-06-09 23:42 ` Paul Eggert
2015-06-10 13:39 ` Alan Mackenzie
2015-06-10 16:20 ` Paul Eggert
2015-06-10 17:39 ` Dmitry Gutov
2015-06-10 19:42 ` Paul Eggert
2015-06-10 19:17 ` Alan Mackenzie
2015-06-10 19:44 ` Paul Eggert
2015-06-11 19:06 ` Alan Mackenzie
2015-06-12 2:41 ` Paul Eggert
2015-06-12 11:25 ` Alan Mackenzie
2015-06-12 23:46 ` Paul Eggert
2015-06-13 11:54 ` Alan Mackenzie
2015-06-13 17:54 ` Paul Eggert
2015-06-07 13:17 ` Wolfgang Jenkner
2015-06-09 16:58 ` Alan Mackenzie
2015-06-02 23:26 ` Paul Eggert
2015-06-01 14:34 ` Eli Zaretskii
2015-06-01 16:48 ` Glenn Morris
2015-06-01 17:55 ` Paul Eggert [this message]
2015-06-01 18:29 ` Eli Zaretskii
2015-06-01 21:13 ` Stefan Monnier
2015-06-09 19:44 ` Wolfgang Jenkner
2015-06-11 13:06 ` bug#20707: " Andy Moreton
2020-08-12 13:02 ` bug#20707: [PROPOSED PATCH] " Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=556C9CA0.3090400@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=20707@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).