Re: [Groff] odd interaction between .bl and .(c in -me macros

[Tadziu Hoffmann]

> Many things that one would normally set in an environment, -me
> stores in registers, which are global, not per environment.
> So there is little point in switching to a new environment
> and then using the -me-sanctioned method of setting, say,
> the paragraph type size (that is, setting the pp register),
> as this change is global.

I think that because the "partially collected line" is part of
the environment, the main purpose of environments is dealing
with two (or more) concurrent "text threads" that shouldn't
interfere with each other (e.g., running text, footnotes, page
headers).  For example, assume you encounter a footnote request
in the text.  You don't want to cause a break because that would
flush the current line being collected out to the page and begin
a new line.  On the other hand, you can't just start diverting
text into the footnote diversion, because then the footnote
would include the current line of the running text as well.  So
you switch to the footnote environment, start diverting into the
footnote diversion, process the footnote text, break to flush
the last (partial) line of the footnote into the diversion, stop
diverting, pop the environment stack to return to the normal
text environment, and continue processing the running text.
(Also, move the page-bottom trap upwards to account for the
height of the new footnote.)

Everything else that you can deal with sequentially (such as
section headers, which must explicitly flush the last partial
line of the preceding paragraph) can be processed in the main
environment.  That is why Unix troff could get along fine with
just 3 environments.
(The section header macro can set the desired font size,
family, etc. from global registers (or have them hardcoded).
Explicitly (re-)setting those values is useful, because then
local changes made by the user will be reset to default at a
new section header / paragraph / etc.  If you want to make
"permanent" changes, set the registers which contain the
defaults, or define high-level macros which do this.)

> In fact, meref.me mentions environments only once, when
> talking about .ll and comparing it to .xl.  Were it not for
> these two macros expressly designed to deal with environments,
> I would conclude that using -me and using multiple
> environments were incompatible.

Actually, they're not incompatible -- it's just that you have
to set the values yourself (or write a macro to do that).

Looking at the code you can see that -me renames "ll" to "xl"
and then defines a wrapper macro "ll" that calls "xl" and also
stores the line length in a register, but it appears as if other
macros wanting to make use of that line length must explicitly
set it from the register (in other words, there's nothing
automatic in the process, and I can only guess that meref.me
suggests that -me is "internally consistent" in that the other
macros actually do make use of the register as described above).

> > In the old troff, it would have been possible to redefine
> > "ll" so that it changes the line lengths in all environments
> > (there were only three, "0", "1", and "2"), but in groff
> > where you can create new environments on the fly, this is
> > surely not possible.

> Since the -me macro set predates groff, could it be that the
> documentation is referring to the troff implementation and was
> never updated with the groff port?

Yes, that's what I had originally thought, too, but a much older
version of -me that I found is identical to groff's in regard to
"xl" and "ll".

> > Of course it is possible to redefine "ev" to switch to the
> > new environment and set the line length, but ...  blindly
> > setting the line length when entering the environment is not
> > desirable.

> Desirable or not, I would say that such behavior is exactly
> what meref.me documents that .ll will do.

Hmm, if it was intended that way it certainly isn't coded that
way.  (And again, I think it would be a bad idea.)  If there's
a bug I think it's that the other macros don't make use of the
"ll"-defined register for the line length.

> If you think it makes more sense to change the documentation
> than the macro package's behavior, what then is the difference
> between .xl and .ll?

See above.

> > The best solution would probably be not to use the low-level
> > requests directly, but instead to define higher-level macros
> > for specific purposes.  (Have you looked at macro "@C" as a
> > wrapper around "ev"?)

> I haven't looked at anything to try and debug this; it's been
> a pretty low-priority problem for me thus far.

Well, "@C" switches to a new environment and explicitly copies
most settings from the previous one to the new one.  Apparently
this is such a useful feature that groff has implemented a new
request for this purpose, "evc".  (But whereas "evc" copies
everything, a macro such as "@C" can be implemented to copy
only a user-defined subset.)