[OT] Re: [gentoo-dev] Re: RFC: Indention in metadata.xml
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. Best regards, Andrew Savchenko pgpYPfQAj3Lr_.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: Indention in metadata.xml
On Sat, 06 Jun 2015 14:22:38 +0200 Justin Lecher (jlec) wrote: > Exactly, that was my intention. > > How about > > * indent with tab > * tab == 4 spaces > * linewidth >> 80 (why do we have this short limit still in 2015) Because of readability and ergonomics. The optimal page width is about 67 characters, see Knuth's work on that. Barring spaces and tabs that 67 will give approximately 80. Best regards, Andrew Savchenko pgp1SP1bYVXjs.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: Indention in metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/06/15 17:21, Michael Orlitzky wrote: > On 06/06/2015 08:22 AM, Justin Lecher (jlec) wrote: >> >> * linewidth >> 80 (why do we have this short limit still in >> 2015) >> > > It's ancient typographic wisdom that the optimal measure (number of > characters in column of text) is somewhere between 45 and 75. It > varies somewhat depending on the typeface and the leading (spacing > between lines, more or less), but everyone agrees that anything > over 80 is uncomfortable to read. > > There's always one guy who will claim that he's perfectly > comfortable reading a single line of text that extends into his > kitchen; rather than argue, the old 80-character terminal thing > gets cited. So that's not the real reason but you still hear it > because it's less subjective. > While I generally understand and agree with your argument, we are talking about problems which arise because of indention adding whitespaces in front. That means the effective content to read is much shorter. Plus it is markup so we have a significant portion of the line being semi-important to read. Justin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJVcxR7XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiusEP/3w9ldEOGD0HwUThJwN9m+3+ EA415TX0onbq2zOG7nj+8DvNHj/TAh/wz3cP+rl90D1q/fOdRGV9hHpQMeAhQVTT f7zpE9Kf9Em6Cv+DZMnK6HYWm9n51cDtoMVZZvKoyOwjM/kmAvFjwQx8EfYrOJ+p Ch7ceEv7j3TORWV6QynFtLSQtCvBckvgNwnuIHmyUfi+begt+LnpgB8Is4HfJgQr 0YPmP+pZFl0trmKQS6vyHTpEK2HqZ9OPIPFFwA6mjABesYe+qTt9FDgTf+CPzHVo rSM6F+82p+ZybShH+K7NNWKT17X0ePQf2+mKoSDVspft12+QKrZ2ceJnr4TOGVK4 mwYYkxcPatTNi5dkEL9JzQxiq5+hMPsDYJJDHdMldEmaubW5mP+0t1o7KPugQxF+ naX+Dxlbd7murkXOJw+9/3R2DlXLxPudlkTbggINSgZsa6ZQQnB3A/hFh+FgANZY +SPBpgGKTNVf3I13DydIVtvzPgIzHd69xD3jrNFD/wjHr78Ot/0gnpw0Sf9O6eeB Mbjnl/I2FyMzKA8y1kVlCCcivm88VrdPzt/E0yoRxKjCxaqzyrMzCpk5XPzpfR2t mJOYYYBoBsojDEtqUAGm30d6CJ6tHo9ChnFt8zFc7MNECwLyEqZe6V68IC7vifB5 Jsqwbqrsc0tnwdaJfKMA =q6KY -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: Indention in metadata.xml
On 06/06/2015 08:22 AM, Justin Lecher (jlec) wrote: > > * linewidth >> 80 (why do we have this short limit still in 2015) > It's ancient typographic wisdom that the optimal measure (number of characters in column of text) is somewhere between 45 and 75. It varies somewhat depending on the typeface and the leading (spacing between lines, more or less), but everyone agrees that anything over 80 is uncomfortable to read. There's always one guy who will claim that he's perfectly comfortable reading a single line of text that extends into his kitchen; rather than argue, the old 80-character terminal thing gets cited. So that's not the real reason but you still hear it because it's less subjective.
Re: [gentoo-dev] Re: RFC: Indention in metadata.xml
On 7 June 2015 at 00:22, Justin Lecher (jlec) wrote: > * linewidth >> 80 (why do we have this short limit still in 2015) I wouldn't say this is the reason... but there's a specific benefit for me at least with the font size I use and the screen size I have. Means you can fit 2 terminals in nicely side by side. Or a terminal and something else nicely side by side. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Re: RFC: Indention in metadata.xml
> * 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 :-/ -- Best regards, mva signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Indention in metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/06/15 14:07, Ulrich Mueller wrote: >> On Sat, 6 Jun 2015, Duncan wrote: > >>> *If* we should agree on using tabs, then we should also >>> standardise the tab width. Using the same rules for indenting >>> and whitespace as for ebuilds (i.e., tab stops every four >>> positions) suggests itself: >>> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html#i ndenting-and-whitespace > >>> >> (Somewhat) More seriously, standardizing the tab size defeats >> the purpose, letting people decide for themselves, particularly >> when it's to be the declared horizontal spacing standard in a >> file such as this, where mixed spaces and tabs can be avoided, so >> someone's personal setting shouldn't be mixed up by someone using >> spaces instead > > It plays a role when at the same time there is a policy about the > line width. For example, the devmanual has this (about _ebuilds_, > not about metadata.xml): > > # Where possible, try to keep lines no wider than 80 positions. # A > 'position' is generally the same as a character — tabs are four # > positions wide, and multibyte characters are just one position > wide. > > This would make no sense with the width of a tab being arbitrary. > >> (and if it is, the non-standard spaces in place of tabs is >> simply much more obvious, allowing easier detection /due/ to the >> non-standardized tabsize, and replacing with tabs as >> appropriate). > > I don't understand this part. We would have either spaces or tabs, > but not both. And e.g. Emacs can highlight tabs (with > whitespace-mode) so there's no problem seeing them. > >> But IMO it's all simply bikeshedding, regardless. > > Maybe. But standardising it could simplify life when updating > metadata files with a script. > Exactly, that was my intention. How about * indent with tab * tab == 4 spaces * linewidth >> 80 (why do we have this short limit still in 2015) Justin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJVcuYOXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmigYkQAIGipC0pMA0JcMTu4aoTM+jj 5T8QOd+zh7SxyuELiie6ZJV+JsccyXZsFZjqYOHptVfqsOuLXlhqv+mC/iAH/zjg pAqyA1BYbuf8D5j1liF7t85CT8K4C9gUfNOjIQbVMqaLubEO4+Kzc8ik+LQ4O9Ca 06Sp1bwtBbcNNzpsLZ/Xa60uCGWgdcopcLEujtP34AxSVfa9NgyWs7a1ceRKMv8m +9T3WryOB6dzLQu1da+nUIOnlkwxau0mlDuwA2F968F5ewbophRf+0Tn5FiSu/zb D0wm3LX0pPIk/l/r9BN7mZHh/yokO6iyMcGhSUyNdUys2G3b2LvOOoXW1MfX8SWE YlZVZhzpImG/yVJu6dr7LSHmXo4NNZ8ZZb7uTgKM2NvyO3tX0BZt8RyAXipRP5+X YFuXDf70zagnuAe/iUfw8+vFqb+JzShAvnD7DI7XpoKOkGl1W5XN06suDzUsSRfx F9lFUk4kD2Xwp0zZpTBncCAzcidSbikUQM/CaBATg+62PwvQisvSBtnz0+eGUSMI iUPj8fJhyuZCoYOPEq+wvTdQwYfpd8PLhKxlTEjDb2qY6uVbqxaznE2A6tmkBG9K 5MriinvGOkjdfxvv+rNwPiMDrnaTgljuXEg64mgUz/7/3m3jb1lyYHMIzoiJpIBH ynDhu68FZTXb+RUVc2wo =+HgJ -END PGP SIGNATURE-
[gentoo-dev] Re: RFC: Indention in metadata.xml
> On Sat, 6 Jun 2015, Duncan wrote: >> *If* we should agree on using tabs, then we should also standardise >> the tab width. Using the same rules for indenting and whitespace as >> for ebuilds (i.e., tab stops every four positions) suggests itself: >> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html#indenting-and-whitespace > (Somewhat) More seriously, standardizing the tab size defeats the > purpose, letting people decide for themselves, particularly when > it's to be the declared horizontal spacing standard in a file such > as this, where mixed spaces and tabs can be avoided, so someone's > personal setting shouldn't be mixed up by someone using spaces > instead It plays a role when at the same time there is a policy about the line width. For example, the devmanual has this (about _ebuilds_, not about metadata.xml): # Where possible, try to keep lines no wider than 80 positions. # A 'position' is generally the same as a character — tabs are four # positions wide, and multibyte characters are just one position wide. This would make no sense with the width of a tab being arbitrary. > (and if it is, the non-standard spaces in place of tabs is simply > much more obvious, allowing easier detection /due/ to the > non-standardized tabsize, and replacing with tabs as appropriate). I don't understand this part. We would have either spaces or tabs, but not both. And e.g. Emacs can highlight tabs (with whitespace-mode) so there's no problem seeing them. > But IMO it's all simply bikeshedding, regardless. Maybe. But standardising it could simplify life when updating metadata files with a script. Ulrich pgp9DnfebDQXI.pgp Description: PGP signature
[gentoo-dev] Re: RFC: Indention in metadata.xml
Ulrich Mueller posted on Sat, 06 Jun 2015 12:17:25 +0200 as excerpted: >> On Sat, 6 Jun 2015, Michał Górny wrote: > >> Visual space is what you set in your editor. Which also gives tab the >> advantage that you can set it to something good for you, like 'more >> than 2 spaces so that it is readable'. > > *If* we should agree on using tabs, then we should also standardise the > tab width. Using the same rules for indenting and whitespace as for > ebuilds (i.e., tab stops every four positions) suggests itself: > https://devmanual.gentoo.org/ebuild-writing/file-format/ index.html#indenting-and-whitespace The bike shed simply /must/ be black... with pink polka dots! =:^) (Somewhat) More seriously, standardizing the tab size defeats the purpose, letting people decide for themselves, particularly when it's to be the declared horizontal spacing standard in a file such as this, where mixed spaces and tabs can be avoided, so someone's personal setting shouldn't be mixed up by someone using spaces instead (and if it is, the non-standard spaces in place of tabs is simply much more obvious, allowing easier detection /due/ to the non-standardized tabsize, and replacing with tabs as appropriate). But IMO it's all simply bikeshedding, regardless. -- 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
