Follow-up Comment #1, bug #64862 (project groff):
We _could_ solve this the way we save other things in tbl: by creating
registers and laboriously populating and restoring from them.
But there are a _lot_ of "previous-value" parameters that would require this
approach.
* previously selected font mounting position (this one)
* previous default font family
* previous fill color
* previous stroke color
* previous indentation amount
* previous line length
* previous additional interline skip amount ("line spacing")
* previous title line length
* previous page offset
* previous type size
* previous post-vertical line spacing
* previous vertical spacing
While conceptually straightforward to do, the quantity of manual operations
implied here suggests that it's a poor approach.
Further, off the top of my head, _all_ of these are properties of the
environment.
I therefore reiterate that it would probably be a good idea if GNU _tbl_
produced output that created an environment for each table region.
So, input like this:
.TS
L.
hello
.TE
...would become something like this.
.TS
.ev 3tbl*environment
.evc \n[.ev]
...
.ev
.TE
Hmm, maybe James Clark hadn't invented the `.ev` register yet at the time he
implemented GNU tbl. I think I've speculated elsewhere that maybe he was
trying to keep AT&T compatible output. (That would explain why the name of
_every_ *roff object handled by GNU _tbl_ has its name indirected through a
C/C++ preprocessor macro.) But it would _appear_ that once the bridge was
crossed to using long names for these, no one ever went back. There's no
mention I know of for a build option to use AT&T-legal names in GNU _tbl_
output, and as far as I recall, no support in GNU tbl code for generating
AT&T-compatible escape sequences (e.g., `\n(xx` vs. `\n[.xx]`).
Anyway. To solve this I think creating an environment is the way to go.
Urgency is not high. As far as I know I am the first person to ever complain
about this.
https://github.com/NetHack/NetHack/commit/9658f6769d1bded85f72e7b5b0f6a0841ef3604b
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64862>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
