[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: Tue, 3 May 2016 16:27:16 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Eli.

On Tue, May 03, 2016 at 06:38:16PM +0300, Eli Zaretskii wrote:
> > Date: Mon, 2 May 2016 19:10:31 +0000
> > From: Alan Mackenzie <address@hidden>
> > Cc: address@hidden

> > Hello, Paul.

> Hello, Alan.

[ .... ]

> > On Mon, May 02, 2016 at 10:53:59AM -0700, Paul Eggert wrote:
> > > (message "%s" M) is the usual way to output a message M without 
> > > formatting it, and something like this is needed anyway if M might 
> > > contain %.

> > That is the case for a string that might contain percent characters.  It
> > is not the case for a string known to be without percents.

> It is now.  In general, the first argument of 'message' is not copied
> to output verbatim, so the advice to use "%s" is a sound one.
> Especially when you are going to display a string that is produced
> dynamically, and so you don't have complete control on the result.
> It's simply dangerous.  We just got one more use case in support of
> that advice.

> > There was nothing wrong with `c-replay-parse-state-state'; it used
> > `message' as documented.  Your change implies that your workaround for
> > `message''s problems is instead to write something like:

> >     (message "%s" (format "......." .....))

> > , which is ridiculous.

> I don't see it as ridiculous.  You'd have similar problems (and use
> the same solution) if the string produced by 'format' included %
> characters, right?

I suppose so.  Have you got anything agains me putting that suggestion
into etc/NEWS, in the entry for `message'?

> >      In a format string containing single quotes, curved quotes `like
> >      this' and grave quotes `like this' work better than straight
> >      quotes 'like this', as `message' typically formats every straight
> >      quote as a curved closing quote.
> > [...]
> > Why is there no clear definition of what is meant by the confusing terms
> > "single quotes", "grave quotes", and "straight quotes"?

> Not sure what you mean: AFAICT, the definition is right there in the
> text you cited.

Only in the form of characters I can't distinguish on my terminal, and
couldn't even if they were distinct due to my failing eyesight ;-).  And
not in the form I would need to be able to program with them, such as
their ASCII/UTF-8 codes.

> > Why is there no mention of `text-quoting-style' on this page?

> Because we don't want to advertise it too much.  It is supposed to be
> a kind of "fire escape", not something users must routinely do.  If
> that assumption is wrong, then having this prominently mentioned in
> the manual will be the least of our troubles.

If I need to output source code using `message', I will need to bind
`text-quoting-style' to a sensible value, won't I?  That is an argument
for full documentation of it.  And why is it something that users
shouldn't routinely do?  Surely it should be a configuration variable.
Some people, like me, don't like being lied to by a computer program.

> > How do I configure my Emacs so that `message' behaves properly?

> I urge you not to do that.  Because if you do, problems like this one
> will slip unnoticed, instead of being fixed in the code.

I'd like it to be fixed in the code.  :-)

> > Properly, for me, means that it handles percent escape sequences, AND
> > OTHERWISE LEAVES THE STRING UNCHANGED.  Why is this information not in
> > the manual and the doc string?

> AFAICT, 'grave' is that value.  And it is documented.

No, `grave' doesn't work.  This changes curly quotes to ASCII quotes, i.e.
it distorts the input and loses information.  The value wanted, let's
call it `leave', would suppress all substitution of quotes.

> > > and the quoting change in Emacs 25 is documented in etc/NEWS, so it is 
> > > not a bug per se.

> > Why is it not in the section "incompatible Lisp changes"?

> Because it isn't.  If this is an incompatible change, then every new
> features that changes behavior is also an incompatible change.

No.  This particular change causes previously working lisp code (such as
my function from yesterday) to stop working.

> > How do I restore the old behaviour of `message'?

> By setting text-quoting-style.  But again, please don't.

I want my Emacs to deliver messages to me as they were intended by the
people who wrote them.  I have a visceral disgust of and hate for this
distortion of strings caused by this translation of quotes.  I'm sure I'm
not the only person who feels like this (and indeed, there were
snide/sarcastic remarks on this list yesterday in my support).  I want to
configure my Emacs to work right for me.  I don't understand why this
isn't intended to be configurable.

> > Can we please fix this before Emacs 25.1 gets released?

> What fix would you like to see?  I'm not sure I understand.

I want there to be an additional value `leave' for `text-quoting-style'
which would suppress all substitution of quotes.  Something like this:

diff --git a/lisp/help-fns.el b/lisp/help-fns.el
index 6e8a108..b5a2c84 100644
--- a/lisp/help-fns.el
+++ b/lisp/help-fns.el
@@ -626,7 +626,7 @@ describe-function-1
             ;; Avoid asking the user annoying questions if she decides
             ;; to save the help buffer, when her locale's codeset
             ;; isn't UTF-8.
-            (unless (memq text-quoting-style '(straight grave))
+            (unless (memq text-quoting-style '(leave straight grave))
               (set-buffer-file-coding-system 'utf-8))))))))
 ;; Add defaults to `help-fns-describe-function-functions'.
diff --git a/src/doc.c b/src/doc.c
index 7cdb0d0..b858e64 100644
--- a/src/doc.c
+++ b/src/doc.c
@@ -704,6 +704,8 @@ text_quoting_style (void)
       ? default_to_grave_quoting_style ()
       : EQ (Vtext_quoting_style, Qgrave))
+  else if (EQ (Vtext_quoting_style, Qleave))
   else if (EQ (Vtext_quoting_style, Qstraight))
@@ -988,7 +990,8 @@ Otherwise, return a new string.  */)
          int ch = STRING_CHAR_AND_LENGTH (strp, len);
          if ((ch == LEFT_SINGLE_QUOTATION_MARK
               || ch == RIGHT_SINGLE_QUOTATION_MARK)
-             && quoting_style != CURVE_QUOTING_STYLE)
+             && quoting_style != CURVE_QUOTING_STYLE
+              && quoting_style != LEAVE_QUOTING_STYLE)
              *bufp++ = ((ch == LEFT_SINGLE_QUOTATION_MARK
                          && quoting_style == GRAVE_QUOTING_STYLE)
@@ -1033,6 +1036,7 @@ void
 syms_of_doc (void)
   DEFSYM (Qfunction_documentation, "function-documentation");
+  DEFSYM (Qleave, "leave");
   DEFSYM (Qgrave, "grave");
   DEFSYM (Qstraight, "straight");
@@ -1046,7 +1050,11 @@ syms_of_doc (void)
   DEFVAR_LISP ("text-quoting-style", Vtext_quoting_style,
                doc: /* Style to use for single quotes in help and messages.
-Its value should be a symbol.
+Its value should be a symbol.  It works by substituting certain single
+quotes for certain other single quotes.  This is done in help output and
+`message' output.  It is not done in `format'.
+`leave' means do not do any substitutions.
 `curve' means quote with curved single quotes \\=‘like this\\=’.
 `straight' means quote with straight apostrophes \\='like this\\='.
 `grave' means quote with grave accent and apostrophe \\=`like this\\='.
diff --git a/src/editfns.c b/src/editfns.c
index f0ce4e7..415d3c3 100644
--- a/src/editfns.c
+++ b/src/editfns.c
@@ -3923,6 +3923,8 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args, bool 
       multibyte = true;
   int quoting_style = message ? text_quoting_style () : -1;
+  if (quoting_style == LEAVE_QUOTING_STYLE)
+    quoting_style = -1;
   /* If we start out planning a unibyte result,
      then discover it has to be multibyte, we jump back to retry.  */
diff --git a/src/lisp.h b/src/lisp.h
index 6a98adb..6a53671 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -4183,6 +4183,9 @@ extern void syms_of_callproc (void);
 /* Defined in doc.c.  */
 enum text_quoting_style
+    /* Leave quotes unchanged.  */
     /* Use curved single quotes ‘like this’.  */

> Thanks.

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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