Re: [Groff] [PATCH] groff_char(7): Add \(dq as glyph that doesn't print as itself.

[Ingo Schwarze]

Hi Branden,

G. Branden Robinson wrote on Mon, Sep 04, 2017 at 05:23:05PM -0400:

> Resurrecting the half of a patch of mine from April that Ingo didn't
> take care of for me.
> 
> I checked, and I did not bust the column width in the table even on a
> TTY with MANWIDTH=80.
> 
> Comments appreciated.
> 
> commit a2cf88c70a53949ab136f062baf32b28d57eaf72
> Author: G. Branden Robinson <address@hidden>
> Date:   Mon Sep 4 17:17:48 2017 -0400
> 
>     Add \(dq as glyph that doesn't print as itself.
>     
>     This is only true in a macro-call context, but mention this fact
>     for the benefit of users confused by the issue.

I'm not completely convinced that is a good idea.

In a similar sense, several other characters do not print as themselves:

 * The Space (code 32) does not always print as itself.
   For example, on macro lines, it merely separates arguments,
   and whether the arguments are printed with or without
   spacing between them, and whether they are printed at all,
   depends on the macro, not on the space(s) between the arguments.
 * The Exclamation Mark (code 33) does not print on .if and .ie lines.
   Similarly for some ASCII characters representing arithmetic operations.
 * The Period (code 46) does not print at the beginning of logical
   input lines, but introduces macros.
 * The Backslash does not print as itself, but introduces
   an escape sequence.

Singling out the Quotation Mark feels wrong, and squeezing all the
similar characters into this table would feel wrong, too.  It's
just not what this table is about.  The table is about the translation
of input characters to output glyphs, not about the parsing of input
lines into plain-text input characters and into other, non-text tokens.

When their function as a token is "input character", all the ASCII
characters listed above do print as themselves, so they do not belong
into this table.

I do not feel very strongly about this, but i think that adding one
of them to this table might cause additional confusion rather than
making anything clearer.

If you think more explanation is needed, it might be better
to add a subsection listing input characters that require
escaping in some contexts to the end of the DESCRIPTION.
Such a section should explain how to escape

 * Space and Quotation mark on request and macro lines
 * Period and Apostroph at the beginning of text lines
 * Backslash anywhere

Yours,
  Ingo