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

[Alan Mackenzie]

Hello, Paul.

On Wed, Jun 07, 2017 at 16:28:28 -0700, Paul Eggert wrote:
> On 06/07/2017 12:13 PM, Alan Mackenzie wrote:
> > What I am arguing against is being required to use _two_ format 
> > strings in one message invocation, as (message "%s" (format "..." ...)).

> We could address this problem by defining a new function (‘memo’, say), 
> that acts like ‘message’ except that it takes just one argument and does 
> no format processing. That way, instead of writing (message "%s" (format 
> FMT A B C)), one could write (memo (format FMT A B C)), thus avoiding 
> the need for two format strings.

YUCK!  So we'd have both message and memo doing basically the same
thing, with different interfaces.  Better to make them have the same
interface.  In that case, you've got two functions which are so close to
eachother, one single function would be better.....

> > _Nobody_ will have the slightest difficulty with % in message, because 
> > it stands out visually.

> I don’t see what “standing out visually” has to do it. If one naively 
> expects (message "30%-50% done") to display "30%-50% done", one will be 
> surprised/disappointed/angry/whatever when Emacs displays only "30% done".

NOBODY will write (message "30%-50% done").  They'll be writing (message
"%s%-%s% done" low high), where low is 30 and high is 50.  The
contradiction in the % is then obvious, and they can correct their
mistaken % (both of them) to %%.

> > It may be documented, but it's still surreptitious.  It seems
> > intended by its writer to be as hidden as possible

> 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?  There are also other things which
reinforce this appearance of surreptition.  They should also be fixed.

> .... and we should fix any part of the documentation that suggests
> otherwise. It would be helpful to point out any specific parts of the
> documentation needing improvement in this area.

The documentation is fine.  It's the design and coding which suggest
the surreptition, and it is the design and coding which need fixing.

-- 
Alan Mackenzie (Nuremberg, Germany).