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

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

[Van L]

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

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

[Eli Zaretskii]

On May 28, 2018 6:56:56 AM GMT+03:00, Van L <van@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.

bug#31614: Off Topic (was: bug#31614)

[Van L]

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

bug#31614: Off Topic

[Noam Postavsky]

Van L <van@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.

bug#31614: Off Topic

[Van L]

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

bug#31614: Off Topic

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  31614@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.

bug#31614: Off Topic

[Noam Postavsky]

On 28 May 2018 at 11:18, Eli Zaretskii <eliz@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.

bug#31614: Off Topic (was: bug#31614)

[Eli Zaretskii]

> From: Van L <van@scratch.space>
> Date: Mon, 28 May 2018 21:05:35 +1000
> Cc: bug-gnu-emacs@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.

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

[Andreas Schwab]

On Mai 28 2018, Van L <van@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@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Mon, 28 May 2018 12:52:22 +0200
> Cc: 31614@debbugs.gnu.org
> 
> On Mai 28 2018, Van L <van@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.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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