* bug#31597: 27.0.50; Annoying ' to ’ translation @ 2018-05-25 20:46 Helmut Eller 2018-05-25 21:31 ` Tomas Nordin [not found] ` <mailman.494.1527281229.1292.bug-gnu-emacs@gnu.org> 0 siblings, 2 replies; 9+ messages in thread From: Helmut Eller @ 2018-05-25 20:46 UTC (permalink / raw) To: 31597 Executing this command: emacs -Q -batch -eval "(error \"can't parse input\")" prints can’t parse input I would expect to see "can't parse input" instead. Had I wanted to see a "can’t parse input" in the output, I would have written "can’t parse input" in the source. Emacs should not do this translation by default; this new behavior is a misfeature. It's extremely annoying that the behavior of such basic functions as error and message has changed so drastically from previous Emacs versions. People who like this automagic translation should be forced to customize text-quoting-style not the people who want the traditional and much more predictable behavior. In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.11) of 2018-05-07 built on caladan Repository revision: 6e362a32bc9d21f73a0f29ca6f45481edeea6f29 Windowing system distributor 'The X.Org Foundation', version 11.0.11902000 System Description: Debian GNU/Linux 9 (stretch) Configured using: 'configure --with-xpm=no --with-gif=no --with-tiff=no --with-jpeg=no --without-pop' Configured features: PNG SOUND DBUS GSETTINGS NOTIFY GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 THREADS LIBSYSTEMD Important settings: value of $LANG: C.UTF-8 locale-coding-system: utf-8-unix ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#31597: 27.0.50; Annoying ' to ’ translation 2018-05-25 20:46 bug#31597: 27.0.50; Annoying ' to ’ translation Helmut Eller @ 2018-05-25 21:31 ` Tomas Nordin 2018-05-25 21:33 ` Tomas Nordin [not found] ` <mailman.494.1527281229.1292.bug-gnu-emacs@gnu.org> 1 sibling, 1 reply; 9+ messages in thread From: Tomas Nordin @ 2018-05-25 21:31 UTC (permalink / raw) To: Helmut Eller, 31597 Helmut Eller <eller.helmut@gmail.com> writes: > Executing this command: > > emacs -Q -batch -eval "(error \"can't parse input\")" > I would guess that what is passed to emacs as a value to -eval after this command is (error "can't parse input") > prints > > can’t parse input which then is expected? On the other hand, if I have this variable in bash: $ echo $message (error "\"can't parse input\"") and execute $ emacs -Q -batch -eval "$message" I get "can’t parse input" It's a fiddle but seems normal to me. Emacs 27.0.50 here. Best regards -- Tomas ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#31597: 27.0.50; Annoying ' to ’ translation 2018-05-25 21:31 ` Tomas Nordin @ 2018-05-25 21:33 ` Tomas Nordin 0 siblings, 0 replies; 9+ messages in thread From: Tomas Nordin @ 2018-05-25 21:33 UTC (permalink / raw) To: Helmut Eller, 31597 Sorry, I failed to read the subject of your report, please ignore my noise. Tomas Nordin <tomasn@posteo.net> writes: > Helmut Eller <eller.helmut@gmail.com> writes: > >> Executing this command: >> >> emacs -Q -batch -eval "(error \"can't parse input\")" >> > > I would guess that what is passed to emacs as a value to -eval after > this command is > > (error "can't parse input") > >> prints >> >> can’t parse input > > which then is expected? > > On the other hand, if I have this variable in bash: > > $ echo $message > (error "\"can't parse input\"") > > and execute > > $ emacs -Q -batch -eval "$message" > > I get > > "can’t parse input" > > It's a fiddle but seems normal to me. Emacs 27.0.50 here. > > Best regards > -- > Tomas ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <mailman.494.1527281229.1292.bug-gnu-emacs@gnu.org>]
* bug#31597: 27.0.50; Annoying ' to ’ translation [not found] ` <mailman.494.1527281229.1292.bug-gnu-emacs@gnu.org> @ 2018-05-27 9:32 ` Alan Mackenzie 2018-05-27 16:04 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: Alan Mackenzie @ 2018-05-27 9:32 UTC (permalink / raw) To: Helmut Eller; +Cc: 31597 Hello, Helmut. In article <mailman.494.1527281229.1292.bug-gnu-emacs@gnu.org> you wrote: > Executing this command: > emacs -Q -batch -eval "(error \"can't parse input\")" > prints > can’t parse input > I would expect to see "can't parse input" instead. > Had I wanted to see a "can’t parse input" in the output, I would have > written "can’t parse input" in the source. Emacs should not do this > translation by default; this new behavior is a misfeature. Yes. It's a misfeature indeed. It's already caused a lot of bad feeling amongst Emacs developers. The person behind the change, Paul Eggert, simply pushed it through without first securing agreement from Emacs as a whole, and had the political skills to prevent a consensus on the matter prevailing. I think he regards it as "modern and desirable" to display what he thinks the programmer wanted, rather than what the programmer actually wrote. As for actually polling users, such as yourself, first? Hmmm. > It's extremely annoying that the behavior of such basic functions as > error and message has changed so drastically from previous Emacs > versions. People who like this automagic translation should be forced > to customize text-quoting-style not the people who want the traditional > and much more predictable behavior. Yes. But no, such a strategem would be "incompatible" with the way things were when rushed through for Emacs 25. I did my best to make the nil value of text-quoting-style mean "do nothing", but was overruled, again on grounds of "compatibility". So, you're not the first to suffer from this misfeature, and you'll certainly not be the last. I think it vanishingly unlikely that it will be fixed. Sorry. > In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.11) > of 2018-05-07 built on caladan > Repository revision: 6e362a32bc9d21f73a0f29ca6f45481edeea6f29 > Windowing system distributor 'The X.Org Foundation', version 11.0.11902000 > System Description: Debian GNU/Linux 9 (stretch) > Configured using: > 'configure --with-xpm=no --with-gif=no --with-tiff=no --with-jpeg=no > --without-pop' > Configured features: > PNG SOUND DBUS GSETTINGS NOTIFY GNUTLS LIBXML2 FREETYPE XFT ZLIB > TOOLKIT_SCROLL_BARS GTK3 X11 THREADS LIBSYSTEMD > Important settings: > value of $LANG: C.UTF-8 > locale-coding-system: utf-8-unix -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#31597: 27.0.50; Annoying ' to ’ translation 2018-05-27 9:32 ` Alan Mackenzie @ 2018-05-27 16:04 ` Eli Zaretskii 2018-05-27 17:12 ` Alan Mackenzie 0 siblings, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2018-05-27 16:04 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 31597, eller.helmut > Date: 27 May 2018 09:32:15 -0000 > From: Alan Mackenzie <acm@muc.de> > Cc: 31597@debbugs.gnu.org > > The person behind the change, Paul Eggert, simply pushed it through > without first securing agreement from Emacs as a whole, and had the > political skills to prevent a consensus on the matter prevailing. This misrepresents what Paul did and say, and I think is grossly unfair to him. I wish we avoided such ad-hominem attacks, just because we disagree. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#31597: 27.0.50; Annoying ' to ’ translation 2018-05-27 16:04 ` Eli Zaretskii @ 2018-05-27 17:12 ` Alan Mackenzie 2018-05-27 17:42 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: Alan Mackenzie @ 2018-05-27 17:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 31597, eller.helmut Hello, Eli. On Sun, May 27, 2018 at 19:04:02 +0300, Eli Zaretskii wrote: > > Date: 27 May 2018 09:32:15 -0000 > > From: Alan Mackenzie <acm@muc.de> > > Cc: 31597@debbugs.gnu.org > > The person behind the change, Paul Eggert, simply pushed it through > > without first securing agreement from Emacs as a whole, and had the > > political skills to prevent a consensus on the matter prevailing. > This misrepresents what Paul did and say, and I think is grossly > unfair to him. This was a highly controversial change. Paul could first have committed the changes on a branch and invited comment. This is, for example, what you did recently when implementing visible line numbers in buffers. It is a correct and considerate way of working. Paul did not do this. He blasted his changes directly onto master. Some of these changes were outrageous, such as forcing the replacement of quotes by curly quotes without the user having an option to disable this replacement. You weren't really involved in the fight against this. I was, and it exhausted me. > I wish we avoided such ad-hominem attacks, just because we disagree. Eli, my view of things is NOT an ad-hominem. An ad-hominem is when one argues by attacking a _person_. My paragraph above does not do this: it criticizes Paul's _actions_. I think it is a fair summary of what actually happened. And I think it is pertinent to the message of my message, namely that this attribute of Emacs which so annoys Helmut is not going to get fixed. Ever. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#31597: 27.0.50; Annoying ' to ’ translation 2018-05-27 17:12 ` Alan Mackenzie @ 2018-05-27 17:42 ` Eli Zaretskii 2018-05-27 19:33 ` Alan Mackenzie 0 siblings, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2018-05-27 17:42 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 31597, eller.helmut > Date: Sun, 27 May 2018 17:12:17 +0000 > Cc: eller.helmut@gmail.com, 31597@debbugs.gnu.org > From: Alan Mackenzie <acm@muc.de> > > > > The person behind the change, Paul Eggert, simply pushed it through > > > without first securing agreement from Emacs as a whole, and had the > > > political skills to prevent a consensus on the matter prevailing. > > > This misrepresents what Paul did and say, and I think is grossly > > unfair to him. > > This was a highly controversial change. Paul could first have committed > the changes on a branch and invited comment. Saying this is a far cry from accusing Paul in nasty political tricks and in deliberately sneaking controversial code behind our backs. > You weren't really involved in the fight against this. I was, and it > exhausted me. I hear you, and you should know very well that I'm not too enthusiastic about this change, either. But we should be able to disagree without name-calling. > > I wish we avoided such ad-hominem attacks, just because we disagree. > > Eli, my view of things is NOT an ad-hominem. An ad-hominem is when one > argues by attacking a _person_. My paragraph above does not do this: it > criticizes Paul's _actions_. I think it is a fair summary of what > actually happened. The wording you've chosen to do that is what I hope we could avoid. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#31597: 27.0.50; Annoying ' to ’ translation 2018-05-27 17:42 ` Eli Zaretskii @ 2018-05-27 19:33 ` Alan Mackenzie 2018-05-27 22:23 ` Noam Postavsky 0 siblings, 1 reply; 9+ messages in thread From: Alan Mackenzie @ 2018-05-27 19:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 31597, eller.helmut Hello, Eli. On Sun, May 27, 2018 at 20:42:53 +0300, Eli Zaretskii wrote: > > Date: Sun, 27 May 2018 17:12:17 +0000 > > Cc: eller.helmut@gmail.com, 31597@debbugs.gnu.org > > From: Alan Mackenzie <acm@muc.de> > > > > The person behind the change, Paul Eggert, simply pushed it through > > > > without first securing agreement from Emacs as a whole, and had the > > > > political skills to prevent a consensus on the matter prevailing. > > > This misrepresents what Paul did and say, and I think is grossly > > > unfair to him. > > This was a highly controversial change. Paul could first have committed > > the changes on a branch and invited comment. > Saying this is a far cry from accusing Paul in nasty political tricks > and in deliberately sneaking controversial code behind our backs. He sneaked in this code in front of our noses, but none of us really appreciated what was going on. I certainly didn't (until later). > > You weren't really involved in the fight against this. I was, and it > > exhausted me. > I hear you, and you should know very well that I'm not too > enthusiastic about this change, either. But we should be able to > disagree without name-calling. It was me that rolled with the punches. Soon after this thing started, I committed an "emergency" user option to allow people to disable this forced character substitution. Within hours, this option had been "polluted" so as not quite to work. And shortly before Emacs 25 was released, the option was quietly degraded to a non-option variable, which one of the manuals said was for "advanced use" only. This is the sort of manoevering I was up against. (The option is now back in Emacs 26.) > > > I wish we avoided such ad-hominem attacks, just because we disagree. > > Eli, my view of things is NOT an ad-hominem. An ad-hominem is when one > > argues by attacking a _person_. My paragraph above does not do this: it > > criticizes Paul's _actions_. I think it is a fair summary of what > > actually happened. > The wording you've chosen to do that is what I hope we could avoid. OK. But I don't think it's healthy to pretend that the above didn't happen, and that everybody is kind, considerate, and respectful to everybody else all the time. I don't think either of us want anything like this to happen again. I would hope that, in future, all controversial changes get argued out first, and if committed to the repository, they go on a branch first. And the OP, Helmut Eller, deserves an explanation of how the current state of affairs, which he has reported as a bug, came about. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#31597: 27.0.50; Annoying ' to ’ translation 2018-05-27 19:33 ` Alan Mackenzie @ 2018-05-27 22:23 ` Noam Postavsky 0 siblings, 0 replies; 9+ messages in thread From: Noam Postavsky @ 2018-05-27 22:23 UTC (permalink / raw) To: Alan Mackenzie; +Cc: eller.helmut, 31597 Alan Mackenzie <acm@muc.de> writes: > I would hope that, in future, all controversial changes get argued out > first, and if committed to the repository, they go on a branch first. The problem lies in how controversial changes should be identified. It's "obvious" to you that the quote translation thing would be controversial, but Paul didn't see that until afterwards. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-05-27 22:23 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-05-25 20:46 bug#31597: 27.0.50; Annoying ' to ’ translation Helmut Eller 2018-05-25 21:31 ` Tomas Nordin 2018-05-25 21:33 ` Tomas Nordin [not found] ` <mailman.494.1527281229.1292.bug-gnu-emacs@gnu.org> 2018-05-27 9:32 ` Alan Mackenzie 2018-05-27 16:04 ` Eli Zaretskii 2018-05-27 17:12 ` Alan Mackenzie 2018-05-27 17:42 ` Eli Zaretskii 2018-05-27 19:33 ` Alan Mackenzie 2018-05-27 22:23 ` Noam Postavsky
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).