bug#31815: 27.0; Inappropriate use of curly quotes in `info.el'

bug#31815: 27.0; Inappropriate use of curly quotes in `info.el'

[Drew Adams]

In `info.el' there are three occurrences of this (these are curly quotes,
in case that doesn't come through in the bug-report system):

  Index for '%s'

They were all changed from this text:

  Index for `%s'

The latter text should be restored.  There is no reason to burden these
contexts with those Unicode curly quotes.  That just makes it harder for
a user to save the buffer text, requiring her to use a Unicode-friendly
encoding.

NOTE: I searched the top level of the Lisp sources, and it appears that
this problem is present there only in `info.el'.  It might also exist at
levels below directory `lisp', so that possibility should be checked.

In GNU Emacs 27.0.50 (build 3, x86_64-w64-mingw32)
 of 2018-03-21
Repository revision: e70d0c9e66d7a8609450b2889869d16aeb0363b5
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install -C 'CFLAGS=-O2 -static -g3''

bug#31815: 27.0; Inappropriate use of curly quotes in `info.el'

[Eli Zaretskii]

> Date: Wed, 13 Jun 2018 10:31:00 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> In `info.el' there are three occurrences of this (these are curly quotes,
> in case that doesn't come through in the bug-report system):
> 
>   Index for '%s'
> 
> They were all changed from this text:
> 
>   Index for `%s'
> 
> The latter text should be restored.

I don't understand what's so special in these 3 occurrences.  Info
buffers are full of curly quotes; the commands that use the above
generate Info buffers from portions of other Info buffers, and add a
header line.  So why should the header lines use different style of
quotes from the rest of the buffer?

bug#31815: 27.0; Inappropriate use of curly quotes in `info.el'

[Drew Adams]

> > In `info.el' there are three occurrences of this (these are curly
> > quotes, in case that doesn't come through in the bug-report system):
> >
> >   Index for '%s'
> >
> > They were all changed from this text:
> >
> >   Index for `%s'
> >
> > The latter text should be restored.
> 
> I don't understand what's so special in these 3 occurrences.
> Info
  ^^^^
> buffers are full of curly quotes; the commands that use the above
> generate Info buffers from portions of other Info buffers, and add a
> header line.  So why should the header lines use different style of
> quotes from the rest of the buffer?

I just got a copy of the control msg for this bug, saying
that it has been closed (I haven't received the usual help
msg for the bug filer saying that it was closed, however.)

The bug report was about the occurrence of such curly quotes
in the Lisp sources (`info.el'), not about their appearance
in Info files.  So your reply does not make sense to me.

I don't know an easy way to find all such occurrences in the
Lisp sources, since such chars cannot be searched for using
the `grep' I have.  There may well be other occurrences,
in subdirs of dir `lisp/'.

Bug #31807 has additional information about why this is
problematic: in some contexts one cannot easily copy+paste
source code that contains such chars.  In bug #31807 I
describe how I was bitten by this when trying to submit
a bug report.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31807#20

bug#31815: 27.0; Inappropriate use of curly quotes in `info.el'

[Noam Postavsky]

On 13 July 2018 at 11:57, Drew Adams <drew.adams@oracle.com> wrote:
>> > In `info.el' there are three occurrences of this (these are curly
>> > quotes, in case that doesn't come through in the bug-report system):
>> >
>> >   Index for '%s'
>> >
>> > They were all changed from this text:
>> >
>> >   Index for `%s'
>> >
>> > The latter text should be restored.
>>
>> I don't understand what's so special in these 3 occurrences.
>> Info
>   ^^^^
>> buffers are full of curly quotes; the commands that use the above
>> generate Info buffers from portions of other Info buffers, and add a
>> header line.  So why should the header lines use different style of
>> quotes from the rest of the buffer?
>
> I just got a copy of the control msg for this bug, saying
> that it has been closed (I haven't received the usual help
> msg for the bug filer saying that it was closed, however.)

Perhaps you misread the control message? I set the bug to severity
minor and tagged it notabug (to summarize Eli's response, which I
basically agree with), but I didn't close it, and looking at
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31815, it is not closed.

> The bug report was about the occurrence of such curly quotes
> in the Lisp sources (`info.el'), not about their appearance
> in Info files.  So your reply does not make sense to me.

The curly quotes in the source are there to produce curly quotes in
Info buffers. We want to produce curly quotes in info buffers to match
the rest of the buffer content which comes from Info files which have
curly quotes in them. Your suggestion to restore the ascii quotes
would produce a buffer of mixed quoting styles.

bug#31815: 27.0; Inappropriate use of curly quotes in `info.el'

[Drew Adams]

> > I just got a copy of the control msg for this bug, saying
> > that it has been closed (I haven't received the usual help
> > msg for the bug filer saying that it was closed, however.)
> 
> Perhaps you misread the control message? I set the bug to severity
> minor and tagged it notabug (to summarize Eli's response, which I
> basically agree with), but I didn't close it, and looking at...,
> it is not closed.

I see; thanks.  I didn't (still don't) understand the difference
between `notabug' and `closed'.  Is it wrong to assume that it
will be closed if it is not a bug?

> > The bug report was about the occurrence of such curly quotes
> > in the Lisp sources (`info.el'), not about their appearance
> > in Info files.  So your reply does not make sense to me.
> 
> The curly quotes in the source are there to produce curly quotes in
> Info buffers. We want to produce curly quotes in info buffers to match
> the rest of the buffer content which comes from Info files which have
> curly quotes in them. Your suggestion to restore the ascii quotes
> would produce a buffer of mixed quoting styles.

I didn't suggest restoring the quotes to non-curly in Info.

[Though I would like it for users to be able to control
whether Info uses curly quotes.  We've been through that
before: Apparently Texinfo doesn't give us a choice here,
so, for example, option ` text-quoting-style' has no
effect on Info.  Too bad, but not everything is as
flexible for users as is Emacs.]

I suggested restoring them in the Lisp source files, not
in Info buffers.  The source files need not use the chars
literally to produce them for Info, AFAIK.

---

To be clear: I'm not even sure just what copy+paste gotcha
I stumbled upon, when trying to report bug #31807.  I think
that other times I've been able to copy+paste such chars
into bug reports, without a problem of any kind of unexpected
conversion.  See that bug thread for more info, maybe.

bug#31815: 27.0; Inappropriate use of curly quotes in `info.el'

[Eli Zaretskii]

> Date: Fri, 13 Jul 2018 08:57:03 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 31815@debbugs.gnu.org
> 
> The bug report was about the occurrence of such curly quotes
> in the Lisp sources (`info.el'), not about their appearance
> in Info files.  So your reply does not make sense to me.

Why do you care about what is in the Lisp sources?  The Lisp sources
do whatever they need to do to produce appropriate contents in the
buffer they create.

> Bug #31807 has additional information about why this is
> problematic: in some contexts one cannot easily copy+paste
> source code that contains such chars.  In bug #31807 I
> describe how I was bitten by this when trying to submit
> a bug report.
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31807#20

Using these characters does have its downsides, so we use them as
little as possible in the sources.

bug#31815: 27.0; Inappropriate use of curly quotes in `info.el'

[Drew Adams]

> > The bug report was about the occurrence of such curly quotes
> > in the Lisp sources (`info.el'), not about their appearance
> > in Info files.  So your reply does not make sense to me.
> 
> Why do you care about what is in the Lisp sources?  The Lisp sources
> do whatever they need to do to produce appropriate contents in the
> buffer they create.

For the reason I gave: I copy and paste code from those
sources.

---

[A bigger bother is copying and pasting code or help
text from Emacs (e.g. `*Help*' or Info) to other
contexts where, say, `...` is used.  For example, I
often paste `*Help*' output into emacs.StackExchange
answers, and I spend time replacing each curly left
and right quote by `.  (Before the change to curliness
I had only to replace the ' by `, e.g., change `foobar'
to `foobar`.]

> Using these characters does have its downsides, so we
> use them as little as possible in the sources.

Thanks, for that.  Copy + paste and (perhaps) search
are the biggest bothers, I think.

bug#31815: 27.0; Inappropriate use of curly quotes in `info.el'

[Eli Zaretskii]

> Date: Fri, 13 Jul 2018 10:51:31 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 31815@debbugs.gnu.org
> 
> > > The bug report was about the occurrence of such curly quotes
> > > in the Lisp sources (`info.el'), not about their appearance
> > > in Info files.  So your reply does not make sense to me.
> > 
> > Why do you care about what is in the Lisp sources?  The Lisp sources
> > do whatever they need to do to produce appropriate contents in the
> > buffer they create.
> 
> For the reason I gave: I copy and paste code from those
> sources.

I'm sorry, but IMO this is not a valid reason for complaining about
the sources.  They should do their job, but otherwise all bets are
off.

bug#31815: 27.0; Inappropriate use of curly quotes in `info.el'

[Noam Postavsky]

Drew Adams <drew.adams@oracle.com> writes:

> I see; thanks.  I didn't (still don't) understand the difference
> between `notabug' and `closed'.  Is it wrong to assume that it
> will be closed if it is not a bug?

To the bug tracker, `notabug' is just an arbitrary tag.  It has no
direct relation to being closed or open.  For me, if I see the `notabug'
tag next to the "Inappropriate use of curly quotes in `info.el'" then
it's easier to remember that the current response is essentially "the
use of curly quotes is not inappropriate".  And if the bug is closed
later, then the `notabug' tag will remind that it's because we decided
use of curly quotes is okay, not that we removed said quotes.

In other words, I consider closing to have a connotation of finality
(even though it can also be reversed), so just tagging with `notabug'
without closing indicates a somewhat more tentative state.

> I didn't suggest restoring the quotes to non-curly in Info.

If you rephrase your suggestion as a patch, then we won't have to play
guessing games.

bug#31815: 27.0; Inappropriate use of curly quotes in `info.el'

[Drew Adams]

> > I didn't suggest restoring the quotes to non-curly in Info.
> 
> If you rephrase your suggestion as a patch, then we won't have to play
> guessing games.

What's to guess?  I said clearly in _each_ of my posts
to this bug thread, starting with the report itself,
that it's about the use of such chars in the Lisp source
files - in particular in `info.el'.

I mentioned that I tried to `grep' to see if other Lisp
files were similarly affected, and that it seemed that
`info.el' was the only one affected at the top level
of the source-code tree, at least.

Each time, I spoke of Lisp files and of `info.el'
specifically.  At no time did I talk about the presence
of curly quotes in Info buffers (we've been down that
dead-end road before).

That someone could misunderstand my message here is
not so simple, I think, but it is understandable - it
happens.  But to come back after it has been made
doubly clear and suggest that I somehow made you guess
what the problem is seems a bit unfair.

I don't know what kind of patch is needed.  And anyway
Eli has said that he doesn't see any reason to care
about users copy+pasting our Lisp source code. Won't
fix.

bug#31815: 27.0; Inappropriate use of curly quotes in `info.el'

[Noam Postavsky]

tags 31815 wontfix
close 31815
quit

Drew Adams <drew.adams@oracle.com> writes:

>> > I didn't suggest restoring the quotes to non-curly in Info.
>> 
>> If you rephrase your suggestion as a patch, then we won't have to play
>> guessing games.
>
> What's to guess?  I said clearly in _each_ of my posts
> to this bug thread, starting with the report itself,
> that it's about the use of such chars in the Lisp source
> files - in particular in `info.el'.

In the OP you said

    They were all changed from this text:

      Index for `%s'

    The latter text should be restored.

Which would affect the text in Info buffers (because it's the argument
to an `insert' call which is evaluated in an Info buffer).  I'm not sure
if you are just ignoring the effect of the change you propose, or you
have some additional changes in mind.

> And anyway Eli has said that he doesn't see any reason to care about
> users copy+pasting our Lisp source code. Won't fix.

Okay.

bug#31815: 27.0; Inappropriate use of curly quotes in `info.el'

[Drew Adams]

> >> > I didn't suggest restoring the quotes to non-curly in Info.
> >>
> >> If you rephrase your suggestion as a patch, then we won't have to
> >> play guessing games.
> >
> > What's to guess?  I said clearly in _each_ of my posts
> > to this bug thread, starting with the report itself,
> > that it's about the use of such chars in the Lisp source
> > files - in particular in `info.el'.
> 
> In the OP you said
>     They were all changed from this text:
>       Index for `%s'
>     The latter text should be restored.
> 
> Which would affect the text in Info buffers (because it's the argument
> to an `insert' call which is evaluated in an Info buffer).  I'm not sure
> if you are just ignoring the effect of the change you propose, or you
> have some additional changes in mind.

I've said multiple times, very clearly, that the _bug_, the
problem for users that is reported, is the presences of
curly quotes in Lisp source code.  It can make it difficult
for users who copy+paste such Lisp code.  And that statement
too is about curly quotes in Lisp source code.

The point is to not have those quotes in the Lisp source
code.  That does not imply that they cannot appear in Info.

Yes, technically, if "the latter text" is simply "restored"
then the Info text would be affected.

But that's not the point of the bug, as the context and the
several other mails in the thread all make clear, repeatedly.

There are other ways to get the effect of curly quotes in
Info than to insert that literal text.  It is clear from
the context that I was not proposing that only restoring
the exact same text in the Lisp code is an acceptable fix.

The point of a bug report is to state the problem, not to
prescribe a particular solution, and certainly not to claim
that there is only one possible solution.

The point of that text, which I think you should (and do?)
realize, is that the curly quotes should be removed from
the Lisp code.  Nothing more, nothing less.

I corrected a misinterpretation more than once in this
thread.  It's simply not about curly quotes in Info.
And it could not be, given that it has been stated that
Emacs has no control over the appearance of curly quotes
in Info (alas).

> > And anyway Eli has said that he doesn't see any reason to care about
> > users copy+pasting our Lisp source code. Won't fix.
> 
> Okay.

Not okay; too bad.

bug#31815: 27.0; Inappropriate use of curly quotes in `info.el'

[Noam Postavsky]

On 15 July 2018 at 18:09, Drew Adams <drew.adams@oracle.com> wrote:
>> I'm not sure
>> if you are just ignoring the effect of the change you propose, or you
>> have some additional changes in mind.

> It is clear from
> the context that I was not proposing that only restoring
> the exact same text in the Lisp code is an acceptable fix.

It wasn't clear to me.

> The point of a bug report is to state the problem

I wish you would follow this advice when making bug reports. For
example, in this report, instead of proposing a partial fix and
assuming that it's clear that you're asking for that restoration +
some other fix, ask something like: "these characters cause X problems
in scenario Y, is there an ASCII-only equivalent we can use?"

bug#31815: 27.0; Inappropriate use of curly quotes in `info.el'

[Drew Adams]

> > The point of a bug report is to state the problem
> 
> I wish you would follow this advice when making bug reports. For
> example, in this report, instead of proposing a partial fix and
> assuming that it's clear that you're asking for that restoration +
> some other fix, ask something like: "these characters cause X problems
> in scenario Y, is there an ASCII-only equivalent we can use?"

I agree.  I try to do that, and will try harder.  Sometimes
pointing toward what might be better can help make the problem
clearer.  And sometimes that bleeds over into what can sound
like a description of a solution (or even the solution).

For the record and future reference: That's never my intention.

Except when I might actually propose a solution (e.g. a patch),
I just report bugs.  And even when I might propose a solution
(e.g. patch) I don't insist on considerations that are purely
implementation, e.g., performance.

I might express an opinion about the effect on users of this
or that proposed solution, but I don't claim that code I offer
is the most performant etc. possible.

(I might also express a slight opinion about coding style,
names etc., readability etc., but again, such an opinion is
not so important.  I care about getting a bug fixed, not so
much about how it is fixed internally, i.e., in ways that
are not user-observable.  I do care to some extent about
the usability of the code itself, i.e., for users of the
code.)