unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* 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

* 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).