While I'm looking at my backlog of -me issues, I should go back to this thread I abandoned in March 2012. The whole sordid history is at the threads starting at http://lists.gnu.org/archive/html/groff/2012-02/msg00019.html and http://lists.gnu.org/archive/html/groff/2012-03/msg00000.html .
The upshot is that meref.me's documentation of .ll and .xl does not reflect the way these work. In particular, meref.me was written at a time when troff could not create an arbitrary number of environments on the fly, so where it says .ll will "set line length in all environments," it is referring to all hard-coded environments that -me knows about. In the troff days, this was equivalent to "all environments." In groff, it is not. Tadziu argues that .ll's behavior as documented in meref.me is not desirable for modern groff; that is, one would not want a macro that would set the line length in new environments created on the fly. Thus he advocates that the documentation be changed to match the current behavior, rather than the other way around. I'm undecided on this. Consider a simple test case that demonstrates -me's intended .ll behavior: .mso me.tmac .ll 4i .he 'L'M'R' .fo 'L'M'R' .pp Here is some text. Here is some filler text to demonstrate the line length. Here is some filler text to demonstrate the line length. .(f By the way, here is a footnote. Here is some filler text to demonstrate the line length. Here is some filler text to demonstrate the line length. .)f .(b M F Here is a block of text. Here is some filler text to demonstrate the line length. Here is some filler text to demonstrate the line length. .)b .br .ev new Here is a brand new environment I just created, that -me knows nothing about. Here is some filler text to demonstrate the line length. Here is some filler text to demonstrate the line length. .br .ev Here, all the page elements are cleanly aligned: the header, footer, regular text, block text, and footnote all have the same margins. The only outlier is the text in environment "new", which -me cannot control because -me is unaware of the concept of user-created environments. But change the .ll at the top of this example to a .xl to see the problem. Now, as expected, header and footer elements, the text block, and the footnote align with -me's default line length (set via .ll in me.tmac) of 6i. The first paragraph has the locally defined (via .xl in the document) line length of 4i. The new environment, however, goes back to groff's fallback line length of 6.5i. The -me macro set uses .ll to initialize the line length "globally," but the globe has gotten bigger since -me was written. I don't think new environments defaulting to a line length half an inch off from the rest of the document is necessarily desired, and almost certainly not the expected behavior. The cleanest way to address this, I think, would be for -me to replace groff's .ev request with a macro that's aware of -me settings. The framework is already there, as Tadziu notes, in the currently internal-only @C macro. The potential pitfall, in Tadziu's own words: > often, environments are used to process > different parts of the text (e.g., you might use a separate > environment to process footnotes), and so you often do want to > have different parameters for the different environments. In > this case blindly setting the line length when entering the > environment is not desirable. meref.me documents that .ll "should not be used after output has begun"; the macro is designed to be used at the top of the document to set the default line length, after which variations in individual environments can be introduced as needed via .xl. So a user creating a new environment would create it via .ev, which would get kicked to a macro that would set the line length to the document's default length. Then the user could use .xl, as documented, to override that default for this specific environment. The trick is for -me's custom .ev macro to detect whether it is entering a new environment or a previously defined one; in the latter case, it should /not/ change the line length to the .ll-defined default, as the user can be presumed to have already set her desired line length. However, I'm not finding any straightforward means of making this determination. Am I overlooking something, or is this a groff limitation that derails the whole concept? For that matter, is the concept itself sound, or are there other pitfalls that I've missed?
