bug#26299: 24.5; Use of `…' in Info

bug#26299: 24.5; Use of `…' in Info

[Drew Adams]

As one user, I find the adoption of `…' instead of `...' to be a
retrogression, not an improvement.  It is far less readable.  Just one
opinion.

Compare, as one example among zillions:

 -- Macro: with-help-window buffer-name body…

with

 -- Macro: with-help-window buffer-name body...

I cannot imagine what someone thought, when making this change.  Did it
come just because we _can_ now use that Unicode character?  That's not
a reason that we _should_ use it in such contexts.

In GNU Emacs 24.5.1 (i686-pc-mingw32)
 of 2015-04-11 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=3D/c/usr --host=3Di686-pc-mingw32'

bug#26299: 24.5; Use of `…' in Info

[npostavs]

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

> As one user, I find the adoption of `…' instead of `...' to be a
> retrogression, not an improvement.  It is far less readable.  Just one
> opinion.
>
> Compare, as one example among zillions:
>
>  -- Macro: with-help-window buffer-name body…
>
> with
>
>  -- Macro: with-help-window buffer-name body...
>
> I cannot imagine what someone thought, when making this change.  Did it
> come just because we _can_ now use that Unicode character?  That's not
> a reason that we _should_ use it in such contexts.

This seems to be another feature of the new (i.e., 5+) texinfo (like the
curly quotes).  I'm still using 4.13 so I see "..." here.  You can make
Emacs display "…" as "..." with

    (aset (or standard-display-table
              (setq standard-display-table (make-display-table)))
          ?… (vconcat "..."))

bug#26299: 24.5; Use of `…' in Info

[Drew Adams]

> > As one user, I find the adoption of `…' instead of `...' to be a
> > retrogression, not an improvement.  It is far less readable.  Just one
> > opinion.
> >
> > Compare, as one example among zillions:
> >  -- Macro: with-help-window buffer-name body…
> > with
> >  -- Macro: with-help-window buffer-name body...
> >
> > I cannot imagine what someone thought, when making this change.  Did it
> > come just because we _can_ now use that Unicode character?  That's not
> > a reason that we _should_ use it in such contexts.
> 
> This seems to be another feature of the new (i.e., 5+) texinfo (like the
> curly quotes).  I'm still using 4.13 so I see "..." here.  You can make
> Emacs display "…" as "..." with
> 
>     (aset (or standard-display-table
>               (setq standard-display-table (make-display-table)))
>           ?… (vconcat "..."))

Thanks for tracking down the cause.

It's not about fixing the regressive appearance just for me.
It's about Emacs users.

Maybe Emacs needs to work around the problem (if it can't be
fixed).  Maybe if Emacs uses `. . .' instead of `...' that
will stop Texinfo from messing with it.

(Why would Texinfo have a blanket treatment of ... as …?
That makes no sense at all.  What if the occurrence of ...
is part of code, and NEEDS to be 3 period chars?)

bug#26299: 24.5; Use of `…' in Info

[Noam Postavsky]

On Thu, Mar 30, 2017 at 9:49 AM, Drew Adams <drew.adams@oracle.com> wrote:
>
> Maybe Emacs needs to work around the problem (if it can't be
> fixed).  Maybe if Emacs uses `. . .' instead of `...' that
> will stop Texinfo from messing with it.
>
> (Why would Texinfo have a blanket treatment of ... as …?
> That makes no sense at all.  What if the occurrence of ...
> is part of code, and NEEDS to be 3 period chars?)

Emacs' .texi files use @dots{} in these cases, as (strongly)
recommended by the texinfo manual:

https://www.gnu.org/software/texinfo/manual/texinfo/html_node/_0040dots.html

    An ellipsis (a sequence of dots) would be spaced wrong when typeset as
    a string of periods, so a special command is used in Texinfo: use the
    @dots{} command to generate a normal ellipsis, which is three dots in
    a row, appropriately spaced … like so. To emphasize: do not simply
    write three periods in the input file; that would work for the Info
    file output, but would produce the wrong amount of space between the
    periods in the printed manual.

I found this thread [1] requesting plain "..." for @dots{} in makeinfo
output; there seemed to be no opposition, but I guess it didn't
happen. Perhaps try pinging bug-texinfo@gnu.org?

[1]: https://lists.gnu.org/archive/html/bug-texinfo/2015-07/msg00013.html

bug#26299: 24.5; Use of `…' in Info

[Drew Adams]

> > Maybe Emacs needs to work around the problem (if it can't be
> > fixed).  Maybe if Emacs uses `. . .' instead of `...' that
> > will stop Texinfo from messing with it.
> >
> > (Why would Texinfo have a blanket treatment of ... as …?
> > That makes no sense at all.  What if the occurrence of ...
> > is part of code, and NEEDS to be 3 period chars?)
> 
> Emacs' .texi files use @dots{} in these cases, as (strongly)
> recommended by the texinfo manual:
> 
>     An ellipsis (a sequence of dots) would be spaced wrong when typeset as
>     a string of periods, so a special command is used in Texinfo: use the
>     @dots{} command to generate a normal ellipsis, which is three dots in
>     a row, appropriately spaced … like so. To emphasize: do not simply
>     write three periods in the input file; that would work for the Info
>     file output, but would produce the wrong amount of space between the
>     periods in the printed manual.
> 
> I found this thread [1] requesting plain "..." for @dots{} in makeinfo
> output; there seemed to be no opposition, but I guess it didn't
> happen. Perhaps try pinging bug-texinfo@gnu.org?

Thanks for checking on this, Noam.  I will leave it to Emacs
maintainers to decide whether to ping bug-texinfo.  I reported
the complaint as one Emacs user.  Dunno what Emacs Dev will
decide is the desired behavior.  I know what I prefer.

bug#26299: 24.5; Use of `…' in Info

[Drew Adams]

[-- Attachment #1.1: Type: text/plain, Size: 2362 bytes --]

> > > Maybe Emacs needs to work around the problem (if it can't be

> > > fixed).  Maybe if Emacs uses `. . .' instead of `...' that

> > > will stop Texinfo from messing with it.

> > >

> > > (Why would Texinfo have a blanket treatment of ... as …?

> > > That makes no sense at all.  What if the occurrence of ...

> > > is part of code, and NEEDS to be 3 period chars?)

> >

> > Emacs' .texi files use @dots{} in these cases, as (strongly)

> > recommended by the texinfo manual:

> >

> >     An ellipsis (a sequence of dots) would be spaced wrong when typeset as

> >     a string of periods, so a special command is used in Texinfo: use the

> >     @dots{} command to generate a normal ellipsis, which is three dots in

> >     a row, appropriately spaced … like so. To emphasize: do not simply

> >     write three periods in the input file; that would work for the Info

> >     file output, but would produce the wrong amount of space between the

> >     periods in the printed manual.

> >

> > I found this thread [1] requesting plain "..." for @dots{} in makeinfo

> > output; there seemed to be no opposition, but I guess it didn't

> > happen. Perhaps try pinging bug-texinfo@gnu.org?

> 

> Thanks for checking on this, Noam.  I will leave it to Emacs

> maintainers to decide whether to ping bug-texinfo.  I reported

> the complaint as one Emacs user.  Dunno what Emacs Dev will

> decide is the desired behavior.  I know what I prefer.

 

Dunno whether you want a separate bug report for this, but here

is a related problem that is even worse, IMO: The character

RIGHTWARDS ARROW FROM BAR (#x421) is no good in Info, at least

in some fonts. It is too narrow.  Previously Emacs used `==>'

instead of that char. See attached screenshot, where the font

is (for some reason):

-outline-MS Gothic-normal-normal-normal-mono-14-*-*-*-c-*-jisx0208*-*

 

The font for the rest of the chars in that screenshot is:

-outline-Lucida Console-normal-normal-normal-mono-14-*-*-*-c-*-iso8859-1.

 

Don't ask me why Emacs uses that font for that char - I have no

idea.  (And yes, to Eli's typical response to questions about

fonts for odd chars, I do have Symbola installed.  But Emacs

doesn't seem to use it, here.)

[-- Attachment #1.2: Type: text/html, Size: 7939 bytes --]

[-- Attachment #2: throw-emacs-bug-26299.png --]
[-- Type: image/png, Size: 23055 bytes --]

bug#26299: 24.5; Use of `…' in Info

[Eli Zaretskii]

> Date: Sun, 11 Jun 2017 19:49:08 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 26299@debbugs.gnu.org
> 
> Dunno whether you want a separate bug report for this, but here
> is a related problem that is even worse, IMO: The character
> RIGHTWARDS ARROW FROM BAR (#x421) is no good in Info, at least
> in some fonts. It is too narrow. Previously Emacs used `==>'
> instead of that char. See attached screenshot, where the font
> is (for some reason):
> -outline-MS Gothic-normal-normal-normal-mono-14-*-*-*-c-*-jisx0208*-*
> The font for the rest of the chars in that screenshot is:
> -outline-Lucida Console-normal-normal-normal-mono-14-*-*-*-c-*-iso8859-1.
> Don't ask me why Emacs uses that font for that char - I have no
> idea. (And yes, to Eli's typical response to questions about
> fonts for odd chars, I do have Symbola installed. But Emacs
> doesn't seem to use it, here.)

Granted, I cannot reproduce this.  I tried on 2 systems, and on both
this character (whose codepoint is #x21a6, btw, not #x421) is
displayed using Symbola.

Does this happen for you in "emacs -Q" as well?  If not, can you tell
what customizations related to fonts or faces do you have that could
cause this?

If "emacs -Q" shows the same problem, then I guess it's some issue
related to what fonts you have installed (e.g., could it be that your
Symbola is outdated and doesn't cover that character?) or something
like that.  I could propose a couple of solutions if that is the case,
if you want to solve it locally.

bug#26299: 24.5; Use of `…' in Info

[Drew Adams]

> > Dunno whether you want a separate bug report for this, but here
> > is a related problem that is even worse, IMO: The character
> > RIGHTWARDS ARROW FROM BAR (#x421) is no good in Info, at least
> > in some fonts. It is too narrow. Previously Emacs used `==>'
> > instead of that char. See attached screenshot, where the font
> > is (for some reason):
> > -outline-MS Gothic-normal-normal-normal-mono-14-*-*-*-c-*-jisx0208*-*
> > The font for the rest of the chars in that screenshot is:
> > -outline-Lucida Console-normal-normal-normal-mono-14-*-*-*-c-*-iso8859-1.
> > Don't ask me why Emacs uses that font for that char - I have no
> > idea. (And yes, to Eli's typical response to questions about
> > fonts for odd chars, I do have Symbola installed. But Emacs
> > doesn't seem to use it, here.)
> 
> Granted, I cannot reproduce this.  I tried on 2 systems, and on both
> this character (whose codepoint is #x21a6, btw, not #x421) is
> displayed using Symbola.
> 
> Does this happen for you in "emacs -Q" as well?  If not, can you tell
> what customizations related to fonts or faces do you have that could
> cause this?
> 
> If "emacs -Q" shows the same problem, then I guess it's some issue
> related to what fonts you have installed (e.g., could it be that your
> Symbola is outdated and doesn't cover that character?) or something
> like that.  I could propose a couple of solutions if that is the case,
> if you want to solve it locally.

OK, sorry for some noise.

The character is fine in Emacs 25.2.1, both in emacs -Q and with
my setup.  And the font is Symbola in both.

The problem is apparently in Emacs 24.5.  (And yes, the char is
0x21A6, in both releases.)  The problem exists in 24.5 for both
emacs -Q and my setup.  And the font is the same in both - the
font I showed earlier (MS Gothic...jisx0208).

The problem was apparently introduced in Emacs 24.5, when that
char was used for the first time, here.  It was apparently
fixed in 25.1.

(HTH in some way, but probably it does not.)

bug#26299: 24.5; Use of `…' in Info

[Eli Zaretskii]

> Date: Mon, 12 Jun 2017 07:52:30 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: npostavs@users.sourceforge.net, 26299@debbugs.gnu.org
> 
> The character is fine in Emacs 25.2.1, both in emacs -Q and with
> my setup.  And the font is Symbola in both.
> 
> The problem is apparently in Emacs 24.5.

Ah, okay, that explains everything: we've changed the default fontset
in Emacs 25.1 to use Symbola for punctuation and symbol characters.
In earlier versions you'd need to set up the fontset to do that in
your customizations.

bug#26299: 24.5; Use of `…' in Info

[Drew Adams]

> > The character is fine in Emacs 25.2.1, both in emacs -Q and with
> > my setup.  And the font is Symbola in both.
> >
> > The problem is apparently in Emacs 24.5.
> 
> Ah, okay, that explains everything: we've changed the default fontset
> in Emacs 25.1 to use Symbola for punctuation and symbol characters.
> In earlier versions you'd need to set up the fontset to do that in
> your customizations.

Thanks for the explanation.

And I see now, in the 25.1 NEWS, this item:

 ** New variable 'use-default-font-for-symbols', for backward compatibility.
 This variable allows you to get back pre-Emacs 25 behavior where the
 font for displaying symbol and punctuation characters was always
 selected according to your fontset setup.  By default, Emacs 25 tries
 to use the default face's font for such characters, if it supports
 them, disregarding the fontsets.  Set this variable to nil to disable
 this and get back the old behavior.

I guess that explains it (though I would have expected also a NEWS
item about the behavior change, separate from that item mentioning
a new variable).

bug#26299: 24.5; Use of `…' in Info

[Eli Zaretskii]

> Date: Mon, 12 Jun 2017 08:18:40 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: npostavs@users.sourceforge.net, 26299@debbugs.gnu.org
> 
> And I see now, in the 25.1 NEWS, this item:
> 
>  ** New variable 'use-default-font-for-symbols', for backward compatibility.
>  This variable allows you to get back pre-Emacs 25 behavior where the
>  font for displaying symbol and punctuation characters was always
>  selected according to your fontset setup.  By default, Emacs 25 tries
>  to use the default face's font for such characters, if it supports
>  them, disregarding the fontsets.  Set this variable to nil to disable
>  this and get back the old behavior.

That's related, but not the same issue as what I was talking about.
This variable is relevant when the default face's font can display a
symbol or punctuation character.  That is not your case, so in your
case this variable and the change in code which it disables are not
relevant.

As for the change in the default fontsets, it was done to better adapt
Emacs to the fonts that are usually installed on user machines, and
there's no reasonable way to describe the effect without knowing what
fonts are installed and which one is used for the default face.  So
that change is not in NEWS.

bug#26299: 24.5; Use of `…' in Info

[Drew Adams]

> That's related, but not the same issue as what I was talking about.
> This variable is relevant when the default face's font can display a
> symbol or punctuation character.  That is not your case, so in your
> case this variable and the change in code which it disables are not
> relevant.
> 
> As for the change in the default fontsets, it was done to better adapt
> Emacs to the fonts that are usually installed on user machines, and
> there's no reasonable way to describe the effect without knowing what
> fonts are installed and which one is used for the default face.  So
> that change is not in NEWS.

OK, thanks for that additional info.

bug#26299: 24.5; Use of `…' in Info

[Stefan Kangas]

tags 26299 + notabug
close 26299
quit

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

>> > Maybe Emacs needs to work around the problem (if it can't be
>> > fixed).  Maybe if Emacs uses `. . .' instead of `...' that
>> > will stop Texinfo from messing with it.
>> >
>> > (Why would Texinfo have a blanket treatment of ... as …?
>> > That makes no sense at all.  What if the occurrence of ...
>> > is part of code, and NEEDS to be 3 period chars?)
>>
>> Emacs' .texi files use @dots{} in these cases, as (strongly)
>> recommended by the texinfo manual:
>>
>>     An ellipsis (a sequence of dots) would be spaced wrong when typeset as
>>     a string of periods, so a special command is used in Texinfo: use the
>>     @dots{} command to generate a normal ellipsis, which is three dots in
>>     a row, appropriately spaced … like so. To emphasize: do not simply
>>     write three periods in the input file; that would work for the Info
>>     file output, but would produce the wrong amount of space between the
>>     periods in the printed manual.
>>
>> I found this thread [1] requesting plain "..." for @dots{} in makeinfo
>> output; there seemed to be no opposition, but I guess it didn't
>> happen. Perhaps try pinging bug-texinfo@gnu.org?
>
> Thanks for checking on this, Noam.  I will leave it to Emacs
> maintainers to decide whether to ping bug-texinfo.  I reported
> the complaint as one Emacs user.  Dunno what Emacs Dev will
> decide is the desired behavior.  I know what I prefer.

Info displays three dots ("...") rather than ellipsis in the manual on
my system, which has texinfo 6.5.0.  So it would seem like texinfo has
reverted this change?

In any case, this is not an Emacs bug, so I'm closing this as notabug.

Best regards,
Stefan Kangas