On 17.10.24 01:39, Dave Kemper wrote:
On Wed, Oct 16, 2024 at 3:01 PM joerg van den hoff <veedeeh...@gmail.com> wrote:
I now double-checked: the manual seems to indicate that w/o preceding mk, rt
needs an argument
(distance from page top). if it _really_ does the line would have to read `.rt
0'. but doing this
does not change behaviour neither for 1.22 nor for 1.23: AFAICS the resulting
pdfs are unaltered.
so apparently `.rt' w/o argument and preceding `mk' indeed is valid and _does_
(and might
prospectively be guaranteed to) return to page top.
This falls into an interesting area of underspecification. CSTR #54
also mentions the behavior of .rt without .mk but with argument, but
does not address argumentless .rt without .mk (let's call it ARWM).
What then should be concluded from this?
1. The behavior of ARWM is undefined
2. The behavior of ARWM is undocumented but defined by troff's behavior
In 1984 maybe one could have made a case for the former, and changed
the behavior with impunity (perhaps making ARWM throw an error or
always move the drawing position to pi inches from the top of the
page). With an extra 40 years of consistent behavior, this becomes
harder to defend, especially knowing that a lot of things were poorly
specified in CSTR #54, so users figured out what worked by trial and
error. (Some of these things have even been codified in groff
documentation.) And also knowing that some of troff's user base
enjoyed finding ways to creatively (ab)use programming languages'
fringes.
That said, there's good reason to _not_ use ARWM in your documents.
To experienced roff readers, ".rt" without an argument strongly
implies there was a preceding .mk. Code that gets the machine to do
what you want is nice, but code that humans can read and make sense of
(while also getting the machine to do what you want) is better. So
".rt 0" is better than plain ".rt" because it makes clear that there's
no preceding .mk, even if they both behave the same. (This holds even
if you're the only one who ever reads your roff code; a future you
will appreciate the disambiguation. It holds even more strongly for
code you post publicly.)
thanks for this. I can agree with all of the above although I do not have
strong feelings about
whether "ARWM" as an alias/shortcut for `.rt 0' is evil or just convenient. I of course can live
with using .rt 0 instead. but I definitely am in favour of your option 2 "undocumented by defined by
troff's behaviour" while branden seemed to be fixated on option 1.
apart from that, for the observed regression (more neutrally: "difference in behaviour in comparison
to 1.22"), the '.rt vs. .rt 0' question is of no import, I guess. the actual question seems
apparently what is desirable behaviour if .rt 0 plus absolute .sp is issued somewhere within DS/DE
and DE is immediately followed by a further relative .sp which worked in 1.22 intuitively "correct"
and now the relative .sp seems to be just ignored as I showed in the example -- which hardly seems
desirable at all.
On Wed, Oct 16, 2024 at 4:13 PM G. Branden Robinson
<g.branden.robin...@gmail.com> wrote:
On many machine architectures, in the C language, a pointer occupies the
same number of bits as an `int` variable. Clearly we can assume that
they're always equivalent; if our code works despite some tedious manual
warning us not to rely on this conclusion, we should do so anyway.
That's a flawed analogy on two fronts:
- C standards explicitly say the size of a pointer is undefined.
ARWM is unaddressed by any documentation.
- As you imply above, pointer sizes do actually vary across
architectures. There is no evidence ARWM behavior also so varies.
