Re: [gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml
On Sun, 7 Jun 2015 04:40:47 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Well, yes, but vgacon is rather dated, now. Never heard of a serial console? It's "dated" sure enough, but I for one use them on a daily basis, and not by choice. jer
Re: [gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml
Duncan wrote: > The point you made here was console-based workflow, as quoted above, > and that's what I addressed, arguing that even if was valid at some > point, it's no longer the factor it once was. For you, that is. Be aware that this creates your bias. You can't extrapolate from your own situation to a broad statement like the above with any kind of certanity. //Peter
[gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml
Andrew Savchenko posted on Mon, 08 Jun 2015 16:33:55 +0300 as excerpted: > On Sun, 7 Jun 2015 04:40:47 + (UTC) Duncan wrote: >> Andrew Savchenko posted on Sat, 06 Jun 2015 20:36:13 +0300 as >> excerpted: >> >> > It will never be finished, because console-based workflow is the most >> > efficient way to work for many people, especially for advanced >> > users/devs. >> >> Well, yes, but vgacon is rather dated, now. More folks are using high >> resolution framebuffer console mode >> So console-based workflow isn't so much of an excuse for 80-char lines, >> these days. Of course lines can be /too/ long. There's a reason >> newspapers and the like use multi-column printing, after all. > > You missed my point completely. 80 chars limit comes not from the > console width, but from the text readability[1]. [The subthread already says OT, allowing those who wish to killfile it, so...] 1) While that point was made (by you or someone else) elsewhere, it wasn't made in this subthread. The point you made here was console-based workflow, as quoted above, and that's what I addressed, arguing that even if was valid at some point, it's no longer the factor it once was. 2) Actually, I didn't miss the text readability point "completely", either. Thus the "Of course lines can be /too/ long" bit, specifically mentioning multi-column newspaper printing, etc. You quoted it, but apparently didn't read it? So differences, if any, appear to be only in degree, tho I'm already on record as saying it's bikeshedding either way. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml
On Sun, 7 Jun 2015 04:40:47 + (UTC) Duncan wrote: > Andrew Savchenko posted on Sat, 06 Jun 2015 20:36:13 +0300 as excerpted: > > > On Sat, 06 Jun 2015 18:35:41 +0600 Vadim A. Misbakh-Soloviov wrote: > >> > * linewidth >> 80 (why do we have this short limit still in 2015) > >> > >> Actually, I dislike that too, but the reason is simple: some people > >> still using text-mode terminals. > >> > >> // It would be nice to finally fix that, but let's be realistic: it > >> looks like it wouldn't be finished in the near 10 years :-/ > > > > It will never be finished, because console-based workflow is the most > > efficient way to work for many people, especially for advanced > > users/devs. > > Well, yes, but vgacon is rather dated, now. More folks are using high > resolution framebuffer console mode all the time, and with monitors > standardizing on 1920x1080 due to HDTV, well... my console mode is 320 > columns x 108 lines, now, and 80 chars... is just scrunched up on the > left quarter of the screen![1] > > Of course there's split-screen too, tho I think many are like me and > simply startx and run terminal windows if they want split-screen, so > haven't bothered configuring it at the frame-buffer console, but again, > even that's 160 width, over 100 width if 3-way-vert-split, and still 80 > width at 4-way-vert-split, which is getting a bit ridiculous. > > So console-based workflow isn't so much of an excuse for 80-char lines, > these days. Of course lines can be /too/ long. There's a reason > newspapers and the like use multi-column printing, after all. But 120 > char isn't too bad, and I expect most would find at least 100 char an > improvement over 80, which really begins to feel like the old 40-char > widths at some point. You missed my point completely. 80 chars limit comes not from the console width, but from the text readability[1]. It doesn't matter how wide one's physical monitor is. Text of 300 characters width will be barely readable. Of course if a code have large left indents for inner blocks, such code may exceed 80-chars barrier, but without left whitespace it should be within limits. Of course there are various exceptions like comments and so on. But as a rule of thumb too wide lines are not readable because eyes shift during line read is way too large. 60-80 chars limit comes from the science, not from the console width. Actually I suspect that console width was selected that way due to readability issues. [1] http://baymard.com/blog/line-length-readability Best regards, Andrew Savchenko pgpnMd5FIx_zK.pgp Description: PGP signature
Re: [gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml
On 07/06/15 18:54, Allan Wegan wrote: >> [1] Of course, 320x108 chars /is/ with a 42-inch TV as a monitor, but >> it's not exactly tiny print, either. I sit farther away from it than >> many people sit from their monitor. But even half of that is 160 >> chars width, which is what I used to use on my 21-inch. > > Now 160 sounds like two perfectly legible terminals side by side with 80 > chars each. ;) > > > I tend to like agreeing with others ;) I have 2 30" monitors running KDE and I often run Konsole in a window 1280 in width but this is really to enable me to easily split tmux panes (terminal on left, log on right). As such 80 (79 in PEP8 in Python) characters per line makes it much easier than relying upon (usually horrible) word wrapping. 120 is a thing I have seen but I think anything above that is pushing it in terms of readable. Obviously there are times when you break these rules, but most of time you can find a way not to that does not change your code or make it less optimal (for example, splitting by assigning a new variable just to break lines up, which could (prior to an optimisation stage) introduce a few opcodes that were not there before). Andrew
Re: [gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml
> [1] Of course, 320x108 chars /is/ with a 42-inch TV as a monitor, but > it's not exactly tiny print, either. I sit farther away from it than > many people sit from their monitor. But even half of that is 160 > chars width, which is what I used to use on my 21-inch. Now 160 sounds like two perfectly legible terminals side by side with 80 chars each. ;) -- Allan Wegan Jabber: allanwe...@jabber.ccc.de OTR-Fingerprint: A1AAA1B9C067F9884A424D339834346929164587 ICQ: 209459114 OTR-Fingerprint: 71DE5B5E67D6D758A93BF1CE7DA06625205AC6EC signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml
Andrew Savchenko posted on Sat, 06 Jun 2015 20:36:13 +0300 as excerpted: > On Sat, 06 Jun 2015 18:35:41 +0600 Vadim A. Misbakh-Soloviov wrote: >> > * linewidth >> 80 (why do we have this short limit still in 2015) >> >> Actually, I dislike that too, but the reason is simple: some people >> still using text-mode terminals. >> >> // It would be nice to finally fix that, but let's be realistic: it >> looks like it wouldn't be finished in the near 10 years :-/ > > It will never be finished, because console-based workflow is the most > efficient way to work for many people, especially for advanced > users/devs. Well, yes, but vgacon is rather dated, now. More folks are using high resolution framebuffer console mode all the time, and with monitors standardizing on 1920x1080 due to HDTV, well... my console mode is 320 columns x 108 lines, now, and 80 chars... is just scrunched up on the left quarter of the screen![1] Of course there's split-screen too, tho I think many are like me and simply startx and run terminal windows if they want split-screen, so haven't bothered configuring it at the frame-buffer console, but again, even that's 160 width, over 100 width if 3-way-vert-split, and still 80 width at 4-way-vert-split, which is getting a bit ridiculous. So console-based workflow isn't so much of an excuse for 80-char lines, these days. Of course lines can be /too/ long. There's a reason newspapers and the like use multi-column printing, after all. But 120 char isn't too bad, and I expect most would find at least 100 char an improvement over 80, which really begins to feel like the old 40-char widths at some point. --- [1] Of course, 320x108 chars /is/ with a 42-inch TV as a monitor, but it's not exactly tiny print, either. I sit farther away from it than many people sit from their monitor. But even half of that is 160 chars width, which is what I used to use on my 21-inch. Wrapping at 120 chars thus shouldn't be unreasonable at all. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
