GNU bug report logs - #31614
(texinfo) dfn - the double quotes around ``deleting'' are inconsistent with (eintr) Complications ``variables''

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31614 in the body.
You can then email your comments to 31614 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Van L <van <at> scratch.space>
To: bug-gnu-emacs <at> gnu.org
Subject: (texinfo) dfn - the double quotes around ``deleting'' are
 inconsistent with (eintr) Complications ``variables''
Date: Mon, 28 May 2018 13:56:56 +1000

Hello.

The beginning and ending double-quoting symbols are inconsistent for 

  1. (eintr) Complications ``variables''
  2. (texinfo) dfn ''deleting''

: 8cda6f8f (Glenn Morris             2007-09-06  1511) the symbol's value as a @dfn{variable}.  This situation is described

Looking up ``@dfn{variable}’’ in ``(texinfo) dfn’’ the double-quoting used in the line has

:      Getting rid of a file is called "deleting" it.

Expect the quoting symbol for open and close to be identical since both are being presented in Info page format.

See:

http://emacs.scratch.space/public/info-dfn-deleting-ugly-double-quotes.png

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org,Van L <van <at> scratch.space>,31614 <at> debbugs.gnu.org
Subject: Re: bug#31614: (texinfo) dfn - the double quotes around ``deleting''
 are	inconsistent with (eintr) Complications ``variables''
Date: Mon, 28 May 2018 11:55:38 +0300

On May 28, 2018 6:56:56 AM GMT+03:00, Van L <van <at> scratch.space> wrote:
> Hello.
> 
> The beginning and ending double-quoting symbols are inconsistent for 
> 
>   1. (eintr) Complications ``variables''
>   2. (texinfo) dfn ''deleting''
> 
> : 8cda6f8f (Glenn Morris             2007-09-06  1511) the symbol's
> value as a @dfn{variable}.  This situation is described
> 
> Looking up ``@dfn{variable}’’ in ``(texinfo) dfn’’ the double-quoting
> used in the line has
> 
> :      Getting rid of a file is called "deleting" it.
> 
> Expect the quoting symbol for open and close to be identical since
> both are being presented in Info page format.
> 
> See:
> 
> http://emacs.scratch.space/public/info-dfn-deleting-ugly-double-quotes.png

You are saying that the Texinfo manual uses ASCII quotes, and therefore
the opening and closing quotes are identical?  If so, the place to
complain about that is the Texinfo mailing list.  There's nothing wrong
that I could spot wrt quotes in the Lisp Intro manual.

Thanks.

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Van L <van <at> scratch.space>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Off Topic (was: bug#31614)
Date: Mon, 28 May 2018 21:05:35 +1000

> Eli Zaretskii writes:
> 
> You are saying that the Texinfo manual uses ASCII quotes, and therefore
> the opening and closing quotes are identical?  If so, the place to
> complain about that is the Texinfo mailing list.

The point of TeX is beautiful typesetting.

I don’t want to create another bug report for why

  (+ 2 2) 

gives the ``complication’’ by default

  4 (#o4, #x4, ?\C-d)

and not the simple

  4

Emacs 26.1-rc1 (NS Port) and Emacs 25.3 (Mac Port) both produce

  4 (#o4, #x4, ?\C-d)

In the below, it is not possible to set 
`eval-expression-print-maximum-character’ to `nil’ to 
achieve the simple `4’ result. 
`M-x customize’ wants a number for 26.1-rc1 and the default is 127. 

  #+NAME: simple.el.gz
  #+BEGIN_SRC elisp n=1535
    If the resulting value is an integer, and CHAR-PRINT-LIMIT is
    non-nil (interactively, unless given a positive prefix argument)
    it will be printed in several additional formats (octal,
    hexadecimal, and character).  The character format is only used
    if the value is below CHAR-PRINT-LIMIT (interactively, if the
    prefix argument is -1 or the value is below
    `eval-expression-print-maximum-character').

  #+END_SRC

  #+NAME: eval-expression-print-maximum-character
  #+BEGIN_EXAMPLE
    eval-expression-print-maximum-character is a variable defined in ‘simple.el’.
    Its value is 127

    Documentation:
    The largest integer that will be displayed as a character.
    This affects printing by ‘eval-expression’ (via
    ‘eval-expression-print-format’).

    You can customize this variable.

    This variable was introduced, or its default value was changed, in
    version 26.1 of Emacs.

  #+END_EXAMPLE

The backtrace diff I submitted in another bug needs undoing 
because I believe the simple `4' result is better to keep in the earlier lisp intro.

Details about ``complications’’ is bulk the lisp intro can separate into a different book. 

Message #17 received at 31614 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Van L <van <at> scratch.space>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 31614 <at> debbugs.gnu.org
Subject: Re: bug#31614: Off Topic
Date: Mon, 28 May 2018 07:30:11 -0400

Van L <van <at> scratch.space> writes:

> I don’t want to create another bug report for why

There's not really a reason not to, we won't run out of bug numbers.

>   (+ 2 2) 
>
> gives the ``complication’’ by default
>
>   4 (#o4, #x4, ?\C-d)
>
> and not the simple
>
>   4
>
> Emacs 26.1-rc1 (NS Port) and Emacs 25.3 (Mac Port) both produce
>
>   4 (#o4, #x4, ?\C-d)
>
> In the below, it is not possible to set 
> `eval-expression-print-maximum-character’ to `nil’ to 
> achieve the simple `4’ result.

Oh, I think I intended eval-expression-print-maximum-character to only
affect the ?\C-d part, e.g., if you set it to 0, you get

    4 (#o4, #x4)

But I see there is no way to get a plain '4' except by (setq
eval-expression-print-maximum-character nil), which is kind of an
accident.

Message #20 received at 31614 <at> debbugs.gnu.org (full text, mbox):

From: Van L <van <at> scratch.space>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 31614 <at> debbugs.gnu.org
Subject: Re: bug#31614: Off Topic
Date: Mon, 28 May 2018 23:04:34 +1000

> Noam Postavsky writes:
> 
>> I don’t want to create another bug report for why
> 
> There's not really a reason not to, we won't run out of bug numbers.

I felt this one wasn’t so much a bug but a ``quality'' disappointment.

After a walk, maybe the identical ascii double quote at both ends is an inside joke worth “deleting” (but my mail app won’t let me use those quotes here).

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Van L <van <at> scratch.space>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: Off Topic (was: bug#31614)
Date: Mon, 28 May 2018 18:15:52 +0300

> From: Van L <van <at> scratch.space>
> Date: Mon, 28 May 2018 21:05:35 +1000
> Cc: bug-gnu-emacs <at> gnu.org
> 
> > Eli Zaretskii writes:
> > 
> > You are saying that the Texinfo manual uses ASCII quotes, and therefore
> > the opening and closing quotes are identical?  If so, the place to
> > complain about that is the Texinfo mailing list.
> 
> The point of TeX is beautiful typesetting.

Yes, it is.  But whether makeinfo produces the curved quotes and other
non-ASCII characters can be controlled by the Texinfo source files,
and the Texinfo project evidently decided not to produce Info files
with non-ASCII characters, while Emacs made the opposite decision.  So
it's their decision, and if you want to convince them to change it,
you need to talk to them, as Texinfo is a separate project.

> Emacs 26.1-rc1 (NS Port) and Emacs 25.3 (Mac Port) both produce
> 
>   4 (#o4, #x4, ?\C-d)
> 
> In the below, it is not possible to set 
> `eval-expression-print-maximum-character’ to `nil’ to 
> achieve the simple `4’ result. 
> `M-x customize’ wants a number for 26.1-rc1 and the default is 127. 

AFAIR, we never had such a feature, and the name of the option even
hints that all it controls is the character representation of the
integer number, as does its doc string.

> The backtrace diff I submitted in another bug needs undoing 
> because I believe the simple `4' result is better to keep in the earlier lisp intro.

I don't think it's a good idea to mix Emacs customization with the
Lisp programming introduction.  I described the additional
representation of the value in a footnote, and I think this is good
enough for that place to get the reader past the complication.  If we
start talking about customizing this display, we will risk losing the
main point of that node.

Message #26 received at 31614 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: van <at> scratch.space, 31614 <at> debbugs.gnu.org
Subject: Re: bug#31614: Off Topic
Date: Mon, 28 May 2018 18:18:21 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  31614 <at> debbugs.gnu.org
> Date: Mon, 28 May 2018 07:30:11 -0400
> 
> >   4 (#o4, #x4, ?\C-d)
> >
> > In the below, it is not possible to set 
> > `eval-expression-print-maximum-character’ to `nil’ to 
> > achieve the simple `4’ result.
> 
> Oh, I think I intended eval-expression-print-maximum-character to only
> affect the ?\C-d part, e.g., if you set it to 0, you get

Indeed, this feature was only about showing the character, mainly
because for large enough value the display could be annoyingly delayed
while Emacs looks for a suitable font.

>     4 (#o4, #x4)
> 
> But I see there is no way to get a plain '4' except by (setq
> eval-expression-print-maximum-character nil), which is kind of an
> accident.

I don't think it's an accident, I think it's a very useful feature, as
one doesn't need to format the value specially when one needs hex or
octal string representation.

Message #29 received at 31614 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> suse.de>
To: Van L <van <at> scratch.space>
Cc: 31614 <at> debbugs.gnu.org
Subject: Re: bug#31614: (texinfo) dfn - the double quotes around ``deleting''
 are inconsistent with (eintr) Complications ``variables''
Date: Mon, 28 May 2018 12:52:22 +0200

On Mai 28 2018, Van L <van <at> scratch.space> wrote:

>   1. (eintr) Complications ``variables''
>   2. (texinfo) dfn ''deleting''

The manuals are created with different makeinfo versions.

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."

Message #32 received at 31614 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Van L <van <at> scratch.space>, 31614 <at> debbugs.gnu.org
Subject: Re: bug#31614: Off Topic
Date: Mon, 28 May 2018 11:37:16 -0400

On 28 May 2018 at 11:18, Eli Zaretskii <eliz <at> gnu.org> wrote:

>> But I see there is no way to get a plain '4' except by (setq
>> eval-expression-print-maximum-character nil), which is kind of an
>> accident.
>
> I don't think it's an accident, I think it's a very useful feature, as
> one doesn't need to format the value specially when one needs hex or
> octal string representation.

I mean, it's an accident that setting that variable to nil causes C-x
C-e to not echo hex or octal.

Message #35 received at 31614 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> suse.de>
Cc: van <at> scratch.space, 31614 <at> debbugs.gnu.org
Subject: Re: bug#31614: (texinfo) dfn - the double quotes around ``deleting''
 are inconsistent with (eintr) Complications ``variables''
Date: Mon, 28 May 2018 19:17:40 +0300

> From: Andreas Schwab <schwab <at> suse.de>
> Date: Mon, 28 May 2018 12:52:22 +0200
> Cc: 31614 <at> debbugs.gnu.org
> 
> On Mai 28 2018, Van L <van <at> scratch.space> wrote:
> 
> >   1. (eintr) Complications ``variables''
> >   2. (texinfo) dfn ''deleting''
> 
> The manuals are created with different makeinfo versions.

Actually, the Texinfo manual is traditionally produced using the same
version of Texinfo as the one described in the manual.  In the case of
the latest version, it's Texinfo 6.5, the latest version.

AFAIK, the cause of the difference in quoting style is that the
Texinfo manual doesn't use any @documentencoding directive, so the
output is plain-ASCII.

Message #38 received at 31614 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: van <at> scratch.space, Andreas Schwab <schwab <at> suse.de>, 31614 <at> debbugs.gnu.org
Subject: Re: bug#31614: (texinfo) dfn - the double quotes around
 ``deleting'' are inconsistent with (eintr) Complications ``variables''
Date: Mon, 07 Feb 2022 11:06:07 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> AFAIK, the cause of the difference in quoting style is that the
> Texinfo manual doesn't use any @documentencoding directive, so the
> output is plain-ASCII.

Skimming this thread, it seems like there's nothing to do on the Emacs
side, so I'm closing this bug report.  If I misunderstood, please
respond to the debbugs address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.