[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alan Mackenzie
Subject: bug#23425: master branch: `message' wrongly corrupts ' to curly quote.
Date: Fri, 9 Jun 2017 19:41:42 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Paul.

On Thu, Jun 08, 2017 at 13:17:39 -0700, Paul Eggert wrote:
> On 06/08/2017 10:34 AM, Alan Mackenzie wrote:
> > YUCK! So we'd have both message and memo doing basically the 
> > samething, with different interfaces.

> If it’s the API difference you object to, it’d be OK for the two 
> functions to have the same signature. It’s no big deal.

It's not OK to have two functions doing the same thing.

> > you've got two functions which are so close to each other, one
> > single function would be better.....

> If having one single function would mean changing hundreds or thousands 
> of callers, then there is an important sense in which one single 
> function would not be better.

That depends solely on whether anybody's prepared to do the work.

You're proposing changing `message' to `memo' for those callers anyway.
If you do that, we will end up with a horrible mess, with two almost
identical functions competing in the vast space of messaging where there
are no quote characters in the format string.  This would leave unsolved
the problem of format strings containing both literal quote characters
and quote characters for possible replacement by curlies.

We should be looking firstly at where we want to end up, and only later
at whether we can get there.  I still maintain that the most
satisfactory solution now available is for %` and %' to become part of
the format string, as already described.

> > NOBODY will write (message "30%-50% done")

> Admittedly the example was contrived, but I thought it was cool how one 
> can use % to delete parts of messages, something that is much worse than 
> quote restyling. More commonly people compute a message string S 
> somewhere else and then call (message S), and that does have real 
> problems with %, particularly in situations where an adversary has some 
> control over the contents of S.

Maybe, but that's a different problem.  We should not be adding to it.

> >> It’s not intended to be “surreptitious” or “hidden” or anything
> >> like that, ....
> > That may be the case, but it _seems_ very much like it.  If the
> > intention had actually been to be surreptitious, what more could
> > have been done than was actually done?

> Lots. We discussed and rejected more-“surreptitious” options back before 
> this stuff was installed. For example, we discussed changing ‘format’ to 
> behave like ‘format-message’ does now.

In effect, that's what was actually done.  `format-message' was
introduced and `message' was switched unconditionally to use it, despite
the serious problems this was bound to cause.

Let me summarise the current state of the discussion.  I have proposed
restoring message's property of every format specifier starting with %,
with every character which isn't % being a literal character.  Two new
format specifiers would be introduced, %` and %' to indicate the
substitution by the user's preferred version of left and right single

This would render format strings containing these new specifiers
unusable on Older Emacsen.  This would be worked around by providing
advice to message, to be applied by external packages using the new

There would be a significant amount of work amending format strings
which currently use ` and ' to use %` and %'.

I think the topic has been pretty thoroughly discussed.  Are there any
objections remaining to me implementing this change and committing it to

Alan Mackenzie (Nuremberg, Germany).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]