bugGNU roff - Bugs: bug #63470, [troff] ramifications of `chop`...

 
 

bug #63470: [troff] ramifications of `chop` not fully illuminated

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Mon 05 Dec 2022 06:10:11 AM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Documentation Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 29 Jan 2024 10:15:21 PM UTC, comment #1: 

The answer is that *roff is a macro language, not a procedural one.

If you chop the final newline from a diversion and then emit it, then in its interpolation context there is no final newline.

So the next thing in the input stream that is interpreted is processed in whatever the context established by the diversion was.
Usually, this will be a text line.


$ cat EXPERIMENTS/magic-diversion.groff
.di foo
This is my diversion.
.br
.di
.foo
.nop How do you like it?
.chop foo
.foo
.nop Does it suit?
.pl \n[nl]u
$ nroff EXPERIMENTS/magic-diversion.groff
This is my diversion.   How   do   you   like   it?    This is my
diversion..nop Does it suit?


If this stumped me, it may stump others.  Discuss it more in our Texinfo manual, and possibly alongside the `chop` request in the groff(7) and/or groff_diff(7) man pages.

G. Branden Robinson <gbranden>
Group administrator
Mon 05 Dec 2022 06:10:11 AM UTC, original submission:  

Consider the following input.


$ cat EXPERIMENTS/trail.man
.TH foo 1 2022-12-04 "groff test suite"
.SH Name
foo \- frobnicate a bar
.SH Authors
The GNU version of
.I foo
was written by
.MT q@\:example\:.com
Quiller
.ME .


Also consider the following implementation of hyperlink output in groff man(7) (from my working copy--my push has been held up on tracking down this issue).  It is unfortunately long, but there is only one line that makes a difference.


.de an*end-hyperlink
.  ie (\\n[an*is-in-link-text-diversion] & \\n[an*do-hyperlink]) \{\
.    br
.    di
.    ev
.
.    \" Was any link text present?
.    ie \\n[dn] \{\
.      if \\n[an*is-output-html] \
.        nop \X^html:<a href="\\*[an*prefix]\\*[an*hyperlink]">^\c
.      if \\n[an*is-output-terminal] \
.        nop \X^tty: link \\*[an*prefix]\\*[an*hyperlink]^\c
.      \" Strip off the final newline of the diversion and emit it.
.      chop an*link-text-div
.      an*link-text-div
.        nop \c\" XXX: If we .nop this, HTML output is corrupted.  Bug?
.      if \\n[an*is-output-html] \
.        nop \X^html:</a>^\c
.      if \\n[an*is-output-terminal] \
.        nop \X^tty: link^\c
.    \}
.    \" If there was no link text, format URI as its own link text.  We
.    \" don't add angle brackets here.
.    el \{\
.      if \\n[an*is-output-html] \
.        nop \X^html:<a href="\\*[an*prefix]\\*[an*hyperlink]">\\*[an*hyperlink]</a>^\c
.      if \\n[an*is-output-terminal] \
.        nop \X^tty: link \\*[an*prefix]\\*[an*hyperlink]^\\*[an*hyperlink]\X^tty: link^\c
.    \}
.    nop \&\\$1\"
.  \}
.  \" If not hyperlinking, format URI in angle brackets.  There was no
.  \" diversion, so the link text has already been formatted normally.
.  el \{\
.    nh
.    nop \\[la]\\*[an*hyperlink]\\[ra]\\$1
.    hy \\n[an*hyphenation-mode]
.  \}
.
.  rr an*is-in-link-text-diversion
..


The line with "XXX" is the one to attend to.

There is, evidently, a difference between

\c

and

.nop \c

...when output is being formatted for HTML (only).  This should not be the case because "nop" is a "no-op" that should have no side effects :rolleyes:.  ("NOP" is always a lie and I am automatically suspicious of anyone who claims it.  Even on CPUs it has the effect of incrementing the program counter.  On modern CPUs it will also alter all kinds of microarchitectural state that the manufacturer will swear up and down constitute trade secrets that will have no impact on a working engineer.  And then the security kids have a field day observing "unobservable" processor state and breaking the hell out of stuff.)

Anyway.  groff is pissing me off the way Intel does right now.

Here's a diff of the generated HTML.


$ diff -u magic-html.html magic-with-nop-html.html
--- magic-html.html     2022-12-04 23:47:40.818051929 -0600
+++ magic-with-nop-html.html    2022-12-04 23:49:23.837782028 -0600
@@ -1,5 +1,5 @@
 <!-- Creator     : groff version 1.23.0.rc1.3482-0e93a -->
-<!-- CreationDate: Sun Dec  4 23:47:40 2022 -->
+<!-- CreationDate: Sun Dec  4 23:49:23 2022 -->
 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
 "http://www.w3.org/TR/html4/loose.dtd">
 <html>
@@ -41,7 +41,7 @@

 <p style="margin-left:9%; margin-top: 1em">The GNU version
 of <i>foo</i> was written by
-<a href="mailto:q@example.com">Quiller</a>.</p>
+<a href="mailto:q@example.com">Quiller.nop </a>.</p>
 <hr>
 </body>
 </html>


Look at that garbage.

One might be tempted to blame the admittedly buggy post-html output driver.  That doesn't seem to be the case.  It is helpless in the face of troff output that doesn't tell it the right thing.


$ diff -u magic-html-Z.grout magic-with-nop-html-Z.grout
--- magic-html-Z.grout  2022-12-04 23:47:22.650116063 -0600
+++ magic-with-nop-html-Z.grout 2022-12-04 23:49:14.073800330 -0600
@@ -132,6 +132,10 @@
 x X devtag:.ta  L 120 L 240 L 360 L 480 L 600 L 720 L 840 L 960 L 1080 L 1200 L 1320 L 1440 L 1560 L 1680 L 1800 L 1920
 V320
 H1248
+t.nop
+wh24
+V320
+H1368
 x X html:</a>
 t.
 n40 0


Some bit of formatter internal state has gone awry.

What about other output devices?


$ cmp magic-tty.txt magic-with-nop-tty.txt && echo SAME
SAME
$ cmp magic-tty-Z.grout magic-with-nop-tty-Z.grout && echo SAME
SAME


Nope.  Only HTML is hosed.  But I'm worried that PDF will be, too, as I add support for PDF marks.

I'd like to kick this to groff 1.24 but if it affects PDF and I can't work around whatever is going wrong, this will become a blocker.

G. Branden Robinson <gbranden>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-01-29 gbranden Item GroupIncorrect behaviour Documentation
        Summary[troff] `nop` and output line continuation `\c` interact magically [troff] ramifications of `chop` not fully illuminated
    2022-12-05 gbranden Summary[troff] `nop` and output line contination `\c` interact magically [troff] `nop` and output line continuation `\c` interact magically

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code