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

[G. Branden Robinson]

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

[comment #7 comment #7:]
> My fleeting concern with that was potential parsing ambiguity if a long
register name ends in a backslash: are there cases where the \] signifying the
end of the register name in the \n[] escape are confusable with the proposed
\] escape?
> 
> To see if this was an actual concern, I first looked in the Identifiers node
of the Texinfo document.  It claims that of printable characters, only those
considered whitespace are ineligible in identifiers.  So the backslash should
be legal.
> 
> But it isn't:
> 
> $ groff <<< '.nr a\ 1'
> troff:<standard input>:1: error: '\ ' is not allowed in a name
> troff:<standard input>:1: warning: numeric expression expected (got '\ ')
> 
> 
> In conclusion, I'm good with \] as an escape, but need to open a new
documentation bug.

You _can_ use '\' in an identifier name, but you have to escape it, turn the
escape mechanism off, or change the escape character.


$ cat EXPERIMENTS/backslash-in-identifier.groff 
.nr a\\b 1
\n[a\\b]
.ec @
.nr c\d 2
@n[c\d]
.eo
.nr e\f 3
.ec \" no way to interpolate that without turning escapes back on
\n[e\\f]
$ ./build/test-groff -Tutf8 | cat -s
1 2 3


That isn't to say I think it's a wise practice, or should be recommended.

The way I think about escaping in *roff is that the escape character, if
defined, is lexically supreme--it is _always_ interpreted as starting an
escape sequence, unless it _can't_ start one.  And the only way it can't
(again, if defined), is if it is already immediately preceded by...the escape
character.

Basically, once the escape character (if defined) is seen, the lexer/parser
goes into "eat one character" mode.  That character determines the escape
function to be performed (interpolate a register, start a comment, etc.), and
it is _only_ that context in which hitting another escape character is not
special.

So far this rule has not led me astray when interpreting *roff input. 
(Admittedly, I've cheated and looked at the parser's implementation in
src/roff/troff/input.cpp many times, but I could not claim to have memorized
it!)

    _______________________________________________________

Reply to this item at:

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

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