On Wed, Aug 14, 2013 at 16:51, Ingo Schwarze wrote: >> I think mandoc should adjust its default output width based on the >> terminal size. At least in the case where the terminal is narrow. This >> diff doesn't change anything if you have wider than 80 column terminals. > > I agree with your idea for the case when somebody is viewing a manual > page interactively, but i disagree with your patch for the following > reason. I started an xterm, reduced its width, then typed:
> So, that's reduced width output. Ouch. That means you cannot run > builds or regression tests in a smaller terminal. I don't think > that's acceptable. > > Do you have any idea how to solve this? > One common approach is doing weird stuff when stdout is a terminal. > I don't like that in general in the first place. > Even if i would accept it in this particular case, i don't think it > would solve your problem: Usually, mandoc(1) is run in a pipe to a > pager, so even during interactive use, stdout is *not* usually a > terminal. Yes, this is a problem. mandoc is in the middle of a pipeline that is connected to a terminal, but is not itself directly doing so. I mention below that maybe man is the correct program to select an appropriate width. > How can we possibly distinguish interactive pipes like > > mandoc | less > > which might profit from variable defrmargin > from typical build system or regeression system pipes like > > mandoc | sed > > which want defrmargin = 78, period? The regression test can specify a fixed width. > If nobody comes up with a smart idea for that, > i fear you will have to put -Owidth=73 into man.conf(5) on your box, > leaving the defaults alone... :-( Several problems. One is that's completely unacceptable on a multiuser system (ok, my machine is not, but a good solution should be). Second, depending on what I'm doing, I use terminals of several different widths. There's not a single static setting that is correct. Somewhat third, using man -C myman.conf doesn't work well, since it doesn't read anything from the default file. So I have to copy the entire file, but then when the default paths are changed, I have to update that file. Kind of a separate issue, but using man.conf for anything is quite frustrating. Perhaps it is man that should be taught more tricks? man can detect if its output is to a terminal, and then provide the correct width to mandoc. This would require man to have some intrinsic knowledge about mandoc, however. > Besides, is your code portable? > > If i understand correctly, ioctl(2), sys/ioctl.h and even TIOCGWINSZ > seem to be reasonably common (though i'm not sure on which systems > they might not be available - do you have any idea?). As far as I know, this particular bit of code will work on ~unix made after 1995. or 1990. or some time long ago. > Finally, *if* we decide to go down that route or a similar one, > i think the patch appended at the end should be included. > Joerg Sonnenberger added the lower boundary on May 15, 2010, > in bsd.lv term.c rev. 1.134. The commit message does not even > mention the lower boundary, much less provide a rationale. > Given that the boundary is completely arbitrary, i never liked > it, and with your patch, the boundary really becomes a hindrance. hmm, opposite reaction. I agree that a lower boundary is a little strange if the user requested something small via -Owidth. In the case of auto sizing, a sane minimum is a good idea. We can move the check up, into the auto sizing part perhaps, which would allow the user to override if they really wanted to.
