bugGNU roff - Bugs: bug #61935, [troff] \k not ignored after \c

 
 

bug #61935: [troff] \k not ignored after \c

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Wed 26 Jan 2022 04:41:05 PM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Confirmed
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 17 Aug 2022 08:59:41 PM UTC, comment #3: 

Another test comment.  See update from Bob Proulx below.

https://lists.gnu.org/archive/html/savannah-hackers-public/2022-08/msg00011.html

If sendmail processes never got spawned, then mail never got queued, and we'll never see the email traffic corresponding to Savannah ticket updates from 12 August to earlier today unless an administrator has a way to regenerate them based on a database query of some sort, I surmise.

G. Branden Robinson <gbranden>
Group administrator
Wed 17 Aug 2022 06:56:49 AM UTC, comment #2: 

This is a dummy comment to see if the email gateway is back up.

See https://lists.gnu.org/archive/html/savannah-hackers-public/2022-08/msg00007.html .

G. Branden Robinson <gbranden>
Group administrator
Wed 26 Jan 2022 04:52:46 PM UTC, comment #1: 

Unix V7 nroff:


New Boot, known devices are hp ht rk rl rp tm vt
: rl(0,0)rl2unix
mem = 177856
# Restricted rights: Use, duplication, or disclosure
is subject to restrictions stated in your contract with
Western Electric Company, Inc.
Thu Sep 22 08:30:25 EDT 1988

login: dmr
$ nroff
foo\c\ka
bar\kb\c
.tm \na
0
.tm \nb
72
foobar


Heirloom Doctools nroff:


$ ./bin/nroff | cat -s
foo\c\ka
bar\kb\c
.tm \na
.tm \nb
0
72
foobar


GNU troff:


$ ./build/test-groff -Tutf8 -b -ww | cat -s
foo\c\ka
bar\kb\c
.tm \na
.tm \nb
72
72
foobar


I have a suspicion that "everything" in our docs is much too
broad.  After looking at src/roff/troff/{env,input}.cpp, I
suspect that what is really meant is "everything that doesn't
get converted into an output node", which unfortunately is not
illuminating terminology with which to teach the meaning of the
notoriously slippery, but essential, `\c` escape sequence to
novice *roff users.

`\}` after `\c` bears looking at as well.

I tested with groff Git HEAD, but I'm betting this behavior goes
all the way back.

G. Branden Robinson <gbranden>
Group administrator
Wed 26 Jan 2022 04:41:05 PM UTC, original submission:  

Heirloom Doctools nroff and Unix V7 nroff both ignore \k escape
sequences after the output line continuation escape sequence \c.

According to our documentation, we do too, but we really don't.


 -- Escape: \c
 -- Register: \n[.int]
     '\c' continues an output line.  Anything on the input line after it
     is ignored except '\R', which works as usual.  In contrast to
     '\<RET>', a line after '\c' is treated as a new input line, so a
     control character is recognized at its beginning.  The visual
     results depend on whether filling is enabled; see *note
     Manipulating Filling and Adjustment::.


Either we should document our difference from the AT&T lineage,
or change GNU troff to work as documented.

The above description also does not consider \" or \# escape
sequences.

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.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code