bugGNU roff - Bugs: bug #43239, broken interaction between line...

 
 

bug #43239: broken interaction between line numbering and diversions

Submitter:  Dave <barx>
Submitted:  Wed 17 Sep 2014 01:54:19 AM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Invalid
Privacy:  Public Assigned to:  wl
Open/Closed:  Closed Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 23 Jan 2022 04:06:10 AM UTC, comment #3: 

comment #2:

> As long as Branden is going through and updating crusty old bugs, to make the record of this one complete I'll point out that further discussion did occur on the email list; http://lists.gnu.org/r/groff/2014-09/msg00188.html is the start of the relevant thread.
>
> Spoiler alert: all who responded agreed with Werner's assessment in comment #1.


Yeah, have to say that I agree with that.  A line number is "attached" to the output line, and goes where the output line goes.

Can that make line numbering discontiguous?  Absolutely.  But it's up to a document or macro package to provide a facility to manage line numbering correctly in combination with footnotes, for instance.

> (The archived thread shows two instances of "Message not available," but I believe this to be inaccurate: comparison against my email archive shows that the thread on the web archive is complete.)


This might be due to the existence of off-list replies.  I suspect what's happening is that the web interface reports "message not available" for any Message-Id (appearing in a References header) that it doesn't know about.  Mail user agents (MUAs) can preserve in that header every Message-Id in what it thinks of as the "thread", which can lead to a multiplicity of histories when off-list replies come into the mix.

There's probably an RFC about this, but I would think, off the top of my head, that a References: line need only contain the Message-Ids of messages actually quoted in the mail.  On the other hand, the References header is usually populated at the moment a reply message is sent to the editor for composition, and the MUA has no way of reliably discerning what remains of the quoted material and its association back to source messages subsequent to the tender mercies of text editing.

G. Branden Robinson <gbranden>
Group administrator
Sat 22 Jan 2022 05:57:09 PM UTC, comment #2: 

As long as Branden is going through and updating crusty old bugs, to make the record of this one complete I'll point out that further discussion did occur on the email list; http://lists.gnu.org/r/groff/2014-09/msg00188.html is the start of the relevant thread.

Spoiler alert: all who responded agreed with Werner's assessment in comment #1.

(The archived thread shows two instances of "Message not available," but I believe this to be inaccurate: comparison against my email archive shows that the thread on the web archive is complete.)

Dave <barx>
Group Member
Wed 17 Sep 2014 04:35:02 AM UTC, comment #1: 

Well, it's definitely not a bug.  In groff, a `diversion' really does what its name says: It diverts formatted groff output from the normal output stream to a macro.  Of course, this includes line numbering.

The proper way to solve this issue is to switch environments, e.g.

  ... before diversion ...
  .ev my-env
  .di my-div
  ... diversion text ...
  .br
  .di
  .ev
  ... after diversion ...
  .di my-div
  ... more text ...

(and don't forgot to end a diversion with `.br' to finish the current partially collected line).

I'm closing this as invalid.  However, I invite you to discuss documentation improvements on the groff mailing list, which is a better place than this tracker issue.

Werner LEMBERG <wl>
Group administrator
Wed 17 Sep 2014 01:54:19 AM UTC, original submission:  

.nm +1
Text before diversion.
Text before diversion.
Text before diversion.
Text before diversion.
Text before diversion.
Text before diversion.
Text before diversion.
Text before diversion.
.br
.di my_diversion
Diverted text.
Diverted text.
Diverted text.
Diverted text.
Diverted text.
Diverted text.
Diverted text.
Diverted text.
Diverted text.
Diverted text.
Diverted text.
Diverted text.
Diverted text.
Diverted text.
Diverted text.
Diverted text.
Diverted text.
.di
.my_diversion
Text after diversion.
Text after diversion.
Text after diversion.
Text after diversion.
Text after diversion.
Text after diversion.

The problem with the above input can be seen in either text (via nroff) or PostScript output.  This behavior is not documented, and not what any user would reasonably expect or want.

You can make the output sane by putting ".nm" immediately before the beginning of the diversion's definition, and ".nm +0" immediately after the end of the definition.  So if line numbering is turned on when a diversion definition begins, groff ought to do this automatically.

Dave <barx>
Group Member

 

(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 (Updated the item)
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by barx (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-01-22 gbranden CategoryNone Core
        Item GroupNone Incorrect behaviour
    2014-09-17 wl StatusNone Invalid
        Assigned toNone wl
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code