unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: 20707@debbugs.gnu.org
Subject: bug#20707: [PROPOSED PATCH] Use curved quoting in C-generated errors
Date: Mon, 01 Jun 2015 21:29:05 +0300	[thread overview]
Message-ID: <83twurs2oe.fsf@gnu.org> (raw)
In-Reply-To: <556C9CA0.3090400@cs.ucla.edu>

> Date: Mon, 01 Jun 2015 10:55:44 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 20707@debbugs.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.

I'm not sure testing this in a single non-UTF-8 locale is enough.

> 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.

There are no UTF-8 locales on Windows, and I don't think there are any
plans to introduce them.

Perhaps teaching .dir-locals.el to support directory-wide default
encoding is the best approach.

> > 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.

Right, but why do we want u8 there?  Isn't it to make sure the string
ends up in UTF-8 in the binary when the source code is encoded in
something other than UTF-8?

> 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.

We no longer support Microsoft compilers anyway.

> > '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?

The convoluted logic of deciding when to produce a multibyte string
sometimes surprised me in the past, so I tend not to trust it.  We
know what we want in this case, so why not use make_multibyte_string
directly?





  reply	other threads:[~2015-06-01 18:29 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
2015-06-01 18:29     ` Eli Zaretskii [this message]
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=83twurs2oe.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=20707@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    /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).