[gentoo-dev] RFC: Indention in metadata.xml

[gentoo-dev] RFC: Indention in metadata.xml

[Justin Lecher (jlec)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi everyone,

Can we get an agreement on how we are indenting metadata.xml?

I like to properly format and indent metadata.xml, but without having
an agreement or policy on the indention, I make unhappy by choosing
the wrong.

The two options which are already suggested are

* 2 spaces
* single tab

So what should it be?

Jusitn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJVcqCPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmivxIP/3Vdv8fLVThtEdjknncX8txq
DSEj1m+pEqVw53noSQscbvjRkiAiGg50xtZFC5zcJVC7cRSIAADGUByakt7w+Lmk
D2cHWfQLJr5ZqGMholHdHJC7G7PXDJZ4D90Rt8qL7I1aGjMzWtGXzkzx2+OD+j8F
jy8XAa2I30/Rgof+fsUp1mgglv5c4Y94CbJcnkbERuyxA5miB2d1E3i3iiIcoLmB
M2fs0DN3oOQT8Fhwp2fJhoRH+aXlayC8o5PbBEKc6xGU5nfvtfvqqGHa9eoqLgXv
vpZXIwKm9vujXoPi7DDBMKAPPqDD1OSKBV0fvbwx0Q94H7XzmSmtFW45gPdAyrF2
rwL3dlLcswDsblv46LHmj+m3/VFJagSccrKaH/I4uf4z2+RhjwNO2R+Z66/EYH3n
hvoYWQTx0Y+YI2kKKpXymK5e9ZgO7x+dxBHwLpa13JcJP0sMESQbN4jmJ5Rob0xV
bqtTsn+/O/rB1iMMC2V1fq3cQT9AQZT3OKnyiXM6nwLDgae30cY4gCUkOqc/ULxp
Eakb5D82HlSWIo840BXNAoGOWI7vFrtaKndDukWn+kKk1SeKm3j2ocwzQ7Rzxsa8
60hfE2tsuo0wQBLxslxYyZnv/kPBS9PS8RtZrLpS5V6D4BGS/32zuBVhN1eP9dQ0
dz0kj1uvehcz5/Dhgms4
=e7QN
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Patrick Lauer]

On 06/06/15 09:26, Justin Lecher (jlec) wrote:
> Hi everyone,
> 
> Can we get an agreement on how we are indenting metadata.xml?
> 
> I like to properly format and indent metadata.xml, but without having
> an agreement or policy on the indention, I make unhappy by choosing
> the wrong.
> 
> The two options which are already suggested are
> 
> * 2 spaces
> * single tab
> 
> So what should it be?

Obviously a tab, as tabs were made for indentation.

Re: [gentoo-dev] RFC: Indention in metadata.xml

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

On Sat, 06 Jun 2015 09:25:33 +0200
Patrick Lauer <patrick@gentoo.org> wrote:

> On 06/06/15 09:26, Justin Lecher (jlec) wrote:
> > Hi everyone,
> > 
> > Can we get an agreement on how we are indenting metadata.xml?
> > 
> > I like to properly format and indent metadata.xml, but without
> > having an agreement or policy on the indention, I make unhappy by
> > choosing the wrong.
> > 
> > The two options which are already suggested are
> > 
> > * 2 spaces
> > * single tab
> > 
> > So what should it be?
> 
> Obviously a tab, as tabs were made for indentation.

Tabs for me too, please. It's worth noting that metagen uses tabs.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

Dnia 2015-06-06, o godz. 09:26:08
"Justin Lecher (jlec)" <jlec@gentoo.org> napisał(a):

> Can we get an agreement on how we are indenting metadata.xml?
> 
> I like to properly format and indent metadata.xml, but without having
> an agreement or policy on the indention, I make unhappy by choosing
> the wrong.
> 
> The two options which are already suggested are
> 
> * 2 spaces
> * single tab
> 
> So what should it be?

A tab. With one-line element contents being inline, while multi-line in
deeper indented block, i.e.:

...><maintainer>
...>...><name>Foo Bar</name>
...>...><email>bar@example.com</email>
...></maintainer>
...><longdescription>
...>...>Some random text. Possibly spanning multiple lines.
...>...>Like this.
...></longdescription>


-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Jason Zaman]

On Sat, Jun 06, 2015 at 09:34:41AM +0200, Michał Górny wrote:
> Dnia 2015-06-06, o godz. 09:26:08
> "Justin Lecher (jlec)" <jlec@gentoo.org> napisał(a):
> 
> > Can we get an agreement on how we are indenting metadata.xml?
> > 
> > I like to properly format and indent metadata.xml, but without having
> > an agreement or policy on the indention, I make unhappy by choosing
> > the wrong.
> > 
> > The two options which are already suggested are
> > 
> > * 2 spaces
> > * single tab
> > 
> > So what should it be?
> 
> A tab. With one-line element contents being inline, while multi-line in
> deeper indented block, i.e.:
> 
> ...><maintainer>
> ...>...><name>Foo Bar</name>
> ...>...><email>bar@example.com</email>
> ...></maintainer>
> ...><longdescription>
> ...>...>Some random text. Possibly spanning multiple lines.
> ...>...>Like this.
> ...></longdescription>

This one definitely. Tabs let people set the tabstop themselves and its
all easy. Can we get repoman to autoformat the xml files during a commit
too?

-- Jason

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 219 bytes --]

>>>>> On Sat, 06 Jun 2015, Justin Lecher (jlec) wrote:

> * 2 spaces
> * single tab

> So what should it be?

Tabs are too wasteful on space. Therefore, two spaces, and no
indentation of the top-level elements.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

Dnia 2015-06-06, o godz. 09:46:27
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >>>>> On Sat, 06 Jun 2015, Justin Lecher (jlec) wrote:
> 
> > * 2 spaces
> > * single tab
> 
> > So what should it be?
> 
> Tabs are too wasteful on space. Therefore, two spaces, and no
> indentation of the top-level elements.

That's nonsense. Tab = 1 byte. Two spaces = 2 bytes.


-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 243 bytes --]

>>>>> On Sat, 6 Jun 2015, Michał Górny wrote:

>> Tabs are too wasteful on space. Therefore, two spaces, and no
>> indentation of the top-level elements.

> That's nonsense. Tab = 1 byte. Two spaces = 2 bytes.

Visual space.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Jason Zaman]

On Sat, Jun 06, 2015 at 10:02:53AM +0200, Ulrich Mueller wrote:
> >>>>> On Sat, 6 Jun 2015, Michał Górny wrote:
> 
> >> Tabs are too wasteful on space. Therefore, two spaces, and no
> >> indentation of the top-level elements.
> 
> > That's nonsense. Tab = 1 byte. Two spaces = 2 bytes.
> 
> Visual space.

:set ts=2
done :)
> 
> Ulrich

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

Dnia 2015-06-06, o godz. 10:02:53
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >>>>> On Sat, 6 Jun 2015, Michał Górny wrote:
> 
> >> Tabs are too wasteful on space. Therefore, two spaces, and no
> >> indentation of the top-level elements.
> 
> > That's nonsense. Tab = 1 byte. Two spaces = 2 bytes.
> 
> Visual space.

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'.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

>>>>> 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

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: RFC: Indention in metadata.xml

[Duncan]

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

[gentoo-dev] Re: RFC: Indention in metadata.xml

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

>>>>> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: RFC: Indention in metadata.xml

[Justin Lecher (jlec)]

-----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

iQJ8BAEBCgBmBQJVcuYOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
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-----

Re: [gentoo-dev] Re: RFC: Indention in metadata.xml

[Vadim A. Misbakh-Soloviov]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

> * 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[OT] Re: [gentoo-dev] Re: RFC: Indention in metadata.xml

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml

[Duncan]

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

Re: [gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml

[Allan Wegan]

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

> [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: allanwegan@jabber.ccc.de
 OTR-Fingerprint: A1AAA1B9C067F9884A424D339834346929164587
ICQ: 209459114
 OTR-Fingerprint: 71DE5B5E67D6D758A93BF1CE7DA06625205AC6EC


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml

[Andrew Udvare]

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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2633 bytes --]

On Sun, 7 Jun 2015 04:40:47 +0000 (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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

[gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml

[Duncan]

Andrew Savchenko posted on Mon, 08 Jun 2015 16:33:55 +0300 as excerpted:

> On Sun, 7 Jun 2015 04:40:47 +0000 (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

[Peter Stuge]

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

Re: [gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml

[Jeroen Roovers]

On Sun, 7 Jun 2015 04:40:47 +0000 (UTC)
Duncan <1i5t5.duncan@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: RFC: Indention in metadata.xml

[Kent Fredric]

[-- Attachment #1.1: Type: text/plain, Size: 447 bytes --]

On 7 June 2015 at 00:22, Justin Lecher (jlec) <jlec@gentoo.org> 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

[-- Attachment #1.2: Type: text/html, Size: 1207 bytes --]

[-- Attachment #2: sn122.png --]
[-- Type: image/png, Size: 84947 bytes --]

Re: [gentoo-dev] Re: RFC: Indention in metadata.xml

[Michael Orlitzky]

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

[Justin Lecher (jlec)]

-----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

iQJ8BAEBCgBmBQJVcxR7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

On 06 Jun 2015 12:17, Ulrich Mueller wrote:
> >>>>> 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

if there's any standard at all for metadata.xml, it should be the same as 
ebuilds.  there's no reason to deviate.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Allan Wegan]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

> The two options which are already suggested are
> * 2 spaces
> * single tab
> So what should it be?

Two spaces per indention with a maximum line width of 80 single-width
Unicode grapheme clusters (equals the with of 80 ASCII characters).



-- 
Allan Wegan
Jabber: allanwegan@jabber.ccc.de
 OTR-Fingerprint: A1AAA1B9C067F9884A424D339834346929164587
ICQ: 209459114
 OTR-Fingerprint: 71DE5B5E67D6D758A93BF1CE7DA06625205AC6EC



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Andreas K. Huettel]

Am Samstag, 6. Juni 2015, 09:26:08 schrieb Justin Lecher (jlec):
> Hi everyone,
> 
> Can we get an agreement on how we are indenting metadata.xml?
> 
> I like to properly format and indent metadata.xml, but without having
> an agreement or policy on the indention, I make unhappy by choosing
> the wrong.
> 
> The two options which are already suggested are
> 
> * 2 spaces
> * single tab
> 
> So what should it be?

How about the unicode character for a right-aligned tab, together with the nonbreaking half-width space?

</me bangs head against table and goes back to the perl virtuals. less pain.>

  

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Mike Gilbert]

On Sat, Jun 6, 2015 at 3:26 AM, Justin Lecher (jlec) <jlec@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi everyone,
>
> Can we get an agreement on how we are indenting metadata.xml?
>
> I like to properly format and indent metadata.xml, but without having
> an agreement or policy on the indention, I make unhappy by choosing
> the wrong.
>
> The two options which are already suggested are
>
> * 2 spaces
> * single tab
>
> So what should it be?

My 2 cents: So long as it is a well-formed XML document and doesn't
look horribly ugly in an editor, it really doesn't matter what we use,
and I don't think we need a policy for it.

For scripting, I would recommend using an XML parser/emitter.
Compatibility with sed scripts is not something I care about.

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Alexis Ballier]

On Sat, 6 Jun 2015 22:00:14 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> Compatibility with sed scripts is not something I care about.

and is something nobody should care about: xml is not a regular
language :)

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Andrew Udvare]

On 07/06/15 05:12, Alexis Ballier wrote:
> On Sat, 6 Jun 2015 22:00:14 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
> 
>> Compatibility with sed scripts is not something I care about.
> 
> and is something nobody should care about: xml is not a regular
> language :)
> 

If you are enforcing split lines on every single tag except ones that
can be shortened like <tag />, then it does not matter if you use 4
spaces or tabs. Both would be compatible with sed assuming the indenting
is correct in either case. With regard to white space within tags is
another story. The rule should still apply there and so compatibility
would remain.

However, I do not disagree an XML parser is better than sed for the
purpose. There are plenty of XML pretty printers.

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Justin Lecher (jlec)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/06/15 14:48, Andrew Udvare wrote:
> On 07/06/15 05:12, Alexis Ballier wrote:
>> On Sat, 6 Jun 2015 22:00:14 -0400 Mike Gilbert
>> <floppym@gentoo.org> wrote:
>> 
>>> Compatibility with sed scripts is not something I care about.
...
> However, I do not disagree an XML parser is better than sed for
> the purpose. There are plenty of XML pretty printers.
> 

So you guys think I am using sed for this? Really?

Still you need to tell a XML formatter what indention style to use.

Justin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJVdKaSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiepMP/j+/jp2yP0Jqj8UKzbTkWbND
2cD2fJdn5op9rfbAt4NuVFofU3/MbnaloITsadHNV1j3Nz9fX2sTB4sr5GPrRNfj
K+nqdLA7TCsCY0OVMGerCEmkCQ/pfzmcHjm4G3Ktx8GDmOPD7dkt5abMez2phz+A
uXJwKrLyQxk/o5OxuryMU1VFLw7oyDRgbo4tJi8Rp4ZCeeT2UpHmr6T1wgrhgfk3
K59kN3NPz86t7u/9sRSD4RteGZrLrisAXFzwMkiRvmy7ZtPRgbao5zWronqOPe7Z
N6yhCUXqaWi3aRS0Rx+Bfn6QHwVat4xTYVcNV2DIN5FWAiwe1PS4zKSi1cSts7rU
6ARAOkwz3DZ6v9PFT+y2QawGvN6Ve1TEvKsl5gmFrhOHaejiNYE4EyF7sYt3aqmk
hv2Wh+E+q6qjYy6ghOUuMgiCNHhAw1966nRPMJF8H1baLrTZSZU1E+MGYdx0EcFu
EmsnHGqAjbFFVtesTf+FN6KDf/YOeppt8ReKJ88SY8zy0z5AwQ4tUC+DcnGukFDt
n1yz+innTSgVce0oKdB8dheaBliTu6aNXlee+9jya1gevijb8axM9Q9xK281Fa8j
rewFaQHqxmXVKkACTavcskDMrW3OQMs5to60yTTXnRxyja0riJ8a1xlG0DwAl45h
COAKrMqMqsH93qw1TD1w
=a8iK
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

Dnia 2015-06-07, o godz. 22:16:18
"Justin Lecher (jlec)" <jlec@gentoo.org> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 07/06/15 14:48, Andrew Udvare wrote:
> > On 07/06/15 05:12, Alexis Ballier wrote:
> >> On Sat, 6 Jun 2015 22:00:14 -0400 Mike Gilbert
> >> <floppym@gentoo.org> wrote:
> >> 
> >>> Compatibility with sed scripts is not something I care about.
> ...
> > However, I do not disagree an XML parser is better than sed for
> > the purpose. There are plenty of XML pretty printers.
> > 
> 
> So you guys think I am using sed for this? Really?
> 
> Still you need to tell a XML formatter what indention style to use.

Not exactly. You can write a tool that tries hard to recognize
indentation style and repeat it. Like the one I wrote to replace
<herd/> with <maintainer/> elements. It was pretty good in figuring out
developer fancies, including multiple different indentation levels.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Justin (jlec)]

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

On 07/06/15 22:22, Michał Górny wrote:
> Dnia 2015-06-07, o godz. 22:16:18
> "Justin Lecher (jlec)" <jlec@gentoo.org> napisał(a):
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> On 07/06/15 14:48, Andrew Udvare wrote:
>>> On 07/06/15 05:12, Alexis Ballier wrote:
>>>> On Sat, 6 Jun 2015 22:00:14 -0400 Mike Gilbert
>>>> <floppym@gentoo.org> wrote:
>>>>
>>>>> Compatibility with sed scripts is not something I care about.
>> ...
>>> However, I do not disagree an XML parser is better than sed for
>>> the purpose. There are plenty of XML pretty printers.
>>>
>>
>> So you guys think I am using sed for this? Really?
>>
>> Still you need to tell a XML formatter what indention style to use.
> 
> Not exactly. You can write a tool that tries hard to recognize
> indentation style and repeat it. Like the one I wrote to replace
> <herd/> with <maintainer/> elements. It was pretty good in figuring out
> developer fancies, including multiple different indentation levels.
> 

I am trying to detect what ever they already is for indention. How did you
implement this?

Justin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Michał Górny]

[-- Attachment #1.1: Type: text/plain, Size: 1441 bytes --]

Dnia 2015-06-08, o godz. 08:36:02
"Justin (jlec)" <jlec@gentoo.org> napisał(a):

> On 07/06/15 22:22, Michał Górny wrote:
> > Dnia 2015-06-07, o godz. 22:16:18
> > "Justin Lecher (jlec)" <jlec@gentoo.org> napisał(a):
> > 
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA512
> >>
> >> On 07/06/15 14:48, Andrew Udvare wrote:
> >>> On 07/06/15 05:12, Alexis Ballier wrote:
> >>>> On Sat, 6 Jun 2015 22:00:14 -0400 Mike Gilbert
> >>>> <floppym@gentoo.org> wrote:
> >>>>
> >>>>> Compatibility with sed scripts is not something I care about.
> >> ...
> >>> However, I do not disagree an XML parser is better than sed for
> >>> the purpose. There are plenty of XML pretty printers.
> >>>
> >>
> >> So you guys think I am using sed for this? Really?
> >>
> >> Still you need to tell a XML formatter what indention style to use.
> > 
> > Not exactly. You can write a tool that tries hard to recognize
> > indentation style and repeat it. Like the one I wrote to replace
> > <herd/> with <maintainer/> elements. It was pretty good in figuring out
> > developer fancies, including multiple different indentation levels.
> > 
> 
> I am trying to detect what ever they already is for indention. How did you
> implement this?

Script attached. Pretty much it looks it tries to figure out what
indent is used for first- and second-level elements, and reproduces
that.


-- 
Best regards,
Michał Górny

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: herdfix.py --]
[-- Type: text/x-python, Size: 3184 bytes --]

#!/usr/bin/env python

from collections import namedtuple
import errno
import glob
from lxml.builder import E
import lxml.etree
import os
import os.path

def main():
	herdtuple = namedtuple('herdtuple', ('email', 'name'))
	herddb = {}
	portdir = '/var/db/repos/gentoo'
	herdsfile = os.path.join(portdir, 'metadata/herds.xml')
	herdsxml = lxml.etree.parse(herdsfile)
	for h in herdsxml.getroot():
		k = h.find('name').text
		e = h.find('email').text
		d = h.find('description').text
		herddb[k] = herdtuple(e, d)

	intree = portdir
	outtree = '/tmp/1'

	# LAZINESS!
	for f in glob.glob(os.path.join(intree, '*/*/metadata.xml')):
		subpath = os.path.relpath(f, intree)
		print(subpath)
		outf = os.path.join(outtree, subpath)

		xml = lxml.etree.parse(f)
		herds = xml.getroot().findall('herd')
		if not herds: # yay, one file less to care about
			continue
		r = xml.getroot()
		maints = r.findall('maintainer')
		if maints:
			insertpoint = maints[-1]
		else:
			insertpoint = herds[-1]

		# try to guess indentation
		def all_texts(node):
			first = True
			for e in node:
				if first:
					yield node.text
					first = False
				yield e.tail
		def all_indents(node):
			for t in all_texts(node):
				if t is None:
					yield ''
					return
				spl = t.split('\n')
				# go to last line without text
				for l in spl:
					if l.lstrip(' \t') != '':
						break
				# go to the last line
				t = l[:len(l) - len(l.lstrip(' \t'))]
				yield t
		def sub_indents(node):
			for e in node:
				for x in all_indents(e):
					yield x


		# some random defaults
		indent = '\t'
		try:
			indent = max(all_indents(r), key=len)
		except ValueError:
			pass

		inner_indent = indent*2 if indent else '\t'
		try:
			inner_indent = max(sub_indents(r), key=len)
		except ValueError:
			pass

		# start adding new herds after maintainers
		for h in herds:
			he = herddb[h.text.strip()]

			# look for duplicate <herd/> entries
			for m in maints:
				if m.find('email').text.strip() == he.email:
					m.set('type', 'herd')
					r.remove(h)
					break
			else:
				attrs = dict(h.items())
				attrs['type'] = 'team'
				nm = E.maintainer('\n',
					inner_indent, E.email(he.email), '\n',
					indent,
					**attrs
				)
				nextinsert = insertpoint.getnext()
				nm.tail = insertpoint.tail
				if nextinsert is not None:
					r.insert(r.index(nextinsert), nm)
				else:
					# avoid extra indent
					nm.tail = '\n'
					r.append(nm)
				insertpoint = nm

				# now we can remove it safely
				r.remove(h)

				# now fix pre-indent
				prev = nm.getprevious()
				if prev is not None:
					prev.tail = '\n' + indent
				else:
					nm.getparent().text = '\n' + indent

		try:
			os.makedirs(os.path.dirname(outf))
		except OSError as e:
			if e.errno != errno.EEXIST:
				raise
		try:
			os.unlink(outf)
		except OSError as e:
			if e.errno != errno.ENOENT:
				raise
		xml.write(outf, encoding='UTF-8', xml_declaration='1.0')
		# yay, add trailing newline because lxml is dumb
		with open(outf, 'ab') as f:
			f.write(b'\n')

if __name__ == '__main__':
	main()

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Mike Gilbert]

On Sun, Jun 7, 2015 at 4:16 PM, Justin Lecher (jlec) <jlec@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 07/06/15 14:48, Andrew Udvare wrote:
>> On 07/06/15 05:12, Alexis Ballier wrote:
>>> On Sat, 6 Jun 2015 22:00:14 -0400 Mike Gilbert
>>> <floppym@gentoo.org> wrote:
>>>
>>>> Compatibility with sed scripts is not something I care about.
> ...
>> However, I do not disagree an XML parser is better than sed for
>> the purpose. There are plenty of XML pretty printers.
>>
>
> So you guys think I am using sed for this? Really?
>
> Still you need to tell a XML formatter what indention style to use.
>

Sorry, I could I have sworn I saw something about "easier scripting"
somewhere in the thread.

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Jeroen Roovers]

On Sun, 7 Jun 2015 17:28:03 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> Sorry, I could I have sworn I saw something about "easier scripting"
> somewhere in the thread.

Now you have two problems. ;-)


     jer

Re: [gentoo-dev] RFC: Indention in metadata.xml

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

On Sat, Jun 06, 2015 at 09:26:08AM +0200, Justin Lecher (jlec) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Hi everyone,
> 
> Can we get an agreement on how we are indenting metadata.xml?
> 
> I like to properly format and indent metadata.xml, but without having
> an agreement or policy on the indention, I make unhappy by choosing
> the wrong.
> 
> The two options which are already suggested are
> 
> * 2 spaces
> * single tab
> 
> So what should it be?

I want to throw in my support for the second option.

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Daniel "zlg" Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/08/2015 12:47 PM, William Hubbs wrote:
> On Sat, Jun 06, 2015 at 09:26:08AM +0200, Justin Lecher (jlec)
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>> 
>> Hi everyone,
>> 
>> Can we get an agreement on how we are indenting metadata.xml?
>> 
>> I like to properly format and indent metadata.xml, but without
>> having an agreement or policy on the indention, I make unhappy by
>> choosing the wrong.
>> 
>> The two options which are already suggested are
>> 
>> * 2 spaces * single tab
>> 
>> So what should it be?
> 
> I want to throw in my support for the second option.
> 
> Thanks,
> 
> William
> 
I'm also in favor of tabs. Aside from being shorter (by a single byte,
in this case), they're less prone to off-by-one inconsistencies and
any good text editor allows the user to configure the tab width, so
everyone can be happy.

Just my two cents.

~Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVdiq3AAoJEAEkDpRQOeFwFnMQANYOy+A9D8wU8RQjXtUm5fEO
FcK+vXyigt+ENholJVl4NYkL6z7l8dTx5PbjZ4qYUgM0hqwraUI8h69gmXe2r4c+
3r3FSaLofQ8ePlmaBQOJMw6OTJu9P2VULVh90bByj+2NKzu07aVHkRevzerzvl5F
uhiRSQvPNNYCxSrYL+Q5SLKtdfpny+gg9npoNkeoQPSzu/GujicxBisTHb8jaBEs
gcP1iSTsvrf8nhYzgxwmKpyDbeBH2V8rUMFOv800m6lbbfXChDHUrOEX81Jxs72/
wfjbEpSFz0Dkhd/WFu4ApMvgaQesT7NudRg5q+YV35aDyx6gXkvdKPyWzNv5FmVd
dDmODWnV7oLm8BymhQaqNZOauh/7LlEjKIRTATGow+IWoqwTVgyVw0lp4DmA3n0L
Mz8+WgaNfEERYct+Pbrc3MkQsQ7DsyAp8GWQ8b+j2SsNXjsVD2bjB58mKv4udda/
Nj8f8mdu43+O9zRXl385r7U5Nbb3foI9fyvJsN1GyPE+8LDHvs5LDvFDY41Yz3Nk
IWaEbEiWGAo5zLOfgld2NOtq8VB7kIMLwF2xhsMfHzO0oQKisPBOH7Ab2x29DvL/
TreinTiDyLtKzlJ6+bprIqH6dTXflaNzHsVzoXQiu9XDdb3hIpXTXup5hlDUZxT6
TZ4zilhFAeYHUjzOOyli
=lB7e
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 3043 bytes --]

On Sat, Jun 6, 2015 at 12:26 AM, Justin Lecher (jlec) <jlec@gentoo.org>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi everyone,
>
> Can we get an agreement on how we are indenting metadata.xml?
>
> I like to properly format and indent metadata.xml, but without having
> an agreement or policy on the indention, I make unhappy by choosing
> the wrong.
>

I was going to stay out of this, but I want to kind of circle back a bit.
You want to 'properly format' the documents. I guess part of my question
is, what would you do if the proper format was basically undefined?

"Properly formatted" XML files isn't really what I consider a goal. Do you
have other goals?

For instance:

"I would like to standardize on spaces or tabs so that we can better
automate the tooling around metadata."

Or perhaps more clearly:

"I am writing tools that manipulate metadata.xml; while I can easily ingest
metadata.xml, producing the correct output is difficult when spaces or tabs
are mixed, can we consistently use one or the other?"

Or another take:

"I am trying to write a tool that manipulates metadata.xml and I am having
difficulty parsing entries that mix spaces and tabs, please help me."

Some of these problems are solved by code (I'm pretty sure the latter
problem just requires a sane XML parser for instance.) I believe mgorny
already provided code that tried to solve problem 2.

Problem 1 is sufficiently generic that it is hard to solve with a code
snippet I think.

The point is these are all goals other than "I want to standardize on tabs
or spaces because I like starting tabs vs spaces flamewars on gentoo-dev."
This is not meant to be accusatory; merely that standardizing the format
"because" doesn't really solve anything (there is no problem statement.)
Perhaps there is an implied statement (consistency is generally better for
all parties.) But even that being clearly stated would be nice.

-A


>
> The two options which are already suggested are
>
> * 2 spaces
> * single tab
>
> So what should it be?


> Jusitn
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0
>
> iQJ8BAEBCgBmBQJVcqCPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
> OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmivxIP/3Vdv8fLVThtEdjknncX8txq
> DSEj1m+pEqVw53noSQscbvjRkiAiGg50xtZFC5zcJVC7cRSIAADGUByakt7w+Lmk
> D2cHWfQLJr5ZqGMholHdHJC7G7PXDJZ4D90Rt8qL7I1aGjMzWtGXzkzx2+OD+j8F
> jy8XAa2I30/Rgof+fsUp1mgglv5c4Y94CbJcnkbERuyxA5miB2d1E3i3iiIcoLmB
> M2fs0DN3oOQT8Fhwp2fJhoRH+aXlayC8o5PbBEKc6xGU5nfvtfvqqGHa9eoqLgXv
> vpZXIwKm9vujXoPi7DDBMKAPPqDD1OSKBV0fvbwx0Q94H7XzmSmtFW45gPdAyrF2
> rwL3dlLcswDsblv46LHmj+m3/VFJagSccrKaH/I4uf4z2+RhjwNO2R+Z66/EYH3n
> hvoYWQTx0Y+YI2kKKpXymK5e9ZgO7x+dxBHwLpa13JcJP0sMESQbN4jmJ5Rob0xV
> bqtTsn+/O/rB1iMMC2V1fq3cQT9AQZT3OKnyiXM6nwLDgae30cY4gCUkOqc/ULxp
> Eakb5D82HlSWIo840BXNAoGOWI7vFrtaKndDukWn+kKk1SeKm3j2ocwzQ7Rzxsa8
> 60hfE2tsuo0wQBLxslxYyZnv/kPBS9PS8RtZrLpS5V6D4BGS/32zuBVhN1eP9dQ0
> dz0kj1uvehcz5/Dhgms4
> =e7QN
> -----END PGP SIGNATURE-----
>
>

[-- Attachment #2: Type: text/html, Size: 4062 bytes --]

Re: [gentoo-dev] RFC: Indention in metadata.xml

[Justin (jlec)]

[-- Attachment #1: Type: text/plain, Size: 3679 bytes --]

On 09/06/15 03:21, Alec Warner wrote:
> On Sat, Jun 6, 2015 at 12:26 AM, Justin Lecher (jlec) <jlec@gentoo.org
> <mailto:jlec@gentoo.org>> wrote:
> 
> Hi everyone,
> 
> Can we get an agreement on how we are indenting metadata.xml?
> 
> I like to properly format and indent metadata.xml, but without having
> an agreement or policy on the indention, I make unhappy by choosing
> the wrong.
> 
> 
>> I was going to stay out of this, but I want to kind of circle back a bit. You
>> want to 'properly format' the documents. I guess part of my question is, what
>> would you do if the proper format was basically undefined?
> 
>> "Properly formatted" XML files isn't really what I consider a goal. Do you have
>> other goals?
> 
>> For instance:
> 
>> "I would like to standardize on spaces or tabs so that we can better automate
>> the tooling around metadata."
> 
>> Or perhaps more clearly:
> 
>> "I am writing tools that manipulate metadata.xml; while I can easily ingest
>> metadata.xml, producing the correct output is difficult when spaces or tabs are
>> mixed, can we consistently use one or the other?"
> 
>> Or another take:
> 
>> "I am trying to write a tool that manipulates metadata.xml and I am having
>> difficulty parsing entries that mix spaces and tabs, please help me."
> 
>> Some of these problems are solved by code (I'm pretty sure the latter problem
>> just requires a sane XML parser for instance.) I believe mgorny already provided
>> code that tried to solve problem 2.
> 
>> Problem 1 is sufficiently generic that it is hard to solve with a code snippet I
>> think.
> 
>> The point is these are all goals other than "I want to standardize on tabs or
>> spaces because I like starting tabs vs spaces flamewars on gentoo-dev." This is
>> not meant to be accusatory; merely that standardizing the format "because"
>> doesn't really solve anything (there is no problem statement.) Perhaps there is
>> an implied statement (consistency is generally better for all parties.) But even
>> that being clearly stated would be nice.
> 
>> -A

Hi Alec,

you are absolutely right. Having stated the goal more clearly would have help to
decide what it should be.

Nevertheless, I think the flames are quite small this time, and we rather heard
two opinions with their arguments.

The two options and the arguments are

tabs:
	* made for indention
	* Gentoo uses tabs everywhere
	... and similar

2 spaces:
	* save space (2 spaces) on the 80 char line width

As XML ignores whitespaces per specification, the only rational argument is,
that Gentoo uses tabs in ebuilds, eclass, basically everywhere so we should also
use it in metadata.xml.

Or simply leave it to the maintainer with tabs (=4 spaces) as default or 2
spaces if wished.

So that is what we should decide on.


Coming back to your original point, the why.

I really like proper indentions.

That is why I started some while ago doing

xmlstarlet fo metadata.xml

using tabs on every commit. As you can imaging that upset some people so I
switched to 2 spaces, which was also not good.

The acute reason to come up with now, is my effort to fill the remote-id tags in
metadata.xml. xmlstarlet uses 2 spaces on insert, so I need to reformat the file
afterwards for consistency reason. Instead of finding to used indention style
and use that, I thought it might be useful to have a common style which can be
always applied. That would ease my effort and also future ones.

We could even do the formatting directly via repoman on every commit.

I hope that brought some substance to my question,

Justin




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]