Re: [PATCH v2 04/18] doc/bash.1: improve typography of ellipses

[G. Branden Robinson]

Hi Martin,

At 2024-04-12T14:55:22+1200, Martin D Kealey wrote:
> On Thu, 1 Feb 2024 at 07:54, G. Branden Robinson <
> g.branden.robinson@gmail.com> wrote:
> 
> > v2: Prevent confclit with PATCH v2 01/18.
> > Apply ellipsis advice from groff_man_style(7).
> > • The dummy character escape sequence \& follows the ellipsis when
> > further text will follow after space on the output line, keeping its
> > last period from being interpreted as the end of a sentence and
> > causing additional inter‐sentence space to be placed after it.
> 
> Is there a reason why we're still using a triple period/full-stop
> “...” (\u002e) instead of an actual ellipsis “…” (\u2026)?

Yes.  Portability to troffs that don't support GNU troff extensions.

     • Why doesn’t the package provide a string to insert an ellipsis?

[...]
       There is an ellipsis code point in Unicode, and some fonts have
       an ellipsis glyph, which some man pages have accessed in a non‐
       portable way with the font‐dependent \N escape sequence.  We
       discourage the use of these; on terminals, they may crowd the
       dots into a half‐width character cell, and will not render at all
       if the output device doesn’t have the glyph.  In syntax synopses,
       missing ellipses can mislead the reader.  Dots and space are
       universally supported.

When AT&T troff finally dies or is abandoned by projects (like Bash and
ncurses) currently maintaining portability to System V hosts (like
Solaris 10), that might be a good time to reconsider the foregoing
point.

But likely not with a *roff _string_, for reasons I elided.

Regards,
Branden

signature.asc
Description: PGP signature