bug-groff
[Top][All Lists]
Advanced

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

[bug #60571] Footnote markers defeat end-of-sentence recognition


From: G. Branden Robinson
Subject: [bug #60571] Footnote markers defeat end-of-sentence recognition
Date: Fri, 14 May 2021 20:39:18 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Follow-up Comment #4, bug #60571 (project groff):

[comment #3 comment #3:]
> [comment #2 comment #2:]
> > The following remain.
> 
> And of those. Heirloom uses   
> 
> ; @ j J P T U

Checking the doc.ps from their git repository, I see they've claimed

I W

as well.  :-/

This is particularly perverse is their \I is our \A--they wanted \A for URI
"a"nchors, apparently, which \W connects to.

> > I think before long we want to propose to the *roff community
> > the reservation of one of the above characters for an extended
> > escape syntax of much the same form as \D and \X.
> 
> That makes a great deal of sense to me.

Yeah, I just don't know where the forum for modern *roff standardization is. 
Is it groff at gnu?
 
> Offhand, < seems the best candidate for a double-agent escape character /
begin delimiter, since it has an obvious companion for an end delimiter (at
the risk of maybe making roff code look a little HTMLy).

Agreed.

> Given the paucity of available letters, we may be in the Post-Mnemonic Era
for assigning new roff escapes.  Traditional Unix commands with a multitude of
single-letter command-line switches have felt this crunch as well.

Yes; I recall Ingo Schwarze seeking to impose a semantic discipline over the
approximately 52-character name space of Unix option letters. (I remember how
"-?" was going to save the world as a universal way to get a usage
message...except, whoops, the Unix shell had already seized "?" for its own
purposes, and any novice who needed help would simply stare with
incomprehension if they were told they needed to quote the "?".)

I think that's hopeless, although he feels a greater urgency than I do because
he also has antipathy for GNU-style long options--but _within_ a project, like
groff, I think it behooves us to have consistent semantics for them.  I have
not evaluated how well we adhere to that, but in my many passes over our man
page corpus I can't remember any clashes leaping out at me.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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