* Space after .E[dl...]? @ 2011-11-22 22:34 Thomas Klausner 2011-11-23 0:31 ` Ingo Schwarze 0 siblings, 1 reply; 4+ messages in thread From: Thomas Klausner @ 2011-11-22 22:34 UTC (permalink / raw) To: discuss Hi! groff by default doesn't add space after a Bd/Ed, Bl/El etc. Many man page authors do like to have one there though and add a Pp for this reason. I think that Bd/Ed etc should have a space by default afterwards (like before the block); except perhaps when used with -compact. Opinions? Thomas -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Space after .E[dl...]? 2011-11-22 22:34 Space after .E[dl...]? Thomas Klausner @ 2011-11-23 0:31 ` Ingo Schwarze 2011-11-23 12:54 ` Thomas Klausner 0 siblings, 1 reply; 4+ messages in thread From: Ingo Schwarze @ 2011-11-23 0:31 UTC (permalink / raw) To: Thomas Klausner; +Cc: discuss Hi Thomas, Thomas Klausner wrote on Tue, Nov 22, 2011 at 11:34:16PM +0100: > groff by default doesn't add space after a Bd/Ed, Bl/El etc. > Many man page authors do like to have one there though > and add a Pp for this reason. > > I think that Bd/Ed etc should have a space by default afterwards > (like before the block); except perhaps when used with -compact. > > Opinions? Maybe that would have been better design. I'm not completely sure that i don't miss good reasons for the established behaviour, but your idea does seem more natural to me than what we have now. However, this is not just a question of what we like better, but also a question of compatibility. There are three aspects to compatibility: (1) At the very least, if we were to change this, groff and mandoc would have to change at the same time. This is clearly not a good point to introduce a groff-mandoc difference. Currently, it is not easy to push changes into the groff mainline. Werner Lemberg, the groff technical lead, is overworked, and while he does take care of critical stuff and also some of the less important things that seem interesting to him, he does not respond to all suggestions. No other groff committer takes the initiative when it comes to changing established behaviour, unless my impressions during the last year or so are quite wrong. (2) Even if we would manage to write patches for groff and mandoc and get them into both trees, we have to consider that people writing new or editing existing manuals will start relying on the new behaviour, and such manuals will look bad with older formatters, for example on Solaris. For that reason, if the existing behaviour has been consistent for a very long time on almost all mdoc(7) implementations, i'd be rather hesitant to change it now. On the other hand, if existing older implementations were inconsistent with one another anyway, this item (2) wouldn't be a relevant point. Note that i have still not come round to tracking down, installing, and testing legacy mdoc(7) implementations, such that i have no idea which kinds of changes would be how disrupting. Before setting out to change the language, i'd consider it important to have a good understanding of such questions. However, right now, i still see much more important issues to work on than investigating compatibility with legacy mdoc(7) implementations and trying to polish the language definition. (3) There are thousands of real-world manuals written for the old behaviour. Quite probably, there are some that will look worse after the change because the additional blank line is not an improvement in their particular case, even if it is in many other cases, and the authors of course relied on the fact that there is no blank line. Before even proposing this change in the language definition, i'd like some rough estimate, or at least feeling, how many pages might be affected by this effect, and how much effort we are imposing on people like jmc@ to clean up the tree after the change. In short, i think this is much less trivial than it may seem, and i'm not that thrilled about the idea, unless somebody else is going to do all the work outlined above. Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Space after .E[dl...]? 2011-11-23 0:31 ` Ingo Schwarze @ 2011-11-23 12:54 ` Thomas Klausner 2011-11-23 23:54 ` Ingo Schwarze 0 siblings, 1 reply; 4+ messages in thread From: Thomas Klausner @ 2011-11-23 12:54 UTC (permalink / raw) To: Ingo Schwarze; +Cc: discuss On Wed, Nov 23, 2011 at 01:31:19AM +0100, Ingo Schwarze wrote: > However, this is not just a question of what we like better, > but also a question of compatibility. There are three aspects > to compatibility: I understand your point. Most (if not all) mdoc man pages that a typical BSD user is interested in will come with their operating system though, so I don't see it as such a big hindrance as you do, because we can fix them. > (3) There are thousands of real-world manuals written for the > old behaviour. Quite probably, there are some that will look > worse after the change because the additional blank line is not > an improvement in their particular case, even if it is in many > other cases, and the authors of course relied on the fact that > there is no blank line. Before even proposing this change in > the language definition, i'd like some rough estimate, or at > least feeling, how many pages might be affected by this effect, > and how much effort we are imposing on people like jmc@ to > clean up the tree after the change. For backwards compat, I'd like to have Pp after El etc. ignored; this should fix this problem. Thanks for your feedback! Thomas -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Space after .E[dl...]? 2011-11-23 12:54 ` Thomas Klausner @ 2011-11-23 23:54 ` Ingo Schwarze 0 siblings, 0 replies; 4+ messages in thread From: Ingo Schwarze @ 2011-11-23 23:54 UTC (permalink / raw) To: Thomas Klausner; +Cc: discuss Hi Thomas, Thomas Klausner wrote on Wed, Nov 23, 2011 at 01:54:26PM +0100: > On Wed, Nov 23, 2011 at 01:31:19AM +0100, Ingo Schwarze wrote: >> However, this is not just a question of what we like better, >> but also a question of compatibility. There are three aspects >> to compatibility: > I understand your point. Most (if not all) mdoc man pages that a > typical BSD user is interested in will come with their operating > system though, so I don't see it as such a big hindrance as you do, > because we can fix them. There are several ports containing mdoc(7) manuals. Besides, it would be a pain if moving manuals from one operating system to another would require fixing up the manual source code because of language incompatibilities. I'd rather reduce such incompatibilies than deliberately add to them. >> (3) There are thousands of real-world manuals written for the >> old behaviour. Quite probably, there are some that will look >> worse after the change because the additional blank line is not >> an improvement in their particular case, even if it is in many >> other cases, and the authors of course relied on the fact that >> there is no blank line. Before even proposing this change in >> the language definition, i'd like some rough estimate, or at >> least feeling, how many pages might be affected by this effect, >> and how much effort we are imposing on people like jmc@ to >> clean up the tree after the change. > For backwards compat, I'd like to have Pp after El etc. ignored; For sure; in mandoc, that would be more or less automatic; in groff, i don't really know. > this should fix this problem. Er, no, i tried to talk about the reverse problem: Existing pages that do not have a .Pp after .Ed or .El because the author did not intend a blank line at that place. Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-11-23 23:54 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-11-22 22:34 Space after .E[dl...]? Thomas Klausner 2011-11-23 0:31 ` Ingo Schwarze 2011-11-23 12:54 ` Thomas Klausner 2011-11-23 23:54 ` Ingo Schwarze
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).