bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #61605] [man pages] Do not create trailing spaces


From: G. Branden Robinson
Subject: [bug #61605] [man pages] Do not create trailing spaces
Date: Fri, 3 Dec 2021 14:12:58 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Update of bug #61605 (project groff):

                Severity:              3 - Normal => 2 - Minor              
                  Status:                    None => Wont Fix               
             Assigned to:                    None => gbranden               
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

[comment #0 original submission:]
> Subject: [man pages] Do not create trailing spaces
> 
>   When there is a space in front of an inline comment,
> it remains there after the comment has been removed,
> so the line contains a trailing space when it is processed.

This doesn't accurately describe how GNU troff works.

As our Texinfo manual says, "Trailing spaces on text lines are ignored.
<https://git.savannah.gnu.org/cgit/groff.git/tree/doc/groff.texi#n4961>"

First, comments are discarded on input, when they are read
<https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/input.cpp#n1007>.
 Then, if there are (discardable) space nodes remaining on the output line
when it is converted into device-independent format, those space nodes are
discarded
<https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/env.cpp#n1705>.

You raise the issue of comments directly abutting the ends of string
definitions.  There is a principle of design that says "Different things
should look different.
<http://web.mit.edu/6.813/www/sp17/classes/07-more-learnability/>"  People
should indeed notice this difference in white space usage before a comment
escape sequence, because a string definition in *roff languages is _not_ like
text input (nor even like most other requests
<https://git.savannah.gnu.org/cgit/groff.git/tree/doc/groff.texi#n11315>).

>   If the space is not a part of a string definition,
> remove the space
> so the software does not need to waste processing
> efforts to remove it.

groff does many things more computationally expensive than walking a linked
list and removing items from it.  Trailing white space may be annoying to nit
pickers but it has well-established semantics in *roff languages, and your
micro-optimizing claim notwithstanding, it is common in programming languages
to separate comments from semantically significant logic on the same input
line.

I would challenge you measure the effect you claim.  Perhaps it would rise
above the noise floor if there were thousands of trailing space characters on
an input line, because that might cause the data to cross a page boundary,
leading to a cache miss. (But perhaps not.) <https://lwn.net/Articles/372384/>
 In any case, the number of real-world *roff documents that will have this
property of myriad blanks between the end of text on a line and a comment is
vanishingly small.
 
>   The '\"' is just as any punctuation mark, showing the end of the text
> for the software to execute.

That's a strange way of looking at it, and not really what it means to the
parser.  For one thing, there are two kinds of punctuation mark to a
*roff--end-of-sentence punctuation and its complement.  A comment escape
sequence is neither.

>   Examples of a trailing space:
> 
> troff:./contrib/hdtbl/groff_hdtbl.7.man:1029: warning: trailing space in
line
> 
> or \f[BI]bold italic\f[], \" \f[BI] is not portable man(7)
> 
> ##
> troff:./man/groff.7.man:501: warning: trailing space in line
> 
> is \f[BI]bold-italic\f[]\/, \" indulging a bit of man(7) evil here
> 
> ##
> troff:./man/roff.7.man:408: warning: trailing space in line
> 
> Around this time, \" judging by "CSTR #17"
> 
> ##
> troff:./man/roff.7.man:436: warning: trailing space in line
> 
> does not feature a request list, \" nor does V6 Unix troff(1) (1975)
> 
> ##
> troff:./src/preproc/eqn/eqn.1.man:177: warning: trailing space in line
> 
> Three points are worth special note. \" good, bad, and different
> 
> ##
> troff: backtrace: file './src/preproc/tbl/tbl.1.man':1395
> 
> the escape character must be disabled. \" XXX: Why?
> 
> ##
> troff:./src/roff/groff/groff.1.man:1148: warning: trailing space in line
> 
> librarian program \" such as man-db, since 2001
> 
> ## 
> troff:./tmac/groff_mdoc.7.man:4635: warning: trailing space in line
> 
> Old typesetters lacked directional double quotes, \" like the C/A/T
> 
> ##
> troff:./tmac/groff_mdoc.7.man:4644: warning: trailing space in line
> 
> strings this way. \" thanks to Ingo Schwarze for the research
> 
> ##
> troff:./tmac/groff_ms.7.man:2296: warning: trailing space in line
> 
> macro \" I wouldn't mention that, but Lesk 1978 encourages doing so. :-/

I wrote most of those comments and I'm not inclined to smash them up against
the real text they annotate nor to delete them.

I believe I am writing idiomatic *roff.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61605>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]