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

[G. Branden Robinson]

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

Hi, Dave!

[comment #1 comment #1:]
> In the Heirloom troff bug tracker, a contributor suggested creating a
mechanism to explicitly indicate end of sentence that would augment the
existing heuristics.
> 
> From http://github.com/n-t-roff/heirloom-doctools/issues/83:
> 
> "I would like... a way to actively identify the end of a sentence, in
addition to the passive mechanism we have now. ... It isn't really practical
to identify every character that could be a transparent
character--superscripts, for example, could be nearly anything [0-9, A-Z,
a-z], and they might come from the ASCII set (reduced in size and shifted up)
or be dedicated glyphs.... Then there are the various quotation marks, not to
mention hot links (and, of course, macros that process note numbers)."

Indeed, it appears that the original Heirloom report happened across precisely
the same problem I did.

> It's not clear to me whether Heirloom troff is actively maintained anymore,
but if anyone is nominally in charge of its future direction, it would be good
to coordinate with them to come up with a portable system.

It has gotten awfully quiet over there.  Things aren't dead but they are
pretty sleepy.  On the other hand 2021 is already much more active than 2020
was (with only 2 commits in 13 months).

The idea of Yet Another New Escape to force end-of-sentence recognition did
occur to me, but it makes me a little anxious because the number of free
keycaps in the US-ASCII repertoire to which we an assign an escape function
after the escape character is rapidly approaching zero.  Here, let me count
'em...

The following remain.


G i I j J K P T U W y
1 2 3 4 5 6 7 8 9
+ ; < > = @ ]


Hmm, I guess that's not as bad as I thought.  Still, 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. 
A delimiter follows, enclosing some arbitrary-length sequence that is decoded
by a dedicated function.

The two candidates that leap to mind are "G", for "GNU" or "groff" if we have
to go our own way on this, and "@" if we don't.

In any case, none of the symbols in the above list have any obvious mnemonic
value to me for the purpose the Heirloom bug submitter and I want. ("\y" for
"yes, damn it, this is the end of a sentence" did occur to me, but alas that
is a highly flexible sentiment.)  \; would seem to be an anti-choice; I think
it would imply "_not_ the end of a sentence" more strongly than the actual
escape for doing so (\&) does.  \., \?, and \! are all taken.

Suggestions?

    _______________________________________________________

Reply to this item at:

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

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