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

[Alan Mackenzie <acm@muc.de>]

Hello, Paul.

On Thu, Jun 04, 2015 at 08:43:50AM -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:
> > a typical use of Q would look like this:

> >      error ("Buffer name " Q(%s) " is in use", SDATA (name));

> I'm afraid that's not sufficient, as sometimes we have code like this:

[ .... ]

> though this is starting to get ugly.

> The more serious problem, though is that neither approach will work well in the 
> Elisp code, which is where the vast majority of these quotes live.

[ .... ]

> I considered changing 'format' so that it automatically curves quotes in the 
> format string.  But that would mishandle common cases like this:

>       (format "\\`%s" path-separator)

> where 'format' is being used to compose a regular expression containing '\`'.

> More reasonable would be to add a new function, 'format-message', that behaves 
> like 'format' except it also curves quotes, and to change functions like 
> 'message' and 'error' to use 'format-message' instead of plain 'format'.  But 
> even here we have lots of examples like this:

>       (y-or-n-p (format "File `%s' exists; overwrite? " filename))

> where we'd have to change 'format' to 'format-message'.

> We could go the GCC route and add a new format flag 'q', so that the above 
> examples could be written like this:

>      (format "Parsing %qs: expected %s %qs, got %qs." a b c d)
>      (y-or-n-p (format "File %qs exists; overwrite? " filename))

, or even "Parsing `%qs': expected %s `%qs', got `%qs'.", where the q
means "make the surrounding quote marks display marks".

> This approach would make sense if 8-bit environments were still common, as they 
> were when GCC added the 'q' flag to its message formatter.  However, nowadays 
> 8-bit environments are obsolescent (sorry) and so this approach seems like 
> overkill now.

8-bit environments may not be all that common any more, at least on a
desktop machine, but what about over comms links?  Linux consoles are not
rare: anybody on a G/L machine without X (e.g. a server) will be using
one, as well as those, such as I, who prefer the directness and lack of
distraction the console provides.

On the Linux console, there are a maximum of 256 glyphs which can be
displayed (or 512 if you're prepared to do without half of the colours),
each of which can be assigned to an arbitrary set of unicode characters.
This limit is a hangover from video hardware made ~30 years ago, and it
is a shame that it still persists, even on modern software generated
video.

> If we are bothering to go through code to fix quotes, it's better 
> to change the above examples to:

>      (format "Parsing ‘%s’: expected %s ‘%s’, got ‘%s’." a b c d)
>      (y-or-n-p (format "File ‘%s’ exists; overwrite? " filename))

I assume that the single quotes in there are the curly ones.  I literally
cannot see the difference, since the two varieties of quotes are mapped
to the same glyphs in my consolefont.  (The curly double quotes are not
mapped at all, hence display as inverse question mark.).

I think it is this lack of WYSIWYH ("what you see is what you have") that
makes me most unhappy about this proposed change to curly quotes.

> for two reasons.  First, unlike %qs the resulting code will work on older Emacs 
> implementations and thus will make the code more backward-compatible.

But it will not work well on a console, even with the most recent Emacs.

> Second, it's easier to read and maintain quote marks that you can see.

See the `%qs' idea above.

-- 
Alan Mackenzie (Nuremberg, Germany).