Re: bug#23425: master branch: `message' wrongly corrupts ' to curly quote.

[Alan Mackenzie]

Hello, Paul.

On Mon, Jun 05, 2017 at 17:14:37 -0700, Paul Eggert wrote:
>  >> Elisp code needed to use
>  >> (message "%s" STR) even before the change you're objecting to,

>  > Did it?  When and why?

> Yes, because one can’t pass arbitrary strings to the message function 
> and expect them to be displayed as-is.

This has absolutely nothing to do with the current bug, and I'm sorry if
I've discussed the point as though it did.  I'm not suggesting arbitrary
strings should be messaged without a "%s" format string.

What I am arguing against is being required to use _two_ format strings
in one message invocation, as (message "%s" (format "..." ...)).  This
just screams out "not thought through" and is unacceptable.

>  > Somebody using message to output Lisp will use ' just as I did - and 
>  > suffer the same horrendous problems

> Sure, like the “horrendous” problems with %.

That's pure sophistry.  _Nobody_, excepting the least bright of your
students (I'm assuming here that it's not the teaching which is at
fault) will have the slightest difficulty with % in message, because it
stands out visually.  Every format construct (up to Emacs 24) started
off with %, and that simplicity and symmetry has now been destroyed.  I
propose to restore it.

By contrast, the current ` and ' are disguised format constructs which
look like plain characters.  They should become %` and %' to make them
explicit and compatible with all the other format constructs.

> For example, in Emacs 24 your example, when used with data involving
> %:

[ .... ]

That example from CC Mode, which gave rise to this bug report, did not
have and could not have had % signs.  If the reverse had been the case,
they would have been carefully and correctly coded before even trying
the thing out, because I, like everybody else here, know that %
introduces format constructs.

>  > Do you, perhaps, have another strategem for preventing this problem?

> Sure: don’t pass arbitrary strings to the message function.

In other words, just ignore the problem, and have it hit as many people
as it will, without giving them any help.  That's not very nice of you.

>  > How do you propose to prevent such puzzlement and anger in the future

> Not by this:

>  >>           (error "Can't find `%s' in %s" thing where)))
>  >>   =>      (error "Can%'t find %`%s%' in %s" thing where)))

> For Emacs code this would likely be a cure worse than the disease,
> ....

How so?  It would make the format constructs explicit, giving maximum
control to the hacker.  Or do you want to make all the curvy quote stuff
as sly and stealthy as possible, so that as few hackers as possible will
be aware of it?

> .... by causing more puzzlement and anger than it would prevent.

How could it cause puzzlement?  It's mnemonic and consistent with the
other format constructs.

> It would make formats significantly harder to read.

But only slightly.  You seem to be saying that the formats need to be
dumbed down for hackers to understand them.  I'm sure you're not right,
here.

> And as Clément mentioned, it would introduce compatibility problems of
> its own.

Rubbish!  What Clément pointed out is that the part of styled_format
which counts format constructs and argumnts would need to be modified.
This would be trivial.

> There is a better way if the primary goal is to avoid quote translation:

>             (error "Can't find `%s' in %s" thing where)))
>     =>      (error "Can’t find ‘%s’ in %s" thing where)))

> Compared to %` and %', this is simpler, easier to read, and more 
> compatible with current and older Emacs versions.

Except those characters don't appear on non-Finnish keyboards, hence are
difficult to type, and they don't display nicely on all supported
environments.  These things make that suggestion a non-starter for
current purposes.

> A downside, though, is that it would involve changing hundreds or
> thousands of strings in the Emacs source (just as %` and %' would).

There's already a volunteer to do this work, so that's not really a
downside at all.

>  > You're not seriously
>  > telling me that any of your students who've written a message call with
>  > a "%s" in the format string remain unaware of the role of %, are you?

> Sure, they learn about % after the message function doesn’t work the way 
> they naively expected. In that respect, % is like ` and '.

Only in the same sense that Emacs is like Microsoft's notepad, in that
they're both text editors.

Only the rawest of beginners will be confused by a % in a format string.
That is not the level of experience we expect of our target users.

>  > There are around 275 calls to message which have a non-literal
>  > format argument.

> Each one stands for possibly many other calls, and we don’t know how 
> many of these other calls might cause a problem.

No, but the number will be small enough for each instance to be dealt
with individually.

>  > The consequences of surreptitious unwanted translation ...
>  >> It's not surreptitious: it's documented.

It may be documented, but it's still surreptitious.  It seems intended
by its writer to be as hidden as possible, so as to make those using it
as unaware as possible of the consequences of its use.  If you don't
like %` and %', perhaps you could suggest some other way of preventing
the nature of ` and ' in format strings from being so obscure.

>  > And this documentation is useless for preventing the problems.

> True, documentation by itself does not prevent programming problems. 
> However, this doesn’t change the fact that quote translation is 
> documented. It is not “surreptitious” or “implicit” or “vague” or 
> “stealthy” or “fuzzy”.

It is most definitely implicit, in that there is no indication in the
format string that quote translation happens, it is stealthy, in that it
goes out of its way to hide its actions.  It is vague, in that a hacker
who sort of knows message will be permanently unsure which characters in
a format string are not literal.

This documentation, no matter how good it might be made, will be
insufficient to prevent hackers falling into the trap which the code
sets.  This part of Emacs is badly thought out for this reason: it's an
accident waiting to happen.  I am proposing to fix it, and have
volunteered to do the work.

-- 
Alan Mackenzie (Nuremberg, Germany).