Re: manpage text width
Hi Ingo, In article <20180329235743.ge59...@athene.usta.de> Ingo Schwarzewrote: > > Can I do anything to fix this? > > Yes. > I've always wondered why groff did that nonsense with man pages. I remember discussing this same issue in groff mailing lists years ago (with E. Raymond). In my opinion, thank you Ingo or whoever had the good idea of not doing the same with mandoc. Walter
Re: manpage text width
> Don't you already need this logic, getenv(3) + isatty(3), to decide if > you use a pager or not? Although I don't understand why getenv(3) is > needed, isn't a TIOCGWINSZ ioctl(2) enough?. Because there is a defacto standard that some SVR2 environment (before the ioctl) be honoured by many programs. Few comments: Scripts can tweak them to create output for a specific layout. They allow adjustment on non-tty circumstance. The priority of getenv vs tty layout vs default isn't precisely specified anywhere, and is a mess I wish someone would study and try to cleanup. During pledge development, this stuff stuff in the way, it was quite interesting - I spent the entire Exeter hackathon on it.
Re: manpage text width
On 3/31/18, Andras Farkas wrote: > On Fri, Mar 30, 2018 at 11:23 AM, Chris Bennett wrote: >> This is very important. Our brains just are not good at working with >> long lines. This is hard-wired. If anyone doesn't believe me, try >> setting your browser window to a narrower width or use reader mode. >> We read by mapping things out on the line. If it's too long, our brains >> get "confused" and information is lost. > Is there any research backing this up? [snip] Yes and no. The preferences of long or short lines might depend on the individual doing the reading. There is a study which seems highly visible despite the small data set: "No effects of line length were found for comprehension or satisfaction, however, users indicated a strong preference for either the short or long line lengths." >From "The Effects of Line Length on Reading Online News" (2005) (Warning for PDF) http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.503.2885=rep1=pdf But there is a generally accepted optimal range allegedly listed in Robert Bringhurst's "The Elements of Typographic Style" : "Anything from 45 to 75 characters is widely-regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal." quoted from "The Line Length Misconception" https://www.viget.com/articles/the-line-length-misconception/ /Lars
Re: manpage text width
On Fri, Mar 30, 2018 at 01:57:43AM +0200, Ingo Schwarze wrote: > I do *NOT* want to add SIGWINCH signal handling to man(1) to abort > less(1), reformat, and respawn less(1) in that case. That kind of > magic would be over the top, and SIGWINCH is an abomination in the > first place. Why on earth would you think so ?... I've been dealing with SIGWINCH without real issues in a few programs and it works really nice.
Re: manpage text width
On Fri, Mar 30, 2018 at 11:23 AM, Chris Bennettwrote: > This is very important. Our brains just are not good at working with > long lines. This is hard-wired. If anyone doesn't believe me, try > setting your browser window to a narrower width or use reader mode. > We read by mapping things out on the line. If it's too long, our brains > get "confused" and information is lost. Is there any research backing this up? I've seen this sentiment twice in this thread, but man's column limit has always been the most dreaded part about man for me. (I'm very happy to find I can change it with -Owidth) I've found that doubling it to 160 columns has always been far, far more comfortable for me, so I have doubt that the 80/78 column limit is anything more than a tradition looking for any reason to continue existing. If a user resizes their terminal before running a program, it makes perfect sense for text to wrap to the terminal's size, just like with programs that simply use stdout to output text.
Re: manpage text width
On 31/03/18(Sat) 03:20, Ingo Schwarze wrote: > Paul Irofti wrote on Fri, Mar 30, 2018 at 11:23:54AM +0300: > [...] > > which is EXACTLY what I was looking for! Can it be the default? :) > > I'm neither particularly enthusiastiastic (because it requires > more code, in particular more getenv(3) which i dislike in general, > and because it adds another difference in behaviour depending on > isatty(3)) nor am im categorically rejecting the request. Don't you already need this logic, getenv(3) + isatty(3), to decide if you use a pager or not? Although I don't understand why getenv(3) is needed, isn't a TIOCGWINSZ ioctl(2) enough?. > If a few developers consider the feature useful, i shall implement > it; if nobody else speaks up, i'm more likely to KISS it. I'd greatly appreciate this default as well.
Re: manpage text width
Hi Paul, Paul Irofti wrote on Fri, Mar 30, 2018 at 11:23:54AM +0300: > Ingo Schwarze wrote: >> * Nowadays, i guess that terminals narrower than 80 columns >>have become seriously rare, so there is not very widespread >>benefit for that case. > Maybe that was true when we still had 4:3 screens, but now I always > have 2 or 3 80 column xterms and space for another that is around 60 > columns. I see. I typically use three xterms side-by-side and for the remaining space on the left a slightly overlapping one that i use more rarely. When is use it, i often get away with only seeing the leftmost columns; when i need to see all columns, i temporarily switch it to the foreground. Purely a matter of taste, of course. I see that your approach makes sense, too. > So I guess a better choice would be: > > $ alias man='man -Owidth=$(($COLUMNS<80?($COLUMNS-2):78))' Sure, that seems reasonable for the usecase. > which is EXACTLY what I was looking for! Can it be the default? :) I'm neither particularly enthusiastiastic (because it requires more code, in particular more getenv(3) which i dislike in general, and because it adds another difference in behaviour depending on isatty(3)) nor am im categorically rejecting the request. If a few developers consider the feature useful, i shall implement it; if nobody else speaks up, i'm more likely to KISS it. Yours, Ingo
Re: manpage text width
Fri, 30 Mar 2018 08:23:12 -0700 Chris Bennett> On Thu, Mar 29, 2018 at 11:57:43PM +, Ingo Schwarze wrote: > > I *could* maybe teach man(1) to honour $COLUMN by default when > > starting up in interactive mode, but i did not do so for the following > > reasons: > > > > * Many people are using terminals wider than 80 columns, but > >texts get hard to read when much wider than that. Very long > >lines become hard to follow. (That's why newspapers usually > >have columns of even less than 80 characters, but they don't > >have as much indentation as manual pages either.) > > This is very important. Our brains just are not good at working with > long lines. This is hard-wired. If anyone doesn't believe me, try Hi Chris, Technical limitation of historic hardware, miscellaneous topics > misc@ https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_punched_card_format_and_character_codes https://en.wikipedia.org/wiki/Characters_per_line#History Kind regards, Anton Lazarov
Re: manpage text width
On Thu, Mar 29, 2018 at 11:57:43PM +, Ingo Schwarze wrote: > I *could* maybe teach man(1) to honour $COLUMN by default when > starting up in interactive mode, but i did not do so for the following > reasons: > > * Many people are using terminals wider than 80 columns, but >texts get hard to read when much wider than that. Very long >lines become hard to follow. (That's why newspapers usually >have columns of even less than 80 characters, but they don't >have as much indentation as manual pages either.) This is very important. Our brains just are not good at working with long lines. This is hard-wired. If anyone doesn't believe me, try setting your browser window to a narrower width or use reader mode. We read by mapping things out on the line. If it's too long, our brains get "confused" and information is lost. This is a problem with textbooks. The wide pages are needed for pictures and diagrams, but the text should be written in narrower columns. It's interestng that older hardware caused us to use narrow widths, but that turns out to be best anyway. Could anybody really follow code written at 200 columns width? Chris Bennett
Re: manpage text width
On Fri, Mar 30, 2018 at 01:57:43AM +0200, Ingo Schwarze wrote: > When you want a manpage to exactly fill the available terminal width, > you can use an alias like this: > > $ alias wman='man -Owidth=$COLUMNS'# or > $ alias wman='man -Owidth=$((COLUMNS-2))' > > Of course, if you change the terminal width while man(1) is open, > you will have to do: q Ctrl-p to reformat. There's also `fc' for that, nicely wrapped in ksh by default: $ type r r is an alias for 'fc -s' For tmux, I'm used to having the right-most pane reserved for manual pages. The following tmux.conf helps a lot: bind M resize-pane -x 82
Re: manpage text width
Hi Ingo, Thanks for the detailed reply. I was expecting it :) > * Nowadays, i guess that terminals narrower than 80 columns >have become seriously rare, so there is not very widespread >benefit for that case. Maybe that was true when we still had 4:3 screens, but now I always have 2 or 3 80 column xterms and space for another that is around 60 columns. I always use the small one for trivial tasks like searching for something in the filesystem, doing some calculations or, you guessed it, reading a manpage. > $ alias wman='man -Owidth=$COLUMNS'# or > $ alias wman='man -Owidth=$((COLUMNS-2))' So I guess a better choice would be: $ alias man='man -Owidth=$(($COLUMNS<80?($COLUMNS-2):78))' which is EXACTLY what I was looking for! Can it be the default? :) Thank you, Paul
Re: manpage text width
On Fri, Mar 30, 2018 at 01:57:43AM +0200, Ingo Schwarze wrote: > Hi Paul, > > Theo de Raadt wrote on Thu, Mar 29, 2018 at 04:17:14PM -0600: > > piroft@ wrote: > > >> Is there any reason why manpage text does not resize nicely > >> with <80 columns xterms? > > I want to avoid excessive magic. > > By the way, actually, the default width is 78, not 80. > By tradition. > > >> Is it because of less(1)? > > No. less(1) always wraps and re-wraps its input file to fit the > terminal width. Of course, it preserves existing line breaks, it > only adds new ones, and it adds the new ones after the last character > that fits on each line, possibly in the middle of words and numbers. > > > Can I do anything to fix this? > > Yes. > > When you want a manpage to exactly fill the available terminal width, > you can use an alias like this: > > $ alias wman='man -Owidth=$COLUMNS'# or > $ alias wman='man -Owidth=$((COLUMNS-2))' > > Of course, if you change the terminal width while man(1) is open, > you will have to do: q Ctrl-p to reformat. > > I do *NOT* want to add SIGWINCH signal handling to man(1) to abort > less(1), reformat, and respawn less(1) in that case. That kind of > magic would be over the top, and SIGWINCH is an abomination in the > first place. > > If you are in the habit of always using 65-column terminals on a given > machine, this is another option: > > # echo output width 64 >> /etc/man.conf > > I *could* maybe teach man(1) to honour $COLUMN by default when > starting up in interactive mode, but i did not do so for the following > reasons: > > * Many people are using terminals wider than 80 columns, but >texts get hard to read when much wider than that. Very long >lines become hard to follow. (That's why newspapers usually >have columns of even less than 80 characters, but they don't >have as much indentation as manual pages either.) I'm not asking for this feature but CSS has max-width for cases like this in HTML. It always fills the width until the maximum. > * Nowadays, i guess that terminals narrower than 80 columns >have become seriously rare, so there is not very widespread >benefit for that case. > * Even if someone does use a narrower terminal, formatting will >be somewhat poor with the matching -Owidth. Some text, in >particular literal displays, will still overflow and wrap in >less(1), and text with large indentations will become >ridiculously narrow. >One thing jmc@ does is trying to make sure that pages do not >only read well, but also look visually nice, and much of that >work is optimized for the default -Owidth=78. >So even for narrower terminals, i'd rather leave the decision >to the user. > * Setting up an alias as explained above is quite easy. > > What i could maybe do is recognize "-Owidth=auto" and "output width > auto" in man.conf(5) and use $COLUMNS in that case, but even that > would require some additional code, and so far, i didn't notice > much demand. > > > It is pre-formatted. > > Only in the sense than man(1) completes the formatting before it > forks and executes less(1). Only the manual pages of 25 (out of > 9900) ports are still preformatted at port build time, and none in > the base system and Xenocara are preformatted at system build time. > > Yours, > Ingo > -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: manpage text width
Hi Paul, Theo de Raadt wrote on Thu, Mar 29, 2018 at 04:17:14PM -0600: > piroft@ wrote: >> Is there any reason why manpage text does not resize nicely >> with <80 columns xterms? I want to avoid excessive magic. By the way, actually, the default width is 78, not 80. By tradition. >> Is it because of less(1)? No. less(1) always wraps and re-wraps its input file to fit the terminal width. Of course, it preserves existing line breaks, it only adds new ones, and it adds the new ones after the last character that fits on each line, possibly in the middle of words and numbers. > Can I do anything to fix this? Yes. When you want a manpage to exactly fill the available terminal width, you can use an alias like this: $ alias wman='man -Owidth=$COLUMNS'# or $ alias wman='man -Owidth=$((COLUMNS-2))' Of course, if you change the terminal width while man(1) is open, you will have to do: q Ctrl-p to reformat. I do *NOT* want to add SIGWINCH signal handling to man(1) to abort less(1), reformat, and respawn less(1) in that case. That kind of magic would be over the top, and SIGWINCH is an abomination in the first place. If you are in the habit of always using 65-column terminals on a given machine, this is another option: # echo output width 64 >> /etc/man.conf I *could* maybe teach man(1) to honour $COLUMN by default when starting up in interactive mode, but i did not do so for the following reasons: * Many people are using terminals wider than 80 columns, but texts get hard to read when much wider than that. Very long lines become hard to follow. (That's why newspapers usually have columns of even less than 80 characters, but they don't have as much indentation as manual pages either.) * Nowadays, i guess that terminals narrower than 80 columns have become seriously rare, so there is not very widespread benefit for that case. * Even if someone does use a narrower terminal, formatting will be somewhat poor with the matching -Owidth. Some text, in particular literal displays, will still overflow and wrap in less(1), and text with large indentations will become ridiculously narrow. One thing jmc@ does is trying to make sure that pages do not only read well, but also look visually nice, and much of that work is optimized for the default -Owidth=78. So even for narrower terminals, i'd rather leave the decision to the user. * Setting up an alias as explained above is quite easy. What i could maybe do is recognize "-Owidth=auto" and "output width auto" in man.conf(5) and use $COLUMNS in that case, but even that would require some additional code, and so far, i didn't notice much demand. > It is pre-formatted. Only in the sense than man(1) completes the formatting before it forks and executes less(1). Only the manual pages of 25 (out of 9900) ports are still preformatted at port build time, and none in the base system and Xenocara are preformatted at system build time. Yours, Ingo
Re: manpage text width
> Is there any reason why manpage text does not resize nicely with <80 > columns xterms? Is it because of less(1)? Can I do anything to fix this? It is pre-formatted.
manpage text width
Hi, Is there any reason why manpage text does not resize nicely with <80 columns xterms? Is it because of less(1)? Can I do anything to fix this? Thanks, Paul