Follow-up Comment #10, bug #59795 (project groff):
Bjarni is correct. I was attempting to infer groff (and Heirloom) behavior in
black-box fashion, and did not contrive enough experimental cases.
But the implementation is sufficiently strange that it's easier to get an
understanding by quoting the code.
>From src/roff/troff/env.cpp:
void adjust()
{
curenv->adjust_mode |= 1;
if (has_arg()) {
switch (tok.ch()) {
case 'l':
curenv->adjust_mode = ADJUST_LEFT;
break;
case 'r':
curenv->adjust_mode = ADJUST_RIGHT;
break;
case 'c':
curenv->adjust_mode = ADJUST_CENTER;
break;
case 'b':
case 'n':
curenv->adjust_mode = ADJUST_BOTH;
break;
default:
int n;
if (get_integer(&n)) {
if (n < 0)
warning(WARN_RANGE, "negative adjustment mode");
else if (n > 5) {
curenv->adjust_mode = 5;
warning(WARN_RANGE, "adjustment mode '%1' out of range", n);
}
else
curenv->adjust_mode = n;
}
}
}
skip_line();
}
void no_adjust()
{
curenv->adjust_mode &= ~1;
skip_line();
}
>From this we can see that adjustment enablement is simply the least
significant bit of the adjustment mode. Where things get weird is the value
of the ADJUST_LEFT constant, but we shouldn't scar users' minds with that.
I'm dubious about this bit:
else if (n > 5) {
curenv->adjust_mode = 5;
warning(WARN_RANGE, "adjustment mode '%1' out of range", n);
}
This should be comparing to an ADJUST_MAX constant instead of a literal. It
also smells a little funny to start right-adjusting if the adjustment mode is
out of range (that's what adjust_mode = 5 means). I'll have to see if AT&T
troff supported numeric adjustment modes; it is already known that V7 troff
did not support the .j register.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?59795>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
