GNU bug report logs -
#23425
master branch: `message' wrongly corrupts ' to curly quote.
Previous Next
Reported by: Alan Mackenzie <acm <at> muc.de>
Date: Mon, 2 May 2016 15:26:02 UTC
Severity: normal
Tags: notabug, wontfix
Done: Glenn Morris <rgm <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23425 in the body.
You can then email your comments to 23425 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Mon, 02 May 2016 15:26:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Alan Mackenzie <acm <at> muc.de>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 02 May 2016 15:26:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello, Emacs.
In the following function:
(defun replay-parse-state-state ()
(message
(concat "(setq "
(mapconcat
(lambda (arg)
(format "%s %s%s" (car arg)
(if (atom (cdr arg)) "" "'") <==================
(if (markerp (cdr arg))
(format "(copy-marker %s)" (marker-position (cdr arg)))
(cdr arg))))
c-parse-state-state " ")
")")))
, the quote mark on the marked line is an ASCII quote, 0x27. When this
function runs in the Emacs master branch under X-Windows, the output of
this quote gets corrupted into a curly quote, as follows:
|
v
(setq c-state-cache ’((32429 . 33731) 795 365) c-state-cache-good-pos
33731 c-state-nonlit-pos-cache ’(53334 50334 47334 44334 41334 38334
35334 32334 29099 26099 23099 20099 17099 13993 10731 7641)
c-state-nonlit-pos-cache-limit 53334 c-state-semi-nonlit-pos-cache
’(32334 29099 26099 23099 20099 17099 13993 10731 7641)
c-state-semi-nonlit-pos-cache-limit 32334 c-state-brace-pair-desert nil
c-state-point-min 1 c-state-point-min-lit-type nil
c-state-point-min-lit-start nil c-state-min-scan-pos 1
c-state-old-cpp-beg nil c-state-old-cpp-end nil c-parse-state-point
33733)
When this output is fed back into Emacs with M-:, it produces an obscure
error message.
This has wasted a lot of time identifying the problem, and fruitlessly
searching for a solution in the Emacs and Elisp manuals, etc.
This is a bug. If a constant ASCII quote is presented to `message' or
`format', it should be processed as such. This bug might exist in the
emacs-25 branch, too. If so, could it be corrected there too, please,
before the release?
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Mon, 02 May 2016 16:26:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Alan Mackenzie <acm <at> muc.de> writes:
> This has wasted a lot of time identifying the problem, and fruitlessly
> searching for a solution in the Emacs and Elisp manuals, etc.
Wow. That's pretty egregious:
(message "'foo'")
=> "’foo’"
It's part of Paul grand War On Quotes, I guess. I think this part
should be reverted, at least.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Mon, 02 May 2016 16:42:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> > This has wasted a lot of time identifying the problem, and fruitlessly
> > searching for a solution in the Emacs and Elisp manuals, etc.
>
> Wow. That's pretty egregious: (message "'foo'") => "'foo'"
>
> It's part of Paul grand War On Quotes, I guess. I think this part
> should be reverted, at least.
You mean you don't find the improvement more beautiful? Luddite! ;-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Mon, 02 May 2016 17:55:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 23425 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
(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 %. Accordingly, I installed the attached patch into the emacs-25
branch and merged the result to master. I had already adjusted some
other instances of calls to ‘message’ (to fix problems with % as well as
with quotes) but missed this call; sorry about that.
The behavior of ‘message’ is documented in the manual, in doc strings,
and the quoting change in Emacs 25 is documented in etc/NEWS, so it is
not a bug per se.
[0001-Fix-quoting-problem-in-cc-engine-debug-message.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Mon, 02 May 2016 19:40:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, Paul.
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.
> Accordingly, I installed the attached patch into the emacs-25
> branch and merged the result to master.
That is merely tinkering with the symptoms of the problem. The actual
problem is that `message' corrupts strings.
> I had already adjusted some other instances of calls to ‘message’ (to
> fix problems with % as well as with quotes) but missed this call;
> sorry about that.
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.
> The behavior of ‘message’ is documented in the manual, in doc strings,
It is not. There is no mention of its corruption of quotes in
`messages''s doc string. In the Elisp manual there is just the
following obscure, and somewhat patronising, paragraph:
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.
Curved quotes do not "work better" than straight quotes, as my
experience this afternoon demonstrates. Why are readers insulted with
"formats"? There is no "formatting" going on here; instead some
characters are being expunged, and substituted by other characters. Why
is the most important idea in that paragraph, this substitution, slid in
as though it was a totally natural thing to do, scarcely worth a
mention?
Why is there no clear definition of what is meant by the confusing terms
"single quotes", "grave quotes", and "straight quotes"?
It appears to me that these substitutions are only done on pairs of
quote marks, not single quotes. If I'm right, why is this not
documented?
Why is there no mention of `text-quoting-style' on this page?
How do I configure my Emacs so that `message' behaves properly?
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?
> 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"?
How do I restore the old behaviour of `message'? This information
surely belongs in etc/NEWS. As far as I can make out, there is no
setting of `text-quoting-style' equivalent to "do nothing". Why not?
Not everybody want to "text-quote".
Over the months, I've lost a ridiculously large amount of time to these
curly quotes. I never want to see them again (even though I'm forced to
in precompiled info files). Please document how to expunge them.
Can we please fix this before Emacs 25.1 gets released? Otherwise these
problems will impact LOTS of users.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 03 May 2016 15:19:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 23425 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 05/02/2016 12:10 PM, Alan Mackenzie 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.
Sure, but the most common problem here is using (message M) to output an
arbitrary string M that is under user control, which is why the advice
about (message "%s" M) is helpful. This advice works for all format
directives, not just % directives.
> There is no mention of its corruption of quotes in
> `messages''s doc string.
Thanks, good point. I fixed it by installing the attached patch, which
should address the other documentation problems you mention too.
> It appears to me that these substitutions are only done on pairs of
> quote marks, not single quotes.
What gives you that impression? Substitutions are done on all quotes,
not just paired quotes.
> Properly, for me, means that it handles percent escape sequences, AND
> OTHERWISE LEAVES THE STRING UNCHANGED.
This alternative was considered when designing text-quoting-style, but
at the time we didn't see a need for the extra complexity. The
particular glitch you ran into is not a strong argument for revisiting
this now.
> Why is it not in the section "incompatible Lisp changes"?
It is in that section, under "** New variable 'text-quoting-style' ...".
[0001-Doc-fixes-for-quoting.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 03 May 2016 15:39:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 2 May 2016 19:10:31 +0000
> From: Alan Mackenzie <acm <at> muc.de>
> Cc: 23425 <at> debbugs.gnu.org
>
> Hello, Paul.
Hello, Alan.
First, I understand your frustration, and I'm sorry you lost time over
this issue. This happens sometimes when new developments go against
our muscle memory.
Having said that...
> 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?
> 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.
> 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.
> 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.
> 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.
> > 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.
> How do I restore the old behaviour of `message'?
By setting text-quoting-style. But again, please don't.
> Can we please fix this before Emacs 25.1 gets released?
What fix would you like to see? I'm not sure I understand.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 03 May 2016 16:28:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 23425 <at> debbugs.gnu.org (full text, mbox):
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 <acm <at> muc.de>
> > Cc: 23425 <at> debbugs.gnu.org
> > 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))
return GRAVE_QUOTING_STYLE;
+ else if (EQ (Vtext_quoting_style, Qleave))
+ return LEAVE_QUOTING_STYLE;
else if (EQ (Vtext_quoting_style, Qstraight))
return STRAIGHT_QUOTING_STYLE;
else
@@ -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 message)
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. */
+ LEAVE_QUOTING_STYLE,
+
/* Use curved single quotes ‘like this’. */
CURVE_QUOTING_STYLE,
> Thanks.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 03 May 2016 16:37:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> we didn't see a need for the extra complexity
Talk about the tail wagging the dog! This whole quote-beautification
crusade (yes, the term is appropriate) has been a huge boatload of
extra complexity. And it's not even clear that we've seen the end of it.
Sure, I know the mantra: "That ship has already sailed" ("Shut up and color").
This particular ship is a gigantic barge of sludge, and it seems it's
trying to plod through ice fields. Global warming to the rescue?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 03 May 2016 16:57:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 3 May 2016 16:27:16 +0000
> Cc: eggert <at> cs.ucla.edu, 23425 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
>
> > > (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'?
No, I have nothing against that.
> > > 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.
Well, a picture is worth about a thousand words. I very much doubt
one could explain that clearly enough, if we assume the characters are
not displayed correctly and that the user isn't already familiar with
the terminology. How do you "define" character by just talking about
them, without showing their glyphs??
> > > 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?
No, you just need to use "%s" as the first argument, that's all.
> And why is it something that users shouldn't routinely do?
Because the theory behind this change is that everyone will want that,
certainly after they get used to it a little. If that theory is
wrong, we will have to change much more than just document that
variable or teach users to use it more.
> Surely it should be a configuration variable. Some people, like me,
> don't like being lied to by a computer program.
You are not being lied to. Just think of ` and ' as yet another
format specifier character, not unlike %.
> > > 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. :-)
You mean, disable the conversion? Not going to happen before 25.1,
and unless there's a user outcry, not going to happen, period.
That's why I think we should use the default, and find and fix any
leftovers like the one which started this discussion.
> > > 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.
??? Are we talking about the same issue?
emacs -Q
M-: (setq text-quoting-style 'grave) RET
M-: (message "`this'") RET => `this'
What am I missing?
> > > 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.
Like any other change can.
> > > 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).
You are not just anyone. You are a core developer and a maintainer of
several important packages. That is a responsibility that places an
onus on us to "suffer" a little so that bugs will be detected and
fixed sooner rather than latter. In general, developers should try
using as many defaults as they can, for that very reason -- to see the
problems that users will as soon as possible.
If you still don't want that, I cannot force you. It's just that
there's so few of us that every single one counts.
> > > 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.
See above: I'm missing something here, because I don't understand why
is that needed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 03 May 2016 17:00:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 3 May 2016 09:36:10 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 23425 <at> debbugs.gnu.org
>
> > we didn't see a need for the extra complexity
>
> Talk about the tail wagging the dog! This whole quote-beautification
> crusade (yes, the term is appropriate) has been a huge boatload of
> extra complexity. And it's not even clear that we've seen the end of it.
>
> Sure, I know the mantra: "That ship has already sailed" ("Shut up and color").
>
> This particular ship is a gigantic barge of sludge, and it seems it's
> trying to plod through ice fields. Global warming to the rescue?
Please drop the attitude. This isn't helping a bit. It does waste
precious time and bandwidth.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 03 May 2016 20:04:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, Eli.
On Tue, May 03, 2016 at 07:55:45PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 3 May 2016 16:27:16 +0000
> > Cc: eggert <at> cs.ucla.edu, 23425 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>
> > I suppose so. Have you got anything agains me putting that
> > suggestion [ the trick of using `format' inside `message] into
> > etc/NEWS, in the entry for `message'?
> No, I have nothing against that.
OK, I'll do that later.
> > > 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.
> Well, a picture is worth about a thousand words. I very much doubt
> one could explain that clearly enough, if we assume the characters are
> not displayed correctly and that the user isn't already familiar with
> the terminology. How do you "define" character by just talking about
> them, without showing their glyphs??
This isn't simple. I think what's needed is a clear explanation of the
conversion process, not merely the result of using it - I'm still a
little confused over whether a left ASCII quote (`) might get converted
into a right ASCII or curly quote. (A little later - yes it can happen)
I don't think that is clearly documented anywhere.
> > > > 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.
> > And why is it something that users shouldn't routinely do?
> Because the theory behind this change is that everyone will want that,
> certainly after they get used to it a little.
That seems a very strange attitude from an Emacs developer - that one
developer's personal preferences should be imposed on all Emacs users
without the possibility of disabling by configuration.
It is quite clear from posts in emacs-devel and bug-gnu-emacs over the
last year or so that NOT EVERYBODY wants these curly quote changes. Far
from it. Just like not everybody wants light text on a dark background,
or (thinking back to Emacs 21) not everybody wants fringes on their GUI
screen. Users were complaining for years about the unconfigurable
fringes, until Emacs 22 was released.
> If that theory is wrong, we will have to change much more than just
> document that variable or teach users to use it more.
That theory _is_ wrong, certainly amongst Emacs developers. Even in this
bug thread, two other people have expressed negative sentiments about
this matter.
> > Surely it should be a configuration variable. Some people, like me,
> > don't like being lied to by a computer program.
> You are not being lied to. Just think of ` and ' as yet another
> format specifier character, not unlike %.
They're not - they're literal characters. The quote which should have
been output yesterday afternoon, but got corrupted, was certainly a
literal quote.
> > > 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. :-)
> You mean, disable the conversion? Not going to happen before 25.1,
> and unless there's a user outcry, not going to happen, period.
No, I mean make this conversion optional and configurable, as in the
patch in my last post.
> That's why I think we should use the default, and find and fix any
> leftovers like the one which started this discussion.
This particular default just makes me too angry to get work done. I'm
still using 24.5. After becoming tired out in the fight over curly
quotes last summer/autumn, I just left that task to other people. I
assumed that the matter of curly quotes had been sorted out
satisfactorally.
[ .... ]
> > No, `grave' doesn't work. This changes curly quotes to ASCII quotes, i.e.
> > it distorts the input and loses information.
> ??? Are we talking about the same issue?
> emacs -Q
> M-: (setq text-quoting-style 'grave) RET
> M-: (message "`this'") RET => `this'
> What am I missing?
That in that scenario, (message "`this'") ; with curly quotes
gets converted to "`this'" ; with ASCII quotes. This is not wanted.
[ .... ]
> > > > 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.
> See above: I'm missing something here, because I don't understand why
> is that needed.
Backwards compatibility, perhaps?
Another reason is the difficulty of discovering from the available
documentation, which is not concise and coherent[*], precisely what the
quote substitution does. At least on disabling the substitution, you
know where you stand.
[*] There is nowhere any text like "when `message' runs, it subtitutes
ASCII and curly quotes as follow: ....".
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 03 May 2016 20:50:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 23425 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 05/03/2016 01:03 PM, Alan Mackenzie wrote:
> On Tue, May 03, 2016 at 07:55:45PM +0300, Eli Zaretskii wrote:
>> No, I have nothing against that.
> OK, I'll do that later.
I gave this a shot by installing the attached; please feel free to
improve it.
> I'm still a
> little confused over whether a left ASCII quote (`) might get converted
> into a right ASCII or curly quote.
Grave accent (`) might be left alone or converted to apostrophe (') or
converted to left single quotation mark (‘), depending on whether
text-quoting-style is ‘grave’, ‘straight’, or ‘curve’, respectively.
Grave accent is never converted to right single quotation mark (’).
> I mean make this conversion optional and configurable, as in the
> patch in my last post.
This conversion already configurable, in the sense that one can use
either (setq text-quoting-style 'grave) or (setq text-quoting-style
'straight) to get behavior that would have worked for the use case that
prompted this bug report. I haven't seen a realistic use case to
motivate the proposed extra complexity of another configuration option here.
> I don't think that is clearly documented anywhere.
The current version of the documentation says the following. If this is
not clear enough, we should improve it so that it is clear.
@item ‘
@itemx `
(left single quotation mark and grave accent) both stand for a left quote.
This generates a left single quotation mark, an apostrophe, or a grave
accent depending on the value of @code{text-quoting-style}.
@item ’
@itemx '
(right single quotation mark and apostrophe) both stand for a right quote.
This generates a right single quotation mark or an apostrophe
depending on the value of @code{text-quoting-style}.
...
@defvar text-quoting-style
@cindex curved quotes
@cindex curly quotes
The value of this variable is a symbol that specifies the style Emacs
should use for single quotes in the wording of help and messages.
If the variable's value is @code{curve}, the style is
@t{‘like this’} with curved single quotes. If the value is
@code{straight}, the style is @t{'like this'} with straight
apostrophes. If the value is @code{grave}, the style is @t{`like
this'} with grave accent and apostrophe, the standard style
before Emacs version 25. The default value @code{nil}
acts like @code{curve} if curved single quotes are displayable, and
like @code{grave} otherwise.
[0001-etc-NEWS-Mention-message-s-format.patch (application/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 15:34:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 3 May 2016 20:03:30 +0000
> Cc: eggert <at> cs.ucla.edu, 23425 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
>
> > > And why is it something that users shouldn't routinely do?
>
> > Because the theory behind this change is that everyone will want that,
> > certainly after they get used to it a little.
>
> That seems a very strange attitude from an Emacs developer - that one
> developer's personal preferences should be imposed on all Emacs users
> without the possibility of disabling by configuration.
>
> It is quite clear from posts in emacs-devel and bug-gnu-emacs over the
> last year or so that NOT EVERYBODY wants these curly quote changes. Far
> from it. Just like not everybody wants light text on a dark background,
> or (thinking back to Emacs 21) not everybody wants fringes on their GUI
> screen. Users were complaining for years about the unconfigurable
> fringes, until Emacs 22 was released.
This is unfair on so many levels, that I simply lost any motivation to
continue this discussion.
> > If that theory is wrong, we will have to change much more than just
> > document that variable or teach users to use it more.
>
> That theory _is_ wrong, certainly amongst Emacs developers. Even in this
> bug thread, two other people have expressed negative sentiments about
> this matter.
So we have 3 people against that. Is it really enough?
> > > Surely it should be a configuration variable. Some people, like me,
> > > don't like being lied to by a computer program.
>
> > You are not being lied to. Just think of ` and ' as yet another
> > format specifier character, not unlike %.
>
> They're not - they're literal characters.
So is %.
> > emacs -Q
> > M-: (setq text-quoting-style 'grave) RET
> > M-: (message "`this'") RET => `this'
>
> > What am I missing?
>
> That in that scenario, (message "`this'") ; with curly quotes
> gets converted to "`this'" ; with ASCII quotes. This is not wanted.
Not sure why. But anyway, the change such as what you suggest is too
pervasive to install on the emacs-25 branch, unless we want to delay
the release. Too bad these issues didn't come up in time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 16:49:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, Eli.
On Wed, May 04, 2016 at 06:32:40PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 3 May 2016 20:03:30 +0000
> > Cc: eggert <at> cs.ucla.edu, 23425 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>
> > > > And why is it something that users shouldn't routinely do?
> > > Because the theory behind this change is that everyone will want that,
> > > certainly after they get used to it a little.
[ .... ]
> > > If that theory is wrong, we will have to change much more than just
> > > document that variable or teach users to use it more.
> > That theory _is_ wrong, certainly amongst Emacs developers. Even in this
> > bug thread, two other people have expressed negative sentiments about
> > this matter.
> So we have 3 people against that. Is it really enough?
That's three people in this thread. Over the months, more people have
expressed unhappinness about curly quotes, in the various ways they have
been imposed on us. Yes, I think that is enough. The comments from the
other two people have been less than fully respectful, and at least one
of them is not known for making snide remarks. What does that tell you?
Put frankly, the curly quote stuff was installed into Emacs without there
being any consensus in favour of it, and was deliberately done in such a
way that it could not be disabled (see below).
> > > > Surely it should be a configuration variable. Some people, like me,
> > > > don't like being lied to by a computer program.
> > > You are not being lied to. Just think of ` and ' as yet another
> > > format specifier character, not unlike %.
> > They're not - they're literal characters.
> So is %.
You can escape a % by writing %%. That will consistently be output as %.
There is no comparable form of escape for the quote characters.
> > > emacs -Q
> > > M-: (setq text-quoting-style 'grave) RET
> > > M-: (message "`this'") RET => `this'
> > > What am I missing?
> > That in that scenario, (message "`this'") ; with curly quotes
> > gets converted to "`this'" ; with ASCII quotes. This is not wanted.
> Not sure why. But anyway, the change such as what you suggest is too
> pervasive to install on the emacs-25 branch, unless we want to delay
> the release. Too bad these issues didn't come up in time.
I brought this matter up in June 2015, immediately after mandatory
mangling of quotes was introduced. I installed a patch
(52c3946c872c8bd96508f74cdda5cbb90c664306, on 2015-06-18) to make this
mangling optional. The very next day, you-know-who effectively reverted
this change, under the guise of expanding the choice available, making
the mangling mandatory again. I should have fought the issue at the
time, but didn't.
If it is too late to go into 25.1, can we put a fix into 25.2? And yet
again, I suggest `text-quoting-style' should become a configurable
option, giving users the ability to chose how THEY want messages to be
displayed.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 17:04:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 4 May 2016 16:48:49 +0000
> Cc: eggert <at> cs.ucla.edu, 23425 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
>
> > > That theory _is_ wrong, certainly amongst Emacs developers. Even in this
> > > bug thread, two other people have expressed negative sentiments about
> > > this matter.
>
> > So we have 3 people against that. Is it really enough?
>
> That's three people in this thread. Over the months, more people have
> expressed unhappinness about curly quotes, in the various ways they have
> been imposed on us. Yes, I think that is enough.
I don't. Please let's wait until 25.1 is released, the only way to
change this decision is if we see a lot of complaints about this.
> The comments from the other two people have been less than fully
> respectful, and at least one of them is not known for making snide
> remarks. What does that tell you?
That some people don't like this. But we knew that back when it was
decided to have this feature.
> Put frankly, the curly quote stuff was installed into Emacs without there
> being any consensus in favour of it, and was deliberately done in such a
> way that it could not be disabled (see below).
Not true. If there were no consensus, at least not a wide enough one,
this wouldn't have been admitted. The objections were not numerous
enough and strong enough to prevent these changes.
> > > They're not - they're literal characters.
>
> > So is %.
>
> You can escape a % by writing %%. That will consistently be output as %.
> There is no comparable form of escape for the quote characters.
Yes, there is: use "%s" as the first argument to 'message'. Which is
a Good Thing anyway, as we all know.
> If it is too late to go into 25.1, can we put a fix into 25.2?
I see no reason not to install a change along these lines on master,
if the new value is not the default.
> And yet again, I suggest `text-quoting-style' should become a
> configurable option, giving users the ability to chose how THEY want
> messages to be displayed.
And I yet again urge you to wait until 25.1 hits the streets, and we
see what the Emacs community at large thinks about this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 17:38:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On Wed, May 4, 2016 at 10:03 AM, Eli Zaretskii wrote:
>> > > That theory _is_ wrong, certainly amongst Emacs developers. Even in this
>> > > bug thread, two other people have expressed negative sentiments about
>> > > this matter.
>>
>> > So we have 3 people against that. Is it really enough?
>>
>> That's three people in this thread. Over the months, more people have
>> expressed unhappinness about curly quotes, in the various ways they have
>> been imposed on us. Yes, I think that is enough.
>
> I don't. Please let's wait until 25.1 is released, the only way to
> change this decision is if we see a lot of complaints about this.
And how do you expect to receive that feedback? Through bug reports?
Can I file mine now instead of waiting for the release of 25.1?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 18:05:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, Eli.
On Wed, May 04, 2016 at 08:03:43PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 4 May 2016 16:48:49 +0000
> > Cc: eggert <at> cs.ucla.edu, 23425 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>
> > > > That theory _is_ wrong, certainly amongst Emacs developers. Even in this
> > > > bug thread, two other people have expressed negative sentiments about
> > > > this matter.
> > > So we have 3 people against that. Is it really enough?
> > That's three people in this thread. Over the months, more people have
> > expressed unhappinness about curly quotes, in the various ways they have
> > been imposed on us. Yes, I think that is enough.
> I don't. Please let's wait until 25.1 is released, the only way to
> change this decision is if we see a lot of complaints about this.
There won't be lots of complaints about this. There will be a few people
who notice, and some of them will utterly hate it, just as I do. Some
will have their Lisp rendered unworkable, just as happened to me. There
are thousands of options in Emacs, and most users care about only a small
subset (although the subset is different for each user). You could
remove any option, no matter how "important", and you'd get only a small
number of complaints. This doesn't seem to me like the way to judge
things.
> > The comments from the other two people have been less than fully
> > respectful, and at least one of them is not known for making snide
> > remarks. What does that tell you?
> That some people don't like this. But we knew that back when it was
> decided to have this feature.
And when was this decision taken? The answer is it wasn't. Despite the
great opposition to it, Paul plowed ahead with several varied schemes for
curly quotes, not waiting for consensus first, and in the end, people
just got tired of opposing him.
> > Put frankly, the curly quote stuff was installed into Emacs without there
> > being any consensus in favour of it, and was deliberately done in such a
> > way that it could not be disabled (see below).
> Not true. If there were no consensus, at least not a wide enough one,
> this wouldn't have been admitted.
That's not the way the Emacs project works. Most contributors work on a
cooperative basis and first discuss contentious things and abide by
understandings reached. You and I certainly do. That leaves us open to
abuse by aggressive committers, who don't abide by the above convention.
This is what happened with curly quotes. There is nobody in the project
who feels empowered to revert "premature" commits.
> The objections were not numerous enough and strong enough to prevent
> these changes.
The objections to curly quotes were extremely numerous (I've spent some
time today looking at old threads), and support for them was sparse.
[ .... ]
> > If it is too late to go into 25.1, can we put a fix into 25.2?
> I see no reason not to install a change along these lines on master,
> if the new value is not the default.
We'll see what we can manage.
> > And yet again, I suggest `text-quoting-style' should become a
> > configurable option, giving users the ability to chose how THEY want
> > messages to be displayed.
> And I yet again urge you to wait until 25.1 hits the streets, and we
> see what the Emacs community at large thinks about this.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 18:40:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 05/04/2016 11:04 AM, Alan Mackenzie wrote:
> Despite the
> great opposition to it, Paul plowed ahead with several varied schemes for
> curly quotes, not waiting for consensus first,
This misrepresents what happened. I proposed a scheme, got feedback,
altered the proposal in response to the feedback, gained general (though
not universal) agreement, and got an OK from the maintainer before
committing the change. The installed scheme differs quite a bit from my
personal preference. Like most compromises it's easy for each of us to
find something we dislike about it.
I plan to look into the further change you proposed, with an eye toward
installing something like it (but I hope simpler) in the master branch.
It's a bit late to be fiddling with this sort of thing in the emacs-25
branch, though.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 18:48:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 23425 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>>>> Alan Mackenzie <acm <at> muc.de> writes:
> There won't be lots of complaints about this. There will be a few people who
> notice, and some of them will utterly hate it, just as I do. Some will have
> their Lisp rendered unworkable, just as happened to me. There are thousands
> of options in Emacs, and most users care about only a small subset (although
> the subset is different for each user). You could remove any option, no
> matter how "important", and you'd get only a small number of complaints.
> This doesn't seem to me like the way to judge things.
Hi guys,
I appreciate the passion on this issue; I had a feeling this would come up,
and I think the reaction is going to be far more widespread than some expect.
As maintainer, I'll go on record by saying that I very much dislike the new
curly quotes logic. After the reactions I've read here, I'm convinced again
that a customization option needs to exist in 25.1, so we can easily recommend
it to people who react as Alan has done.
I realize it's harder to take away a defcustom than to promote a defvar, but
this is too much of a hot issue to wait an entire release for sufficient bug
reports to come in before we act. If we think this reaction is going to be
isolated to just a few developers here, I fear we've underestimated the global
capacity for bike-shedding: and nothing says bike-shedding better than a
purely aesthetic concern as minor as ' vs. ’.
In fact, I would like to rip all the curly-quote redisplay logic out of Emacs,
for several reasons:
1. It achieves nothing technically. Emacs is not a better editor because of
it in any objective way; it is purely an aesthetic change, desired only
by those who agree with its aesthetics.
2. It has caused numerous bugs already.
3. It has provoked heated debate many times already. The amount of time
lost on emacs-devel to this one issue is an absolute shame.
4. It changes Emacs according to the preferences of specific people, without
giving others -- in the very spirit of Emacs! -- an option to choose
one's desired behavior in the standard fashion.
At this point, I cannot undo this feature, since that would destabilize 25.1.
However, we must have an option to conveniently disable it before the release
happens. Of that I am now certain. Would someone be willing to craft a patch,
please?
Lastly, to play devil's advocate: I also recognize, after having written this,
that I'm something of an "old fogey" in Emacs terms, with a special place for
ASCII in my heart. It's quite possible that the new-and-coming generation is
very fond of Unicode, and they will all love this feature, since it gives
Emacs a more modern "feel". For their sake, I'm prepared to wait for the
world's judgment before deciding that this feature is entirely terrible.
But for the sake of my fellow dinosaurs, I need a way to turn it off! Please!
They are like tiny knives, stabbing at my mind with their Unicode edges; or a
plague of typeset locusts, foretelling the soon-to-come Apostroclypse.
I hope we can resolve this discussion with less ire, and more focus on what
will make 25.1 a better release. No one is ill-intended here. We just have
very different opinions on what looks nice.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 18:58:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, Paul.
On Wed, May 04, 2016 at 11:39:08AM -0700, Paul Eggert wrote:
> On 05/04/2016 11:04 AM, Alan Mackenzie wrote:
> > Despite the
> > great opposition to it, Paul plowed ahead with several varied schemes for
> > curly quotes, not waiting for consensus first,
> This misrepresents what happened.
You installed your contentious changes without prior discussion on
emacs-devel.
> I proposed a scheme, ....
By which you mean you installed your changes on the master branch.
> ... got feedback, altered the proposal in response to the feedback,
> gained general (though not universal) agreement, ....
It's a pity you didn't attempt to garner that agreement BEFORE
installing your changes. That might have saved a lot of bad feeling.
> and got an OK from the maintainer before committing the change. The
> installed scheme differs quite a bit from my personal preference. Like
> most compromises it's easy for each of us to find something we dislike
> about it.
You'll recall that at one point I installed a quick change to make the
translation of quotes optional. Your reaction, the very next day, was
to nullify my change, rendering your translations mandatory again.
> I plan to look into the further change you proposed, with an eye toward
> installing something like it (but I hope simpler) in the master branch.
> It's a bit late to be fiddling with this sort of thing in the emacs-25
> branch, though.
No, that won't do. By "something like it", you probably mean something
that leaves the translation mandatory. Only a facility which allows
total disablement will be adequate here. After discussion with Eli, I
intend to apply the patch I proposed yesterday, and I'd be much obliged
if this time you would allow its intention to survive.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 19:04:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 23425 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>>>> Alan Mackenzie <acm <at> muc.de> writes:
>> This misrepresents what happened.
> You installed your contentious changes without prior discussion on
> emacs-devel.
Please, do not let this bug devolve into an argument between volunteers. I
cannot conceive of a world in which Paul did any of this maliciously, nor am I
insensitive to your concerns, Alan.
Let's focus on what we're going to do about it now, not what we might have
done about it back then.
Thanks,
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 19:06:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 4 May 2016 10:37:33 -0700
> From: Josh <josh+gnu <at> nispio.net>
> Cc: Alan Mackenzie <acm <at> muc.de>, eggert <at> cs.ucla.edu, 23425 <at> debbugs.gnu.org
>
> > I don't. Please let's wait until 25.1 is released, the only way to
> > change this decision is if we see a lot of complaints about this.
>
> And how do you expect to receive that feedback? Through bug reports?
Yes. Also, through messages on help-gnu-emacs and here.
> Can I file mine now instead of waiting for the release of 25.1?
Yes, of course. But didn't you do that already? This is the bug
report about that very feature.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 19:10:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 4 May 2016 18:04:17 +0000
> Cc: eggert <at> cs.ucla.edu, 23425 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
>
> > I don't. Please let's wait until 25.1 is released, the only way to
> > change this decision is if we see a lot of complaints about this.
>
> There won't be lots of complaints about this. There will be a few people
> who notice, and some of them will utterly hate it, just as I do. Some
> will have their Lisp rendered unworkable, just as happened to me. There
> are thousands of options in Emacs, and most users care about only a small
> subset (although the subset is different for each user). You could
> remove any option, no matter how "important", and you'd get only a small
> number of complaints. This doesn't seem to me like the way to judge
> things.
I see no other way.
> > That some people don't like this. But we knew that back when it was
> > decided to have this feature.
>
> And when was this decision taken? The answer is it wasn't. Despite the
> great opposition to it, Paul plowed ahead with several varied schemes for
> curly quotes, not waiting for consensus first, and in the end, people
> just got tired of opposing him.
>
> > > Put frankly, the curly quote stuff was installed into Emacs without there
> > > being any consensus in favour of it, and was deliberately done in such a
> > > way that it could not be disabled (see below).
>
> > Not true. If there were no consensus, at least not a wide enough one,
> > this wouldn't have been admitted.
>
> That's not the way the Emacs project works. Most contributors work on a
> cooperative basis and first discuss contentious things and abide by
> understandings reached. You and I certainly do. That leaves us open to
> abuse by aggressive committers, who don't abide by the above convention.
> This is what happened with curly quotes. There is nobody in the project
> who feels empowered to revert "premature" commits.
That's not my recollection of how this happened. But the records are
all there, so anyone can re-read them and make up their own minds.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 20:24:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 05/04/2016 09:46 PM, John Wiegley wrote:
> As maintainer, I'll go on record by saying that I very much dislike the new
> curly quotes logic. After the reactions I've read here, I'm convinced again
> that a customization option needs to exist in 25.1, so we can easily recommend
> it to people who react as Alan has done.
This doesn't seem like a good idea to me.
If we add a custom option, doesn't that constitute a promise that the
curly quote translation *will* work for at least several releases of
Emacs after that?
Because the option would have a value meaning "translate straight quotes
to curlies", and we'll have to support it once the option is introduced.
> In fact, I would like to rip all the curly-quote redisplay logic out of Emacs,
> for several reasons:
I would too (though I wouldn't actually mind it if it were implemented
in a very different fashion). But this is a totally different direction
from "let's add a user option". I think.
> 3. It has provoked heated debate many times already. The amount of time
> lost on emacs-devel to this one issue is an absolute shame.
Word.
> 4. It changes Emacs according to the preferences of specific people, without
> giving others -- in the very spirit of Emacs! -- an option to choose
> one's desired behavior in the standard fashion.
>
> At this point, I cannot undo this feature, since that would destabilize 25.1.
Can we actually leave it in, while all but promising to take it out in
the next release?
That would seem like an odd choice.
> Lastly, to play devil's advocate: I also recognize, after having written this,
> that I'm something of an "old fogey" in Emacs terms, with a special place for
> ASCII in my heart. It's quite possible that the new-and-coming generation is
> very fond of Unicode, and they will all love this feature, since it gives
> Emacs a more modern "feel". For their sake, I'm prepared to wait for the
> world's judgment before deciding that this feature is entirely terrible.
As a member of a somewhat younger generation, I can say that they look
fine in Help buffers, manuals, and so on, although they do not look
"modern". The curly single quotes feel more like certain tech in
alternative history novels: shiny, could be considered cool in some very
specific circles, but nobody uses anything like that in the modern times.
I never want to see them in my source code, though, and the benefits,
whatever they are, do not justify the increased complexity in the
associated facilities.
> But for the sake of my fellow dinosaurs, I need a way to turn it off! Please!
> They are like tiny knives, stabbing at my mind with their Unicode edges; or a
> plague of typeset locusts, foretelling the soon-to-come Apostroclypse.
The problem with using the "don't translate at all" option is that it
allows you to write code that won't work for other users.
For instance, if we had such an option now, Alan wouldn't have found the
presently discussed bug. It wouldn't not manifest with his setup, but it
would manifest in default Emacs configuration where quote translation is
enabled, and the majority of the users would suffer.
For that reason only, I'm against having an option like that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 21:35:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 05/04/2016 11:57 AM, Alan Mackenzie wrote:
> By "something like it", you probably mean something
> that leaves the translation mandatory.
No, I mean something that avoids quote translation entirely, just in a
simpler way.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 21:50:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > > Surely it should be a configuration variable. Some people, like me,
>> > > don't like being lied to by a computer program.
>>
>> > You are not being lied to. Just think of ` and ' as yet another
>> > format specifier character, not unlike %.
>>
>> They're not - they're literal characters.
>
> So is %.
% has always been documented as being special. The only special
character. Adding more special characters is an incompatible change and
breaks existing uses.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 21:51:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 05/04/2016 11:57 AM, Alan Mackenzie wrote:
>> I proposed a scheme, ....
> By which you mean you installed your changes on the master branch.
>
No, I mean that I emailed patches to bug-gnu-emacs, which is the
documented way to suggest changes. There was a reasonably lengthy
discussion about the patches and I eventually installed into master a
patchset that was quite a bit different from what I originally proposed,
after getting an OK from Emacs's then-maintainer.
At the time I didn't think it was that big a deal: it's just quoting in
diagnostics, after all. With the benefit of hindsight I now see that I
was mistaken about how strongly some users are attached to quoting `like
this'. I am sorry you were not involved earlier, as that would likely
have saved us a lot of grief. I am also sorry about the whole
misunderstanding and will strive to publicize future changes on
emacs-devel more prominently, even changes that I may think are not that
important.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 22:07:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 23425 <at> debbugs.gnu.org (full text, mbox):
>>>>> Dmitry Gutov <dgutov <at> yandex.ru> writes:
> For instance, if we had such an option now, Alan wouldn't have found the
> presently discussed bug. It wouldn't not manifest with his setup, but it
> would manifest in default Emacs configuration where quote translation is
> enabled, and the majority of the users would suffer.
Hmm... these good arguments are getting in the way of my tirade.
Alright, I will let this go without a customization option, again. Alan, you
can setq `text-quoting-style' for now in your .emacs, although doing so may
get in the way of finding more bugs.
Let's see what the populace says, and how many pitchforks are raised. It's
quite possible we may revert this whole feature in 26, but let's get some
genuine public reaction before deciding the matter.
Within the Emacs developers, I now see strong votes against, some votes for
(are they as strong?), but I still don't know what the World At Large is going
to think.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 22:20:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 23425 <at> debbugs.gnu.org (full text, mbox):
"John Wiegley" <johnw <at> gnu.org> writes:
> Let's see what the populace says, and how many pitchforks are raised. It's
> quite possible we may revert this whole feature in 26, but let's get some
> genuine public reaction before deciding the matter.
Well, while I don't quite understand the whole "hatin' on quotes" thing,
I think Paul's arguments makes sense. But we should document this in a
forward-looking manner. We should say that Emacs in the future may do
random substitutions of characters in the first string of `message' and
`format', and that the only way to get things untranslated is this:
(format "%s" foo)
And, please, then stick to that, and not start doing at-our-whim
translations of the rest of the arguments. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 04 May 2016 23:50:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 23425 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 05/04/2016 11:39 AM, Paul Eggert wrote:
>
> I plan to look into the further change you proposed, with an eye
> toward installing something like it (but I hope simpler)
Attached is a proposed patch to master to do this. It disables
translation from curved quotes, which means that quote translation now
affects only ` and ', and it documents that the text-quoting-style
'grave' therefore suppresses all quote translation. This shortens the
Emacs source code by forty lines or so, which is a good sign.
[0001-text-quoting-style-now-affects-only-and.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Thu, 05 May 2016 07:13:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Well, while I don't quite understand the whole "hatin' on quotes" thing,
> I think Paul's arguments makes sense. But we should document this in a
> forward-looking manner. We should say that Emacs in the future may do
> random substitutions of characters in the first string of `message' and
> `format', and that the only way to get things untranslated is this:
>
> (format "%s" foo)
That makes it impossible to write format strings.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Thu, 05 May 2016 08:07:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, John.
On Wed, May 04, 2016 at 11:46:58AM -0700, John Wiegley wrote:
> Hi guys,
> I appreciate the passion on this issue; I had a feeling this would come up,
> and I think the reaction is going to be far more widespread than some expect.
> As maintainer, I'll go on record by saying that I very much dislike the new
> curly quotes logic. After the reactions I've read here, I'm convinced again
> that a customization option needs to exist in 25.1, so we can easily recommend
> it to people who react as Alan has done.
:-)
[ .... ]
> At this point, I cannot undo this feature [translation of single quotes
> in help messages and message format strings], since that would
> destabilize 25.1. However, we must have an option to conveniently
> disable it before the release happens. Of that I am now certain. Would
> someone be willing to craft a patch, please?
I committed 32f5bf0c29bbad6524f71079e4380b8156289551 to master last night
just before I read your post. It adds the value `leave' (as in "leave
alone and don't touch") to the set valid in `text-quoting-style'. This
might be what you're looking for, or serve as the basis for it.
`text-quoting-style' so far remains a mere Lisp variable, not a
customisable option.
> Lastly, to play devil's advocate: I also recognize, after having written this,
> that I'm something of an "old fogey" in Emacs terms, with a special place for
> ASCII in my heart. It's quite possible that the new-and-coming generation is
> very fond of Unicode, and they will all love this feature, since it gives
> Emacs a more modern "feel". For their sake, I'm prepared to wait for the
> world's judgment before deciding that this feature is entirely terrible.
We old fogies need our tools just as much as the new generations do.
[ .... ]
> --
> John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Thu, 05 May 2016 15:52:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> Cc: 23425 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Wed, 4 May 2016 16:49:12 -0700
>
> Attached is a proposed patch to master to do this. It disables
> translation from curved quotes, which means that quote translation now
> affects only ` and ', and it documents that the text-quoting-style
> 'grave' therefore suppresses all quote translation. This shortens the
> Emacs source code by forty lines or so, which is a good sign.
Sounds good to me, thanks. (I didn't have time to actually try this
yet.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Thu, 05 May 2016 17:06:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Wed, 4 May 2016 23:23:11 +0300
> Cc: eggert <at> cs.ucla.edu, 23425 <at> debbugs.gnu.org
>
> 4. It changes Emacs according to the preferences of specific people, without
> giving others -- in the very spirit of Emacs! -- an option to choose
> one's desired behavior in the standard fashion.
>
> At this point, I cannot undo this feature, since that would destabilize 25.1.
>
> Can we actually leave it in, while all but promising to take it out in the next release?
>
> That would seem like an odd choice.
I agree: this is not a good idea. If we even suspect we will be
taking this out soon, we shouldn't introduce it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Thu, 05 May 2016 17:08:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> From: John Wiegley <jwiegley <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 23425 <at> debbugs.gnu.org
> Date: Wed, 04 May 2016 11:46:58 -0700
>
> As maintainer, I'll go on record by saying that I very much dislike the new
> curly quotes logic.
I'm not a big fan of them, either.
But this isn't about mine or yours or Paul's personal preferences.
This is about the Emacs users out there. It is claimed that the
majority wants these quotes, and that Emacs using `this quoting' is
perceived as anything but modern, to put it mildly.
There are those who claim the exact opposite: that the majority wants
to remain with `this'. I imagine there's also those who don't care
much either way, and have not spoken about this.
How can we know which way is the truth, except by letting a larger
group of users try that? I don't see any other practical way of doing
that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Thu, 05 May 2016 23:47:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 23425 <at> debbugs.gnu.org (full text, mbox):
>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
> How can we know which way is the truth, except by letting a larger group of
> users try that? I don't see any other practical way of doing that.
I agree, we'll need to see what the Majority actually thinks, since it's
impossible to ask them here.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Fri, 06 May 2016 08:55:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 23425 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> As maintainer, I'll go on record by saying that I very much dislike the new
>> curly quotes logic.
>
> I'm not a big fan of them, either.
Me neither, but...
> There are those who claim the exact opposite: that the majority wants
> to remain with `this'. I imagine there's also those who don't care
> much either way, and have not spoken about this.
... I think most users won't even notice it (as long as it does not
appear in source code).
In fact, I know several users of Emacs who are using the pretests, and I
asked them about this. None of them noticed it until I mentioned it,
and then told me they didn't care at all.
Nico
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 10 May 2016 14:43:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 05/05/2016 08:51 AM, Eli Zaretskii wrote:
> Sounds good to me, thanks.
Thanks, no further comment so I merged it into master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 31 May 2017 01:08:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 23425 <at> debbugs.gnu.org (full text, mbox):
A year has passed. Is this report still relevant?
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Wed, 31 May 2017 01:43:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Alan Mackenzie <acm <at> muc.de>:
bug acknowledged by developer.
(Wed, 31 May 2017 01:43:02 GMT)
Full text and
rfc822 format available.
Message #127 received at 23425-done <at> debbugs.gnu.org (full text, mbox):
On 05/30/2017 06:07 PM, Glenn Morris wrote:
> A year has passed. Is this report still relevant?
No, as the patch I installed into master a year ago appears to have
fixed the problem by supporting Alan's original request in Bug#23425#26
of having a value for text-quoting-style that would "suppress all
substitution of quotes". (setq text-quoting-style 'grave) now has the
desired effect. Closing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 31 May 2017 21:26:02 GMT)
Full text and
rfc822 format available.
Message #130 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, Paul.
On Tue, May 30, 2017 at 18:42:00 -0700, Paul Eggert wrote:
> On 05/30/2017 06:07 PM, Glenn Morris wrote:
> > A year has passed. Is this report still relevant?
Yes, it is very much relevant. The bug has not been fixed. In
particular, somebody using `message' to generate quotes in the natural
and obvious fashion (possibly intending to resubmit them to the lisp
reader) will get them corrupted, and will lose much time and energy
attempting to diagnose the puzzling bug which results, possibly giving
up.
The only documentation for this feature is obscure and hidden. There
is nothing in `message''s doc string which explicitly states likely
unwanted replacement of characters takes place; just a puzzling
"exception proves the rule" paragraph.
> No, as the patch I installed into master a year ago appears to have
> fixed the problem by supporting Alan's original request in Bug#23425#26
That appearance is deceptive. And my original complaint was most
assuredly not in #26 of that thread. Your workaround did not fix the
problem. The problem, stated above, is the waste of other people's time
and energy inevitably caused by the current code and default options. A
fix would be a state in which somebody could use `message' in emacs -Q
without getting caught up in all this stuff.
> of having a value for text-quoting-style that would "suppress all
> substitution of quotes". (setq text-quoting-style 'grave) now has the
> desired effect. Closing.
Well, thanks a bunch for giving me a chance to state my view before
closing this bug. Notice that both Glenn's post and your response were
made in the middle of the night, European time, without there being
intervening European day time.
This bug has not been fixed. That judgement is mine, as the person who
raised it in the first place. Did you close this bug as "won't fix"?
Although not good, that would at least be better than pretending it's
been fixed and sweeping it back under the carpet.
--
Alan Mackenzie (Nuremberg, Germany).
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 31 May 2017 22:05:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 31 May 2017 23:27:02 GMT)
Full text and
rfc822 format available.
Message #135 received at 23425 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 05/31/2017 02:24 PM, Alan Mackenzie wrote:
> This bug has not been fixed.
Oh, sorry, I misunderstood your earlier comments. I reopened the bug.
> The only documentation for this feature is obscure and hidden. There
> is nothing in `message''s doc string which explicitly states likely
> unwanted replacement of characters takes place; just a puzzling
> "exception proves the rule" paragraph.
I installed the attached patch into master, which I hope makes that doc
string sufficiently clear. I'd rather not change the Emacs default
behavior, though, for reasons already discussed.
[0001-src-editfns.c-Fmessage-Improve-doc-string-Bug-23425-.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Thu, 01 Jun 2017 16:57:01 GMT)
Full text and
rfc822 format available.
Message #138 received at 23425 <at> debbugs.gnu.org (full text, mbox):
So in your view what needs to happen for this bug to be closed?
As was explained a year ago, change your initial example to (message
"%s" ...) and your issue goes away.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Fri, 02 Jun 2017 21:04:02 GMT)
Full text and
rfc822 format available.
Message #141 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, Paul.
On Wed, May 31, 2017 at 16:26:12 -0700, Paul Eggert wrote:
> On 05/31/2017 02:24 PM, Alan Mackenzie wrote:
> > This bug has not been fixed.
> Oh, sorry, I misunderstood your earlier comments. I reopened the bug.
Thanks.
How about transferring this discussion to emacs-devel, so that more
people would be able to see it.
> > The only documentation for this feature is obscure and hidden. There
> > is nothing in `message''s doc string which explicitly states likely
> > unwanted replacement of characters takes place; just a puzzling
> > "exception proves the rule" paragraph.
> I installed the attached patch into master, which I hope makes that doc
> string sufficiently clear. I'd rather not change the Emacs default
> behavior, though, for reasons already discussed.
The default behaviour has been changed already, and that change has
caused problems and will cause further problems.
I propose restoring the default to what it was in Emacs 24. For
simplicity's sake, only % should be special, and for translating quotes
we could introduce %' and %`, such that quote translation happens only
when a %' or %` is present.
This would solve the problem in an elegant and consistent way, would
enable quote translation to happen, yet would avoid users of literal
quote characters getting caught up in unwanted quote translations.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Fri, 02 Jun 2017 21:16:02 GMT)
Full text and
rfc822 format available.
Message #144 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 6/3/17 12:02 AM, Alan Mackenzie wrote:
> I propose restoring the default to what it was in Emacs 24. For
> simplicity's sake, only % should be special, and for translating quotes
> we could introduce %' and %`, such that quote translation happens only
> when a %' or %` is present.
I recall proposing something to that effect back in one of the original
discussions. E.g. GCC does that with its message function.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Fri, 02 Jun 2017 21:48:02 GMT)
Full text and
rfc822 format available.
Message #147 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 06/02/2017 02:02 PM, Alan Mackenzie wrote:
> How about transferring this discussion to emacs-devel, so that more
> people would be able to see it.
We had that discussion there already, and I doubt whether it’d be
worthwhile to repeat it. Of course you're free to take it there again if
you like.
> The default behaviour has been changed already, and that change has
> caused problems and will cause further problems.
I expect that most of the practical problems have been shaken out
already with the changes published in Emacs 25.1 last year, so that most
of this cost has already been paid.
> I propose restoring the default to what it was in Emacs 24. For
> simplicity's sake, only % should be special, and for translating quotes
> we could introduce %' and %`, such that quote translation happens only
> when a %' or %` is present.
That kind of approach was proposed way back when. It doesn’t address
quotes in doc strings, though. More generally, a problem with this sort
of approach is that although it simplifies ‘message’ (obviously), this
is at the price of complicating everything else. I estimate we’d need to
change 10,000 lines of Emacs source code to make that change to
‘message’. (This is a just a quick estimate based on ‘grep '".*`.*"'’.)
The resulting source code would typically be a bit harder to read than
it is now.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sat, 03 Jun 2017 00:14:01 GMT)
Full text and
rfc822 format available.
Message #150 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> We had that discussion there already, and I doubt whether it'd be
> worthwhile to repeat it. Of course you're free to take it there again
> if you like.
I think this is a situation where the maintainer(s) should simply
announce a decision, so that we can stop going over the same ground
again and again. (Personally I think a year and two releases means the
decision is already made.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sat, 03 Jun 2017 20:55:01 GMT)
Full text and
rfc822 format available.
Message #153 received at 23425 <at> debbugs.gnu.org (full text, mbox):
[ Message posted to emacs-devel <at> gnu.org, with Reply-To: set. ]
Hello, Paul.
On Fri, Jun 02, 2017 at 14:47:42 -0700, Paul Eggert wrote:
> On 06/02/2017 02:02 PM, Alan Mackenzie wrote:
> > How about transferring this discussion to emacs-devel, so that more
> > people would be able to see it.
> We had that discussion there already, and I doubt whether it’d be
> worthwhile to repeat it. Of course you're free to take it there again if
> you like.
The previous discussion was abruptly cut short, without reaching a
conclusion, with a "we're too close to a release to change anything
now". This came with the implicit understanding the discussion could be
countinued after the release.
> > The default behaviour has been changed already, and that change has
> > caused problems and will cause further problems.
> I expect that most of the practical problems have been shaken out
> already with the changes published in Emacs 25.1 last year, so that most
> of this cost has already been paid.
They have not. We have moved from a state where everybody knew what
`message' did (in Emacs 24), to one with wild special characters which
only apply sometimes, and necessitate crazy prolix formulations to work
around unwanted translations of quote characters.
`message' is currently broken.
Introducing quote translation has introduced a burden on all users of
`message'. Seeing how poisonous and insidious this translation can be,
it makes sense to shift this burden over to the use cases where the
programmers need quote translation, and hence will be aware of it.
> > I propose restoring the default to what it was in Emacs 24. For
> > simplicity's sake, only % should be special, and for translating quotes
> > we could introduce %' and %`, such that quote translation happens only
> > when a %' or %` is present.
> That kind of approach was proposed way back when. It doesn’t address
> quotes in doc strings, though.
Of course it doesn't. Doc strings have their own peculiar quoting
mechanisms which are disjoint from those of `message'.
> More generally, a problem with this sort of approach is that although
> it simplifies ‘message’ (obviously), this is at the price of
> complicating everything else.
What is the "everything else" that gets thus complicated? I don't see
anything else getting more complicated.
> I estimate we’d need to change 10,000 lines of Emacs source code to
> make that change to ‘message’. (This is a just a quick estimate based
> on ‘grep '".*`.*"'’.) The resulting source code would typically be a
> bit harder to read than it is now.
I think this estimate is way over the mark. There are around 17,000
occurrances of "message" in our Lisp sources, and probably a few in our
C sources. Only (some of) those containing the quote characters in the
format string would need amendment. These will comprise a tiny portion
of these ~17,000, and can be found easily enough with a script.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sat, 03 Jun 2017 21:03:02 GMT)
Full text and
rfc822 format available.
Message #156 received at 23425 <at> debbugs.gnu.org (full text, mbox):
[ Posted to emacs-devel <at> gnu.org. Reply-To: set there too. ]
On Fri, Jun 02, 2017 at 20:13:22 -0400, Glenn Morris wrote:
> > We had that discussion there already, and I doubt whether it'd be
> > worthwhile to repeat it. Of course you're free to take it there again
> > if you like.
The discussion was abruptly suspended with "we're too close to a
release", without any conclusion having been reached.
`message' and friends are in a thoroughly unsatisfactory state, with
wild ad-hoc rules, and obstruse formulations needed as workarounds.
> I think this is a situation where the maintainer(s) should simply
> announce a decision, so that we can stop going over the same ground
> again and again. (Personally I think a year and two releases means the
> decision is already made.)
The decision was made in the near infinite number of releases prior to
Emacs 25 to have a rational and clear system of special characters
beginning with %. Quote translation, which was introduced into Emacs
without a consensus amongst developers has destroyed that rationality
and simplicity.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sat, 03 Jun 2017 21:09:02 GMT)
Full text and
rfc822 format available.
Message #159 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, Glenn.
On Thu, Jun 01, 2017 at 12:56:05 -0400, Glenn Morris wrote:
> So in your view what needs to happen for this bug to be closed?
> As was explained a year ago, change your initial example to (message
> "%s" ...) and your issue goes away.
No it does not. The issue is that this is a trap waiting to spring and
bite hackers. Also the workaround you identify is ugly and irregular -
it would involve writing two format strings (one of them being the "%s")
to do one `message' invocation.
I have identified a regular and rational way to repair the damage,
namely to introduce the new %-constructs %` and %', which would invoke
quote translation, and would remain compatible with `message' as it was
before Emacs-25.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sat, 03 Jun 2017 21:12:02 GMT)
Full text and
rfc822 format available.
Message #162 received at 23425 <at> debbugs.gnu.org (full text, mbox):
[ Posted to emacs-devel <at> gnu.org, Reply-To: set there, too. ]
Hello, Dmitry.
On Sat, Jun 03, 2017 at 00:15:49 +0300, Dmitry Gutov wrote:
> On 6/3/17 12:02 AM, Alan Mackenzie wrote:
> > I propose restoring the default to what it was in Emacs 24. For
> > simplicity's sake, only % should be special, and for translating quotes
> > we could introduce %' and %`, such that quote translation happens only
> > when a %' or %` is present.
> I recall proposing something to that effect back in one of the original
> discussions. E.g. GCC does that with its message function.
Can you see any disadvantage with such a change?
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sat, 03 Jun 2017 21:33:01 GMT)
Full text and
rfc822 format available.
Message #165 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 6/4/17 12:10 AM, Alan Mackenzie wrote:
>> I recall proposing something to that effect back in one of the original
>> discussions. E.g. GCC does that with its message function.
>
> Can you see any disadvantage with such a change?
IIRC, it was waved away with complaints of verbosity.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sun, 04 Jun 2017 21:02:01 GMT)
Full text and
rfc822 format available.
Message #168 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Alan Mackenzie wrote:
> We have moved from a state where everybody knew what
> `message' did (in Emacs 24), to one with wild special characters which
> only apply sometimes, and necessitate crazy prolix formulations to work
> around unwanted translations of quote characters.
This exaggerates somewhat. We moved from Emacs 24 where only % is special, to
Emacs 25 where %, ` and ' are special. Although some people don't know that `
and ' are special, that's also true for %. And although it can be annoying to
write (message "%s" STR) to avoid unwanted translation of STR, that annoyance
was already present for %.
> it makes sense to shift this burden over to the use cases where the
> programmers need quote translation, and hence will be aware of it.
When text-quoting-style specifies translation, most instances of ` and ' in
Emacs messages are better off translated. So it also makes sense to translate by
default in this situation, with a way to avoid translation in the rare cases
where translation isn't wanted. The question is about which approach makes more
sense, not whether one approach is sensible and the other nonsense.
>> although it simplifies ‘message’ (obviously), this is at the price of
>> complicating everything else.
>
> What is the "everything else" that gets thus complicated?
I was referring to the hassle of going through hundreds or thousands of message
strings or calls, deciding which instances of ` and ' should be replaced with %`
and %', and replacing the instances accordingly. It's also possible that at
times we'll need two format strings instead of one, complicating the code.
> There are around 17,000
> occurrances of "message" in our Lisp sources, and probably a few in our
> C sources. Only (some of) those containing the quote characters in the
> format string would need amendment. These will comprise a tiny portion
> of these ~17,000
How many lines do you think will be in that "tiny portion"? No matter how you
count them, it'll be quite a few changes.
> and can be found easily enough with a script
I'm afraid not, because in many cases the string is not a simple literal
constant argument to the message function. For starters, there's also the error
function; that's another 14,000 text matches in the Elisp source -- many of them
false alarms of course, but not all of them.
I'm not saying this sort of change is impossible. It's just that it'd be quite a
bit of work, work that someone would need to volunteer to do. Is this really the
best use of our limited resources?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Mon, 05 Jun 2017 16:29:02 GMT)
Full text and
rfc822 format available.
Message #171 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, Paul.
On Sun, Jun 04, 2017 at 14:01:42 -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:
> > We have moved from a state where everybody knew what
> > `message' did (in Emacs 24), to one with wild special characters which
> > only apply sometimes, and necessitate crazy prolix formulations to work
> > around unwanted translations of quote characters.
> This exaggerates somewhat. We moved from Emacs 24 where only % is special, to
> Emacs 25 where %, ` and ' are special.
Yes. We moved from regularity (where %x, for varying x, and nothing
else was special) to a ragbag (where there are 3 special characters,
with the two "new" ones being syntactically totally different from %).
> Although some people don't know that ` and ' are special, that's also
> true for %.
No. _Anybody_ who's used `message' knows that %s is how you print out
an arbitrary sexp. Anybody who's used printf in C knows this, too. It
is very easy not to know that ` and ' are special, and horribly easy to
get caught out by it, as happened to me.
> And although it can be annoying to write (message "%s" STR) to avoid
> unwanted translation of STR, that annoyance was already present for %.
It is not merely annoying, it is hideously irregular. Having to write
(message "%s" (format "...." arg1 arg2 ....)) screams out "we didn't
think this through properly". A call to message should only need one
format string. The change I am proposing would achieve this.
This was never the case for %. It is and always was trivially easy to
cause a literal % sign to be output by message, and there was never
danger of confusion in this.
We also have `format' and `format-message' which handle format strings
inconsistently. (Yes, I know, `format-message' was introduced
deliberately to create this inconsistency, because `format' was no
longer able to cope on its own.)
> > it makes sense to shift this burden over to the use cases where the
> > programmers need quote translation, and hence will be aware of it.
> When text-quoting-style specifies translation, most instances of ` and ' in
> Emacs messages are better off translated. So it also makes sense to translate by
> default in this situation, with a way to avoid translation in the rare cases
> where translation isn't wanted.
I disagree with this, of course. Translating behind people's backs is
not a friendly thing to do. Translation should only be done where it is
specifically specified.
> The question is about which approach makes more sense, not whether one
> approach is sensible and the other nonsense.
OK.
> >> although it simplifies ‘message’ (obviously), this is at the price of
> >> complicating everything else.
> > What is the "everything else" that gets thus complicated?
> I was referring to the hassle of going through hundreds or thousands of message
> strings or calls, deciding which instances of ` and ' should be replaced with %`
> and %', and replacing the instances accordingly.
Yes. There are quite a lot, but not an unmanageable number.
> It's also possible that at times we'll need two format strings instead
> of one, complicating the code.
We need two strings instead of one at the moment, with (message "%s"
(format "..." .....)). With %` and %' we'd only need one string in each
message invocation. This is simplification.
Can you give an example of something which might need two strings?
> > There are around 17,000 occurrances of "message" in our Lisp
> > sources, and probably a few in our C sources. Only (some of) those
> > containing the quote characters in the format string would need
> > amendment. These will comprise a tiny portion of these ~17,000
> How many lines do you think will be in that "tiny portion"? No matter how you
> count them, it'll be quite a few changes.
By searching for
"(\\(message\\|error\\)\\s +\\([^\"]\\|\"\\(\\\\.\\|[^\"\\]\\)*[`']\\)"
, i.e. an invocation of message or error followed by either something
which isn't a literal string, or a literal string containing ` or ', I
get 2745 matches in our Lisp sources. There'll be a smaller number also
in our C sources. I would have to enhance that regexp to recognise
comments, and maybe a few other things, but 2745 is a good first
approximation.
A very great number of these are "(error ..." handlers in condition-case
forms. A great number of those remaining could be simply and
mechanically translated, for example "don't", "can't", "couldn't", etc.,
and a lot of "`%s'"s and "`%S'"s.
I estimate there will be a few hundred forms remaining which need
decision making to adapt them. For example, where message is used in
macros, and the format string is a macro parameter.
> > and can be found easily enough with a script
> I'm afraid not, because in many cases the string is not a simple literal
> constant argument to the message function. For starters, there's also the error
> function; that's another 14,000 text matches in the Elisp source -- many of them
> false alarms of course, but not all of them.
See above.
> I'm not saying this sort of change is impossible. It's just that it'd be quite a
> bit of work, work that someone would need to volunteer to do. Is this really the
> best use of our limited resources?
Clearly, that someone would have to be me. The consequences of
surreptitious unwanted translation are so severe that I think this would
indeed be a good use of resources.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Mon, 05 Jun 2017 18:20:02 GMT)
Full text and
rfc822 format available.
Message #174 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 06/05/2017 09:27 AM, Alan Mackenzie wrote:
> Can you give an example of something which might need two strings?
Suppose the same string is used for both messages and documentation.
You're proposing %` in the former where ` is in the latter, so we would
need distinct strings.People cut and paste between messages and doc
strings, and it's possible there's even code that does this (I haven't
checked). Using different quoting notations for the two kinds of strings
will cause confusion and problems.
> 2745 is a good first approximation.
This is being optimistic. It's not just the message and error functions;
there are others, ranging from general functions like user-error to
more-specialized functions like icalendar--dmsg.These cannot be found
merely by a simple text search for function names. A simple albeit
tedious and somewhat error-prone approach would be to examine every `
and ' in every string and character constant (in either C or Elisp) and
fix those intended for the message function or any of its callers. This
is the sort of thing that I did when converting for Emacs 25.
> The consequences of surreptitious unwanted translation are so severe
It's not surreptitious: it's documented. And the consequences are not
severe: they are a minor change to strings intended for human
consumption, where humans can easily recover from unwanted translation,
and where humans who don't want translation can easily turn it off.
As I understand it, you're proposing making hundreds or thousands of
changes like this:
(error "Can't find `%s' in %s" thing where)))
=> (error "Can%'t find %`%s%' in %s" thing where)))
These changes will adversely affect code readability, and this will have
a maintenance cost in the long run -- not just to whoever makes the
hundreds or thousands of changes, but to everybody who has to read the
code afterwards.It's not at all clear that this cost is greater than the
benefit of fixing some of the minor problems that you're objecting to.
> _Anybody_ who's used `message' knows
Perhaps I should introduce you to my students someday. I teach them
elements of Emacs and I assure you that some of them do not know.
Although I readily concede that more people know about % than ` or ',
this doesn't alter the fact that it causes problems to support special
characters of any sort in the message function. Elisp code needed to use
(message "%s" STR) even before the change you're objecting to, and it'd
still need (message "%s" STR) even if the change were reverted.
> It is not merely annoying, it is hideously irregular. Having to write
> (message "%s" (format "...." arg1 arg2 ....)) screams out "we didn't
> think this through properly".
Yes, and that's just as true for % as it is for ` and '. In hindsight,
the message function should have had a better API. Hindsight is
wonderful....
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Mon, 05 Jun 2017 18:32:01 GMT)
Full text and
rfc822 format available.
Message #177 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On Jun 05 2017, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> Suppose the same string is used for both messages and
> documentation. You're proposing %` in the former where ` is in the latter,
> so we would need distinct strings.People cut and paste between messages
> and doc strings, and it's possible there's even code that does this (I
> haven't checked). Using different quoting notations for the two kinds of
> strings will cause confusion and problems.
That's a bad argument. A doc string already has completely different
special characters.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Mon, 05 Jun 2017 20:39:02 GMT)
Full text and
rfc822 format available.
Message #180 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, Paul.
On Mon, Jun 05, 2017 at 11:19:06 -0700, Paul Eggert wrote:
> On 06/05/2017 09:27 AM, Alan Mackenzie wrote:
[ .... ]
> > 2745 is a good first approximation.
> This is being optimistic. It's not just the message and error functions;
> there are others, ranging from general functions like user-error to
> more-specialized functions like icalendar--dmsg.These cannot be found
> merely by a simple text search for function names.
Maybe not, but 2745 remains a good first approximation. Other functions
which call message will be found in their turn, and the number of calls
of things like icalendar--dmsg will be small, both individually and in
total. There are around 275 calls to message which have a non-literal
format argument.
> A simple albeit tedious and somewhat error-prone approach would be to
> examine every ` and ' in every string and character constant (in
> either C or Elisp) and fix those intended for the message function or
> any of its callers. This is the sort of thing that I did when
> converting for Emacs 25.
> > The consequences of surreptitious unwanted translation are so severe
> It's not surreptitious: it's documented.
And this documentation is useless for preventing the problems. Somebody
using message to output Lisp will use ' just as I did - and suffer the
same horrendous problems trying to make sense of non-sensical error
messages saying 'foo does not exist, when it plainly does. Do you,
perhaps, have another strategem for preventing this problem?
As I said, the burden of dealing with this translation should fall on
those who are actually and consciously using it. Unless, of course,
you're in favour of hackers remaining unaware of the stealthy
alterations being made to their expressed intentions. Such a burden, on
those wanting the translation, is small.
> And the consequences are not severe: they are a minor change to
> strings intended for human consumption, where humans can easily
> recover from unwanted translation, and where humans who don't want
> translation can easily turn it off.
When I got caught by this bug there was no "easy" way to turn off the
translation. The process of turning it off involved a long period of
puzzlement over the non-sensical error messages referred to above, and
an even longer period of being very angry at having my work messed up by
Emacs. How do you propose to prevent such puzzlement and anger in the
future, if not by %` and %'? And I was somebody who had been familiar
with discussions on emacs-devel over such matters. Such things might
not seem severe to you. I am sure they are to many people.
> As I understand it, you're proposing making hundreds or thousands of
> changes like this:
> (error "Can't find `%s' in %s" thing where)))
> => (error "Can%'t find %`%s%' in %s" thing where)))
Yes.
> These changes will adversely affect code readability, and this will have
> a maintenance cost in the long run
No. The addition of quote translation is what has affected readability.
It is currently implicit and vague, a bit like the lack of connection
between written English and spoken English. I am proposing restoring it
to an explicit form, where the sole special character is %, as it had
been for ever before Emacs 25.
I don't think you've considered the maintenance cost of this
impliciticity, this vagueness, the fact that people will be using ` and
' in format strings without understanding what they mean.
> -- not just to whoever makes the hundreds or thousands of changes, but
> to everybody who has to read the code afterwards.
Those people will be able to understand the code much more easily with
explicit %` and %' rather than the stealthy behind-the-back translation
which happens at the moment.
> It's not at all clear that this cost is greater than the benefit of
> fixing some of the minor problems that you're objecting to.
It's easy to minimise and dismiss other people's problems. I don't see
non-sensical error messages as anything but a major problem.
One of the problems of the Emacs 25 approach is that the distinction
between ` and ', and the curly quotes has become vague, fuzzy, and
confused. I do not want this confusion to carry on into Emacs 26.
> > _Anybody_ who's used `message' knows
> Perhaps I should introduce you to my students someday. I teach them
> elements of Emacs and I assure you that some of them do not know.
The ones who have never used `message', you mean. 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?
> Although I readily concede that more people know about % than ` or ',
> this doesn't alter the fact that it causes problems to support special
> characters of any sort in the message function. Elisp code needed to use
> (message "%s" STR) even before the change you're objecting to,
Did it? When and why?
> and it'd still need (message "%s" STR) even if the change were
> reverted.
When and why?
> > It is not merely annoying, it is hideously irregular. Having to write
> > (message "%s" (format "...." arg1 arg2 ....)) screams out "we didn't
> > think this through properly".
> Yes, and that's just as true for % as it is for ` and '.
Not at all. In message, % causes no problems. ` and ' do.
> In hindsight, the message function should have had a better API.
> Hindsight is wonderful....
If you think a better API could have been conceived, outline it. I
don't. And even if it could, that's no excuse to worsen the workings of
message.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Mon, 05 Jun 2017 21:06:01 GMT)
Full text and
rfc822 format available.
Message #183 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 2017-06-05 16:37, Alan Mackenzie wrote:
> How do you propose to prevent such puzzlement and anger in the
> future, if not by %` and %'?
Note that this introduces a backwards compatibility issue, if not done carefully:
Debugger entered--Lisp error: (error "Not enough arguments for format string")
message("%`woops%'")
eval((message "%`woops%'") nil)
Did something similar happen with \=' ?
Clément.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 06 Jun 2017 00:15:02 GMT)
Full text and
rfc822 format available.
Message #186 received at 23425 <at> debbugs.gnu.org (full text, mbox):
>> 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 been true for years. For
example, lisp/ChangeLog.8 says this:
1999-02-23 Richard M. Stallman <rms <at> gnu.org>
* subr.el (with-temp-message): Use %s so % in old msg won't fool us.
This use of (message "%s" ...) is still in master, and would still be
needed even if we went back to Emacs 24-style message formatting.
> Somebody using message to output Lisp will use ' just as I did - and
suffer the
> same horrendous problems
Sure, like the “horrendous” problems with %. For example, in Emacs 24
your example, when used with data involving %:
(setq c-parse-state-state '((a '%%)))
(message
(concat "(setq "
(mapconcat
(lambda (arg)
(format "%s %s%s" (car arg)
(if (atom (cdr arg)) "" "'")
(if (markerp (cdr arg))
(format "(copy-marker %s)" (marker-position (cdr arg)))
(cdr arg))))
c-parse-state-state " ")
")"))
returns "(setq a '((quote %)))", which is obviously wrong and which
results in silent data corruption.
> Do you, perhaps, have another strategem for preventing this problem?
Sure: don’t pass arbitrary strings to the message function.
> 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, by
causing more puzzlement and anger than it would prevent. It would make
formats significantly harder to read. And as Clément mentioned, it would
introduce compatibility problems of its own.
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. A downside, though, is
that it would involve changing hundreds or thousands of strings in the
Emacs source (just as %` and %' would).
> 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 '.
> 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.
> The consequences of surreptitious unwanted translation ...
>> It's not surreptitious: it's documented.
> 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”.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 06 Jun 2017 08:22:01 GMT)
Full text and
rfc822 format available.
Message #189 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On Jun 05 2017, Paul Eggert <eggert <at> cs.ucla.edu> 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.
Another bad argument, because we are talking about format strings, which
you cannot be replaced by "%s".
>>> (error "Can't find `%s' in %s" thing where)))
>>> => (error "Can%'t find %`%s%' in %s" thing where)))
A better way would be a new modifier to place quotes around the
argument. That's what GCC is using now. Also, contractions like don't
should be avoided anyway.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 06 Jun 2017 12:25:02 GMT)
Full text and
rfc822 format available.
Message #192 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 2017-06-06 04:21, Andreas Schwab wrote:
> Also, contractions like don't
> should be avoided anyway.
That doesn't matter much in the long run, I think: we intend to support languages in which apostrophes in the middle of words can't be avoided.
Clément.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 06 Jun 2017 13:57:02 GMT)
Full text and
rfc822 format available.
Message #195 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On Tue, Jun 6, 2017 at 7:24 PM, Clément Pit-Claudel
<cpitclaudel <at> gmail.com> wrote:
> On 2017-06-06 04:21, Andreas Schwab wrote:
>> Also, contractions like don't
>> should be avoided anyway.
>
> That doesn't matter much in the long run, I think: we intend to support languages in which apostrophes in the middle of words can't be avoided.
In that long run, I have more news for you: there are languages which
have a letter that looks almost, but not exactly, like the apostrophe
punctuation mark, but is encoded differently. (E.g. Ukrainian, U+02BC
Modifier Letter Apostrophe, as opposed to U+2019 Right Single
Quotation Mark).
Good luck substituting the correct character in each case given only '
U+0027 Apostrophe.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 06 Jun 2017 18:22:01 GMT)
Full text and
rfc822 format available.
Message #198 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 2017-06-06 09:55, Yuri Khan wrote:
> On Tue, Jun 6, 2017 at 7:24 PM, Clément Pit-Claudel
> <cpitclaudel <at> gmail.com> wrote:
>> On 2017-06-06 04:21, Andreas Schwab wrote:
>>> Also, contractions like don't
>>> should be avoided anyway.
>>
>> That doesn't matter much in the long run, I think: we intend to support languages in which apostrophes in the middle of words can't be avoided.
>
> In that long run, I have more news for you: there are languages which
> have a letter that looks almost, but not exactly, like the apostrophe
> punctuation mark, but is encoded differently. (E.g. Ukrainian, U+02BC
> Modifier Letter Apostrophe, as opposed to U+2019 Right Single
> Quotation Mark).
>
> Good luck substituting the correct character in each case given only '
> U+0027 Apostrophe.
Do you mean that in these languages the casual way is to write ', though the formal way would be ʼ?
Clément.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 06 Jun 2017 19:01:02 GMT)
Full text and
rfc822 format available.
Message #201 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On Wed, Jun 7, 2017 at 1:21 AM, Clément Pit-Claudel
<cpitclaudel <at> gmail.com> wrote:
>> In that long run, I have more news for you: there are languages which
>> have a letter that looks almost, but not exactly, like the apostrophe
>> punctuation mark, but is encoded differently. (E.g. Ukrainian, U+02BC
>> Modifier Letter Apostrophe, as opposed to U+2019 Right Single
>> Quotation Mark).
>
> Do you mean that in these languages the casual way is to write ', though the formal way would be ʼ?
Hm, I haven’t thought about that. That depends.
The default XKB Ukrainian layout maps the <TLDE> key to U+0027 and
Shift+<TLDE> to U+02BC. I have no knowledge whether X11/GNU/Linux
users actually bother to press Shift.
The Ukrainian layout on Windows (Vista and above) has only U+0027.
There exist third-party typographic layouts but I assume they are only
used by people who are (1) aware of the difference, and (2) care.
So, yes, I expect that the majority of Ukrainian computer users do in
fact enter U+0027 when the correct character is U+02BC.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 06 Jun 2017 19:41:02 GMT)
Full text and
rfc822 format available.
Message #204 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 2017-06-06 14:59, Yuri Khan wrote:
> So, yes, I expect that the majority of Ukrainian computer users do in
> fact enter U+0027 when the correct character is U+02BC.
Makes sense, thanks for clarifying.
It might be possible to enforce that translation files use the proper character (people writing translations for Emacs will be able to rely on an appropriate Emacs input method). Can you confirm that this would sidestep the issue that you mentioned earlier? We'd never have ' where ʼ is meant, and so automatic `'-translation wouldn't cause unexpected issues.
(The language that prompted my initial email was unsurprisingly French, which uses ' between consecutive characters (it'd be a pain to have to type "l%'arrivée d%'un email", and I don't know anyone who types in the proper "l’arrivée d’un email", except when their text editor auto-corrects).
Clément.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Tue, 06 Jun 2017 23:10:02 GMT)
Full text and
rfc822 format available.
Message #207 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 06/06/2017 01:21 AM, Andreas Schwab wrote:
> we are talking about format strings, which you cannot be replaced by "%s".
The original bug report is about the ‘message’ function, not about
formats in general. For that function, "%s" is the longstanding way to
output arbitrary strings. For formats in general, one can use the
‘format’ function (which does not translate quotes) or the
‘format-message’ function (which does); this suffices in practice.
> contractions like don't should be avoided anyway
As a practical matter Emacs messages often have contractions and I am
not aware of a GNU style guideline that would discourage their use.
Plus, some uses of apostrophes in messages are for possessives, not
contractions. Surely we should not ban contractions and possessives
merely because our API has glitches with apostrophes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 07 Jun 2017 04:58:02 GMT)
Full text and
rfc822 format available.
Message #210 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
> Date: Tue, 6 Jun 2017 15:39:57 -0400
> Cc: Andreas Schwab <schwab <at> suse.de>, Paul Eggert <eggert <at> cs.ucla.edu>,
> 23425 <at> debbugs.gnu.org, Alan Mackenzie <acm <at> muc.de>,
> Emacs developers <emacs-devel <at> gnu.org>
>
> (The language that prompted my initial email was unsurprisingly French, which uses ' between consecutive characters (it'd be a pain to have to type "l%'arrivée d%'un email", and I don't know anyone who types in the proper "l’arrivée d’un email", except when their text editor auto-corrects).
You should know that there are people who claim that using u+2019 in
"l’arrivée" is incorrect, and that one should write "lʼarrivée"
instead. The rationale is that u+2019 is a punctuation character, so
it doesn't belong in the middle of a word. There was a long
discussion about that on the Unicode list a couple of months ago.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 07 Jun 2017 07:46:01 GMT)
Full text and
rfc822 format available.
Message #213 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On Jun 06 2017, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> The original bug report is about the ‘message’ function, not about formats
> in general. For that function, "%s" is the longstanding way to output
> arbitrary strings. For formats in general, one can use the ‘format’
> function (which does not translate quotes) or the ‘format-message’
> function (which does); this suffices in practice.
That doesn't make sense, since the first argument of message is a format
string.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 07 Jun 2017 13:29:02 GMT)
Full text and
rfc822 format available.
Message #216 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Could you guys please possibly pick only one mailing list,
bugs or emacs-devel?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 07 Jun 2017 16:52:02 GMT)
Full text and
rfc822 format available.
Message #219 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, Clément.
On Mon, Jun 05, 2017 at 17:05:43 -0400, Clément Pit-Claudel wrote:
> On 2017-06-05 16:37, Alan Mackenzie wrote:
> > How do you propose to prevent such puzzlement and anger in the
> > future, if not by %` and %'?
> Note that this introduces a backwards compatibility issue, if not done carefully:
> Debugger entered--Lisp error: (error "Not enough arguments for format string")
> message("%`woops%'")
> eval((message "%`woops%'") nil)
I think it would be done carefully! Clearly, %` and %' would be format
elements for which the count of necessary arguments would not be
incremented. Or, more concisely, we wouldn't count them.
[ .... ]
> Clément.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 07 Jun 2017 18:18:01 GMT)
Full text and
rfc822 format available.
Message #222 received at 23425 <at> debbugs.gnu.org (full text, mbox):
[dropping emacs-devel on Drew's request]
On 06/07/2017 12:44 AM, Andreas Schwab wrote:
> That doesn't make sense, since the first argument of message is a
> format string.
Sorry, I’ve lost context. I wrote that (message "%s" STR) was needed
even before Emacs 25 for arbitrary strings STR, to avoid unwanted
interpretation of characters in STR. Alan was dubious and wanted to know
when and why that occurred. I gave a example from 1999 and said the
“why” was because “one can’t pass arbitrary strings to the message
function and expect them to be displayed as-is”. You objected to this
justification, writing “we are talking about format strings, which you
cannot be replaced by "%s".” This objection was unclear and the
subsequent discussion (from my point of view, anyway) has gone off the
rails. Perhaps you could clarify the objection by giving specific code
that exemplifies the problem you are thinking of, presumably a problem
that cannot easily be addressed by using (message "%s" ...).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 07 Jun 2017 19:15:02 GMT)
Full text and
rfc822 format available.
Message #225 received at 23425 <at> debbugs.gnu.org (full text, mbox):
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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 07 Jun 2017 19:28:02 GMT)
Full text and
rfc822 format available.
Message #228 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 2017-06-07 15:13, Alan Mackenzie wrote:
> 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.
Uh? What I pointed out was that new code wouldn't work with old Emacsen.
Maybe I misunderstood your proposal? As far as I can tell, the change you propose will force me to write every `message' call like this in my packages:
(if (< emacs-version 26)
(message "Hello, `world'!")
(message "Hello, %`world%'!"))
Am I missing something?
Clément.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 07 Jun 2017 19:30:03 GMT)
Full text and
rfc822 format available.
Message #231 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 2017-06-07 12:50, Alan Mackenzie wrote:
> Hello, Clément.
>
> On Mon, Jun 05, 2017 at 17:05:43 -0400, Clément Pit-Claudel wrote:
>> On 2017-06-05 16:37, Alan Mackenzie wrote:
>>> How do you propose to prevent such puzzlement and anger in the
>>> future, if not by %` and %'?
>
>> Note that this introduces a backwards compatibility issue, if not done carefully:
>
>> Debugger entered--Lisp error: (error "Not enough arguments for format string")
>> message("%`woops%'")
>> eval((message "%`woops%'") nil)
>
> I think it would be done carefully! Clearly, %` and %' would be format
> elements for which the count of necessary arguments would not be
> incremented. Or, more concisely, we wouldn't count them.
Sorry, that's not what I was talking about. The problem I was worrying about is that these new format constructs would raise exceptions in older versions of Emacs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 07 Jun 2017 19:34:02 GMT)
Full text and
rfc822 format available.
Message #234 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 6/7/17 10:27 PM, Clément Pit-Claudel wrote:
> Uh? What I pointed out was that new code wouldn't work with old Emacsen.
That's a valid concern, and the only tangible downside of introducing %`
and %' that I'm aware of.
> Maybe I misunderstood your proposal? As far as I can tell, the change you propose will force me to write every `message' call like this in my packages:
>
> (if (< emacs-version 26)
> (message "Hello, `world'!")
> (message "Hello, %`world%'!"))
>
> Am I missing something?
Or wait until you only need to support Emacs 26 and newer. Not a huge
loss, IMO. That time will come.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 07 Jun 2017 19:53:01 GMT)
Full text and
rfc822 format available.
Message #237 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, Clément.
On Wed, Jun 07, 2017 at 15:27:02 -0400, Clément Pit-Claudel wrote:
> On 2017-06-07 15:13, Alan Mackenzie wrote:
> > 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.
> Uh? What I pointed out was that new code wouldn't work with old Emacsen.
> Maybe I misunderstood your proposal? As far as I can tell, the change you propose will force me to write every `message' call like this in my packages:
> (if (< emacs-version 26)
> (message "Hello, `world'!")
> (message "Hello, %`world%'!"))
> Am I missing something?
Apologies, I misunderstood you completely.
I also missed the point you are making. I'll have to think about it.
Thanks!
> Clément.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 07 Jun 2017 20:35:01 GMT)
Full text and
rfc822 format available.
Message #240 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello again, Clément.
On Wed, Jun 07, 2017 at 15:27:02 -0400, Clément Pit-Claudel wrote:
> On 2017-06-07 15:13, Alan Mackenzie wrote:
> > 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.
> Uh? What I pointed out was that new code wouldn't work with old Emacsen.
> Maybe I misunderstood your proposal? As far as I can tell, the change you propose will force me to write every `message' call like this in my packages:
> (if (< emacs-version 26)
> (message "Hello, `world'!")
> (message "Hello, %`world%'!"))
That would clearly be unacceptable.
> Am I missing something?
No, I don't think so. But it is probably feasible to put advice on
`message' in older Emacsen. This advice would strip the % from %` and
%'.
It should be borne in mind that the handling of ` and ' by `message' in
Emacs-25 is in any case incompatible with earlier versions of Emacs.
> Clément.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Wed, 07 Jun 2017 23:29:01 GMT)
Full text and
rfc822 format available.
Message #243 received at 23425 <at> debbugs.gnu.org (full text, mbox):
[dropping emacs-devel on Drew's request.]
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.
> _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".
> 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, 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Thu, 08 Jun 2017 08:05:01 GMT)
Full text and
rfc822 format available.
Message #246 received at 23425 <at> debbugs.gnu.org (full text, mbox):
If you want to force everyone to use (message "%s" (format ...)) then
there is no point in message to use format again.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Thu, 08 Jun 2017 17:36:02 GMT)
Full text and
rfc822 format available.
Message #249 received at 23425 <at> debbugs.gnu.org (full text, mbox):
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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Thu, 08 Jun 2017 20:18:01 GMT)
Full text and
rfc822 format available.
Message #252 received at 23425 <at> debbugs.gnu.org (full text, mbox):
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.
> 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.
> 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.
>
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Fri, 09 Jun 2017 19:43:01 GMT)
Full text and
rfc822 format available.
Message #255 received at 23425 <at> debbugs.gnu.org (full text, mbox):
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
quote.
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
specifiers.
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
master?
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Fri, 09 Jun 2017 20:18:02 GMT)
Full text and
rfc822 format available.
Message #258 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> 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
> specifiers.
Just what did you have in mind for that?
> There would be a significant amount of work amending format strings
> which currently use ` and ' to use %` and %'.
That's the problem for Emacs maintainers. But the problem for
3rd-party code is much bigger, because it often needs to support
more than just the latest release. Clement pointed this out well.
A user, including a Lisp user, should be able to write ' or ` and
get what s?he writes. No behind-the-scenes application of makeup.
No prettying-up at all - you write ' and you get '. Simple. Clear.
Lovely. Useful. No need for high-heels.
> I think the topic has been pretty thoroughly discussed. Are there any
> objections remaining to me implementing this change and committing it to
> master?
Sorry, but I cannot be in favor of this proposal, as I understand
it so far.
But I'm even less in favor of what's already been done: making
quote-translation the default behavior. That's both a tragedy
and a travesty. I cannot imagine what the maintainers were
thinking when they let this one get through.
It's fine to provide easy ways to _allow_ for different kinds of
quote translation. But quote chars (including but not limited to
` and ') should NOT be translated by default.
By default, chars should be respected for what they are. Emacs
should not substitute other chars just because someone working
on Emacs development considered the substitute chars prettier
or more modern. That's nuts. One overly zealous coder wreaked
havoc, and we'll be wrestling with the result for a long time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Fri, 09 Jun 2017 20:32:02 GMT)
Full text and
rfc822 format available.
Message #261 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Alan Mackenzie wrote:
> I think the topic has been pretty thoroughly discussed. Are there any
> objections remaining to me implementing this change and committing it to
> master?
I object. This is a contentious issue, and I would like the maintainers
to make an explicit decision before you change anything.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Fri, 09 Jun 2017 20:40:02 GMT)
Full text and
rfc822 format available.
Message #264 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, Drew.
On Fri, Jun 09, 2017 at 13:17:01 -0700, Drew Adams wrote:
> > 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
> > specifiers.
> Just what did you have in mind for that?
That this advice, applied to message in Emacs <26, would strip the %
from %` and %' in format strings. So that, for example, the format
string "%`%s%'" would get converted to "`%s'" for older Emacsen.
> > There would be a significant amount of work amending format strings
> > which currently use ` and ' to use %` and %'.
> That's the problem for Emacs maintainers. But the problem for
> 3rd-party code is much bigger, because it often needs to support
> more than just the latest release. Clement pointed this out well.
This is the purpose of the above advice to message.
> A user, including a Lisp user, should be able to write ' or ` and
> get what s?he writes. No behind-the-scenes application of makeup.
> No prettying-up at all - you write ' and you get '. Simple. Clear.
> Lovely. Useful. No need for high-heels.
I agree with you completely, which is why I am proposing this amendment.
> > I think the topic has been pretty thoroughly discussed. Are there any
> > objections remaining to me implementing this change and committing it to
> > master?
> Sorry, but I cannot be in favor of this proposal, as I understand
> it so far.
That puzzles me, since we seem to agree about everything else on this
issue.
> But I'm even less in favor of what's already been done: making
> quote-translation the default behavior. That's both a tragedy
> and a travesty. I cannot imagine what the maintainers were
> thinking when they let this one get through.
> It's fine to provide easy ways to _allow_ for different kinds of
> quote translation. But quote chars (including but not limited to
> ` and ') should NOT be translated by default.
This is what I am proposing: a ` or ' in the format string should stand
for itself, like any other character bar %. %` would get translated
either to itself or a curly quote, depending on the user's settings.
> By default, chars should be respected for what they are. Emacs
> should not substitute other chars just because someone working
> on Emacs development considered the substitute chars prettier
> or more modern. That's nuts. One overly zealous coder wreaked
> havoc, and we'll be wrestling with the result for a long time.
I agree with you. In message format strings, % should be _the_ special
character. We need one. We don't need more than one.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Fri, 09 Jun 2017 21:06:02 GMT)
Full text and
rfc822 format available.
Message #267 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> That this advice, applied to message in Emacs <26, would strip the %
> from %` and %' in format strings. So that, for example, the format
> string "%`%s%'" would get converted to "`%s'" for older Emacsen.
I suppose it's better than nothing. But I prefer to continue to ask
that Emacs come to its senses about this whole quote-beautification
exercise.
> > A user, including a Lisp user, should be able to write ' or ` and
> > get what s?he writes. No behind-the-scenes application of makeup.
> > No prettying-up at all - you write ' and you get '. Simple. Clear.
> > Lovely. Useful. No need for high-heels.
>
> I agree with you completely, which is why I am proposing this amendment.
You're accepting being automatically dressed up in high-heels,
but you're proposing a set of overshoes that you can slip on
over them, to cancel their effect.
I'm still asking that we reverse course on the high-heels
masquerade. It was misguided, and it seems quite unemacsy,
to me.
> > Sorry, but I cannot be in favor of this proposal, as I understand
> > it so far.
>
> That puzzles me, since we seem to agree about everything else on this
> issue.
See above. It may be better than nothing, but I'm still hoping
that Emacs will come to its senses about this.
> > It's fine to provide easy ways to _allow_ for different kinds of
> > quote translation. But quote chars (including but not limited to
> > ` and ') should NOT be translated by default.
>
> This is what I am proposing: a ` or ' in the format string should stand
> for itself, like any other character bar %.
I agree with that, of course. It was a mistake to silently, and
by default, make `message' handle other chars specially.
> %` would get translated either to itself or a curly quote,
> depending on the user's settings.
User settings or code settings or both? Libraries need to be
able to control the behavior by code. And users need to be
able to control it too. (And conflicts need to be resolved.)
So far, I intend to just bind `text-quoting-style' around code
I'm interested in giving sane behavior. (But I'm not against
having an advice that does essentially that for `format'.)
> > By default, chars should be respected for what they are. Emacs
> > should not substitute other chars just because someone working
> > on Emacs development considered the substitute chars prettier
> > or more modern. That's nuts. One overly zealous coder wreaked
> > havoc, and we'll be wrestling with the result for a long time.
>
> I agree with you. In message format strings, % should be _the_ special
> character. We need one. We don't need more than one.
And we should not have more than one.
Note that with `text-quoting-style' we already have a way to
reach inside `format' etc. and change the behavior. But I'm
not against that - the scope can be controlled.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Fri, 09 Jun 2017 21:46:02 GMT)
Full text and
rfc822 format available.
Message #270 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 06/09/2017 12:41 PM, Alan Mackenzie wrote:
> It's not OK to have two functions doing the same thing.
Nobody is proposing that. Although the proposed function is similar to
the message function, it differs in that it does not restyle quotes.
There is lots of precedent for having two functions with similar but not
identical behavior: for example, the error and user-error functions.
>> 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.
No, it also depends on people who have to deal with the modified code
afterwards, as the resulting formats would be harder to read. And it
depends not only on doing the work for Emacs itself, but also for
third-party software written in Elisp. These are significant costs.
Users should not be required to litter their code with hard-to-read
formats like "Can%'t encode %`0x%x%' with this buffer%'s coding system"
to get decent quoting. This would be more error-prone than what we have
now, and although I do not object to adding support for new formats I
would object to requiring their use in place of what we have now.
> You're proposing changing `message' to `memo' for those callers anyway.
No, existing callers such as (message "%s" filename) would continue to
operate as before, and would not need to be changed.
> This would leave unsolved the problem of format strings containing
both literal quote characters and quote characters for possible
replacement by curlies.
I don’t see this as a significant problem in practice. In practice,
formats typically want all quotes translated, or no quotes translated.
If I am wrong I would like to see practical examples of the problem
before worrying about possible solutions. One can address the problem
without making any changes to Emacs; whether changing Emacs would be
helpful depends on how the problem comes up in practice.
>> We discussed and rejected more-“surreptitious” options back before
his stuff was installed. For example, we discussed changing ‘format’ to
behave like ‘format-message’ does now.
>
> In effect, that's what was actually done.
Not at all. Had we made the more-drastic change, we would have had to
rewrite calls like (format "\\`%s" not-word-symbol-re). This would have
been considerably more work, and would have resulted in far more
compatibility problems, than the change that was eventually installed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Fri, 09 Jun 2017 22:52:01 GMT)
Full text and
rfc822 format available.
Message #273 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> Although the proposed function is similar to the message
> function, it differs in that it does not restyle quotes.
It is function `message', not your proposed function `memo',
that should not "restyle" quote chars.
If you want a function that restyles quote chars then _that_
should be a new function. Existing code - and future code -
that uses `message' should not have any such "restyling"
imposed on it.
If you had simply offered to add such a new function, I
doubt that anyone would have complained. Seriously.
Instead, you had to impose this incompatible and specialized
prettification on the longstanding and ubiquitous, stalwart
workhorse function `message'.
That was a grave design error. It should never have been
allowed.
> it depends not only on doing the work for Emacs itself, but also for
> third-party software written in Elisp. These are significant costs.
Really? You are actually arguing for concern about 3rd-party
maintenance work now? This is like DJT complaining about fake
news from others.
Where was that concern when you hijacked `message'? Where was
your proposal to create another function, then?
> Users should not be required to litter their code with hard-to-read
> formats like "Can%'t encode %`0x%x%' with this buffer%'s coding system"
> to get decent quoting.
And now you are concerned about users? Where was that concern
when you imposed an incompatible change on `message'?
> existing callers such as (message "%s" filename) would continue
> to operate as before, and would not need to be changed.
Where was your concern about letting `message' callers be
able to continue operating as before, before?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sat, 10 Jun 2017 00:22:02 GMT)
Full text and
rfc822 format available.
Message #276 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Drew Adams wrote:
> Where was that concern when you hijacked `message'?
There is no need for personal and inflammatory language like that.
That being said, I can try to describe the software engineering concerns. The
problem with Emacs 24 message quoting had several possible solutions, none of
them ideal. In practice the approach taken in Emacs 25 requires far fewer
changes to existing code than the proposed quote-related format specs, and that
is a significant win. Although quote-related format specs also have advantages,
these advantages do not clearly outweigh that win and the proposed specs have
further problems of their own.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sat, 10 Jun 2017 07:10:02 GMT)
Full text and
rfc822 format available.
Message #279 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Date: Fri, 09 Jun 2017 16:31:31 -0400
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 23425 <at> debbugs.gnu.org
>
> Alan Mackenzie wrote:
>
> > I think the topic has been pretty thoroughly discussed. Are there any
> > objections remaining to me implementing this change and committing it to
> > master?
>
> I object. This is a contentious issue, and I would like the maintainers
> to make an explicit decision before you change anything.
As far as things concern me, there will be no significant changes in
these facilities for at least some time, unless there's an
overwhelming agreement for such changes (which this thread and
previous ones doesn't seem to show). We've rocked this boat enough;
IMO we should now leave it where it is for some time and let users get
used to it and bring us some feedback, before we embark on further
adventures.
John?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sat, 10 Jun 2017 10:03:01 GMT)
Full text and
rfc822 format available.
Message #282 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, Paul.
On Fri, Jun 09, 2017 at 17:20:58 -0700, Paul Eggert wrote:
> Drew Adams wrote:
> > Where was that concern when you hijacked `message'?
> There is no need for personal and inflammatory language like that.
I think there is. In a group of people who are invariably nice to each
other, there is the opportunity for rogues to exploit that niceness, and
to do deeply unpleasant things without comeback. In this case, you are
that rogue, and it is about time somebody called you out on your
behaviour.
Before committing changes which are controversial, or which will
adversely affect others, it's expected to have a full and open
discussion on emacs-devel. You surreptitiously committed this backward
incompatible change to `message' on 2015-08-25, without first having
initiated such a discussion. Because of the way you did this, those
incompatibilities remained hidden until they hit another developer (me)
in a thoroughly unpleasant way some time later.
You did indeed hijack `message'. You changed a generally useful and
universal function into one with caveats and gotchas to satisfy your own
personal preferences and, likely, a desire to impose those preferences
on Emacs users generally.
I suggest that you now apologise for what you did back in August 2015,
promising never to do the same thing again.
[ .... ]
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sat, 10 Jun 2017 10:53:01 GMT)
Full text and
rfc822 format available.
Message #285 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Alan Mackenzie writes:
> I suggest that you now apologise for what you did back in August 2015,
> promising never to do the same thing again.
https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-05/msg00324.html
What more do you want?
I'm not happy with that change either, but Paul has worked on Emacs for
25 years, with almost 5000 commits on record. This does not make him
infallible, but calling him a 'rogue' is just unacceptable.
-David
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sat, 10 Jun 2017 11:49:02 GMT)
Full text and
rfc822 format available.
Message #288 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> From: David Engster <deng <at> randomsample.de>
> Date: Sat, 10 Jun 2017 12:52:44 +0200
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 23425 <at> debbugs.gnu.org
>
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-05/msg00324.html
>
> What more do you want?
>
> I'm not happy with that change either, but Paul has worked on Emacs for
> 25 years, with almost 5000 commits on record. This does not make him
> infallible, but calling him a 'rogue' is just unacceptable.
Agreed. We all make mistakes, and should be tolerable to those made
in good faith by others.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sat, 10 Jun 2017 13:03:02 GMT)
Full text and
rfc822 format available.
Message #291 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, David.
On Sat, Jun 10, 2017 at 12:52:44 +0200, David Engster wrote:
> Alan Mackenzie writes:
> > I suggest that you now apologise for what you did back in August 2015,
> > promising never to do the same thing again.
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-05/msg00324.html
> What more do you want?
An apology and an undertaking not to repeat the offense. What you quote
is colloquially known as a "non-apology". If you look carefully at it,
you'll see it attributes the blame to somebody else ("With the benefit
of hindsight, I now see that I was mistaken about how strongly some
users are attached to quoting `like this'") and that attribution is
somewhat insulting and one-sided, it makes no offer to fix things, and
the undertaking not to repeat is less than wholehearted ("I will
_strive_ ... to publicize ... on emacs-devel _more_ _prominently_").
Does that ostensible apology give you much confidence that Paul won't do
the same thing again? I have my doubts.
> I'm not happy with that change either, but Paul has worked on Emacs for
> 25 years, with almost 5000 commits on record. This does not make him
> infallible, but calling him a 'rogue' is just unacceptable.
I really wish you hadn't accused me of that after snipping my text so
that people couldn't see the two together. What I actually wrote was
"IN THIS CASE, you are that rogue", meaning in this particular instance.
I stand by that allegation. What I didn't do was to call Paul a rogue
in general.
I'm clearly not happy with this change. I'd be as unhappy about it if
Paul had already written 50,000 commits, or it had been written by RMS.
But, to repeat myself, I'm most unhappy that it was slipped into Emacs
bypassing the customary discussion process.
It's a non backward-compatible change to a critical bit of Emacs.
`message' was previously a logical, strong function, and it has been
turned into a messy function which sort of works most of the time. I
don't think this is good.
> -David
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sat, 10 Jun 2017 13:41:01 GMT)
Full text and
rfc822 format available.
Message #294 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 10 Jun 2017 13:01:01 +0000
> From: Alan Mackenzie <acm <at> muc.de>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 23425 <at> debbugs.gnu.org
>
> > https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-05/msg00324.html
>
> > What more do you want?
>
> An apology and an undertaking not to repeat the offense.
It wasn't an offense. It was a good-faith mistake. Please accept
what the others think about this, and please don't blow this out of
proportion.
> But, to repeat myself, I'm most unhappy that it was slipped into Emacs
> bypassing the customary discussion process.
Veteran contributors -- and Paul is definitely among them -- aren't
required to wait for a discussion before they push their commits.
When to start a discussion before making a change is up to their
judgment call. That is how Emacs development works for many years. I
agree that in this case the change should have been discussed more
thoroughly in advance -- but that is exactly what Paul said he regrets
he hadn't done. So the lesson has been learned, and we are now wiser
about this and similar issues that could come up in the future.
> It's a non backward-compatible change to a critical bit of Emacs.
> `message' was previously a logical, strong function, and it has been
> turned into a messy function which sort of works most of the time.
IME, it works quite well all of the time. Where it has some
deficiencies, I'm sure we will with time improve it so it works even
better. That's my experience in Emacs for many years.
And with that, I think it's high time to end this discussion.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sat, 10 Jun 2017 15:29:01 GMT)
Full text and
rfc822 format available.
Message #297 received at 23425 <at> debbugs.gnu.org (full text, mbox):
On 6/10/17 4:01 PM, Alan Mackenzie wrote:
> I'm clearly not happy with this change. I'd be as unhappy about it if
> Paul had already written 50,000 commits, or it had been written by RMS.
> But, to repeat myself, I'm most unhappy that it was slipped into Emacs
> bypassing the customary discussion process.
Much as I dislike this and related changes, and the enormous timewaste
that ensued, the change had been approved by the back-then maintainer,
in an even more broken form (which has been improved upon somewhat
since). Who had never voiced a significant change in his position in any
subsequent discussions, IIRC.
So it's hard to blame Paul for the entirety of the problem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sun, 11 Jun 2017 10:05:02 GMT)
Full text and
rfc822 format available.
Message #300 received at 23425 <at> debbugs.gnu.org (full text, mbox):
Hello, Eli.
On Sat, Jun 10, 2017 at 16:39:33 +0300, Eli Zaretskii wrote:
> > It's a non backward-compatible change to a critical bit of Emacs.
> > `message' was previously a logical, strong function, and it has been
> > turned into a messy function which sort of works most of the time.
> IME, it [`message'] works quite well all of the time.
It does not work at all for outputting ` and '. Ugly workarounds are
required for that.
> Where it has some deficiencies, I'm sure we will with time improve it
> so it works even better. That's my experience in Emacs for many years.
If it doesn't get fixed now, it will never be fixed.
> And with that, I think it's high time to end this discussion.
How about fixing this bug first?
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23425; Package
emacs.
(Sun, 11 Jun 2017 14:39:02 GMT)
Full text and
rfc822 format available.
Message #303 received at 23425 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 11 Jun 2017 10:03:47 +0000
> Cc: deng <at> randomsample.de, eggert <at> cs.ucla.edu, 23425 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
>
> > IME, it [`message'] works quite well all of the time.
>
> It does not work at all for outputting ` and '. Ugly workarounds are
> required for that.
We will have to disagree on the ugliness part. Modulo that, it's
quite possible to output these two characters.
> > Where it has some deficiencies, I'm sure we will with time improve it
> > so it works even better. That's my experience in Emacs for many years.
>
> If it doesn't get fixed now, it will never be fixed.
It will, if we the motion to do that ever gets more support, or if we
find some grave problems we are not aware today.
> > And with that, I think it's high time to end this discussion.
>
> How about fixing this bug first?
I'm sorry, but I don't see anything that needs to be fixed at this
time.
Added tag(s) wontfix and notabug.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Tue, 20 Jun 2017 01:40:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
23425 <at> debbugs.gnu.org and Alan Mackenzie <acm <at> muc.de>
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Tue, 20 Jun 2017 01:40:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 18 Jul 2017 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 6 years and 284 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.