Re: [gentoo-pms] Fill column

Re: [gentoo-pms] Fill column

[Ulrich Mueller]

>>>>> On Sun, 17 Jan 2010, Ciaran McCreesh wrote:

> Oh heck no. There's no excuse for using 70 or 80 columns for source
> code any more. My old laptop can fit 100 across the screen
> comfortably, which is much cleaner to work with.

Some people use several windows side by side, and the natural width of
these windows is 80 columns because almost all code adheres to it.

And we are talking about LaTeX source code that is mostly human
readable language. Readability suffers if lines have more than 60 or
70 characters.

Ulrich

Re: [gentoo-pms] Fill column

[Ciaran McCreesh]

2010/1/17 Ulrich Mueller <ulm@gentoo.org>:
>>>>>> On Sun, 17 Jan 2010, Ciaran McCreesh wrote:
>> Oh heck no. There's no excuse for using 70 or 80 columns for source
>> code any more. My old laptop can fit 100 across the screen
>> comfortably, which is much cleaner to work with.
>
> Some people use several windows side by side, and the natural width of
> these windows is 80 columns because almost all code adheres to it.

Almost all code does not adhere to it. 80 columns is a harmful legacy
that needs to be abandoned now that we are no longer limited by 1970s
terminals.

> And we are talking about LaTeX source code that is mostly human
> readable language. Readability suffers if lines have more than 60 or
> 70 characters.

Except that we're using fixed width fonts and reading non-hyphenated
source code, and we are reading it on a screen, not in print.

-- 
Ciaran McCreesh

Re: [gentoo-pms] Fill column

[Brian Harring]

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

On Sun, Jan 17, 2010 at 02:26:34PM +0000, Ciaran McCreesh wrote:
> 2010/1/17 Ulrich Mueller <ulm@gentoo.org>:
> >>>>>> On Sun, 17 Jan 2010, Ciaran McCreesh wrote:
> >> Oh heck no. There's no excuse for using 70 or 80 columns for source
> >> code any more. My old laptop can fit 100 across the screen
> >> comfortably, which is much cleaner to work with.
> >
> > Some people use several windows side by side, and the natural width of
> > these windows is 80 columns because almost all code adheres to it.
> 
> Almost all code does not adhere to it. 80 columns is a harmful legacy
> that needs to be abandoned now that we are no longer limited by 1970s
> terminals.

I'm not a particular fan of doing things just because of historical 
inertia.  That said, there are benefits to 80- namely, a shitload of 
source/text/etc is aimed at 80.  I'm not arrogant anything to claim 
"almost all code does not adhere to it"; I'll state the majority I 
work with on a day to day basis does however follow 80 w/ exemptions 
were appropriate.

Regardless, what works best for everyone is what should be used.  The 
'git blame' arguement would normally be valid, but in my opinion it's 
irrelevant in this case- it's a one time blip in tracing the source, 
further, the commit msgs used for PMS are of pretty varying quality 
thus decreasing the usefulness of blame.  Beyond that, blame is more 
of a source tool then text tool in terms of usefulness- I honestly 
can't think of the last time I had to do blame/annotate on PMS.

Either way, if the majority of folks find it easiest to work w/ an 80 
limit, go with 80.  I'd say the same if the magical number was 100 or 
unlimited.

Whatever makes it easiest for people to contribute and work on the 
document should win out- to be clear, I'm talking about the majority 
of folk not what best suits one person.

Personally, I prefer 80- if it'll help improve the source level 
reading of PMS and enough folks want it, I'm +1.  Barring that, +0.

~harring

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

Re: [gentoo-pms] Fill column

[David Leverton]

2010/1/19 Brian Harring <ferringb@gmail.com>:
> Beyond that, blame is more
> of a source tool then text tool in terms of usefulness- I honestly
> can't think of the last time I had to do blame/annotate on PMS.

FWIW, I used it on PMS every now and again.

[gentoo-pms] EXPORT_FUNCTIONS

[Ulrich Mueller]

What is the reason for the following restriction:
"EXPORT_FUNCTIONS must be used at most once per eclass."

Eclasses could be cleaner if the following was allowed:
   EXPORT_FUNCTIONS src_unpack src_compile
   if <some EAPI condition>; then
       EXPORT_FUNCTIONS src_prepare src_configure
   fi

Looks like none of the three package managers would have any trouble
with it. (And it's used in the tree already.)

Ulrich

[gentoo-pms] Re: EXPORT_FUNCTIONS

[Ulrich Mueller]

>>>>> On Mon, 1 Feb 2010, I wrote:

> What is the reason for the following restriction:
> "EXPORT_FUNCTIONS must be used at most once per eclass."

If nobody knows a reason for it, then I suggest removing of this
sentence.

Ulrich


From a048b02f31a4c69fcdf0498d49eef9e387f389e3 Mon Sep 17 00:00:00 2001
From: Ulrich Mueller <ulm@gentoo.org>
Date: Fri, 5 Feb 2010 21:19:23 +0100
Subject: [PATCH] Remove restriction that EXPORT_FUNCTIONS must be used only once.


Signed-off-by: Ulrich Mueller <ulm@gentoo.org>
---
 eclasses.tex |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/eclasses.tex b/eclasses.tex
index 9aeec91..b3ad13b 100644
--- a/eclasses.tex
+++ b/eclasses.tex
@@ -71,8 +71,6 @@ should the author wish to override it he can access the function in \t{foo.eclas
 \t{EXPORT\_FUNCTIONS} must only be used on ebuild phase functions. The function that is aliased
 must be named \t{eclassname\_phasefunctionname}, where \t{eclassname} is the name of the eclass.
 
-\t{EXPORT\_FUNCTIONS} must be used at most once per eclass.
-
 % vim: set filetype=tex fileencoding=utf8 et tw=100 spell spelllang=en :
 
 %%% Local Variables:
-- 
1.6.6.1

Re: [gentoo-pms] Re: EXPORT_FUNCTIONS

[David Leverton]

On Friday 05 February 2010 20:21:11 Ulrich Mueller wrote:
> >>>>> On Mon, 1 Feb 2010, I wrote:
> >
> > What is the reason for the following restriction:
> > "EXPORT_FUNCTIONS must be used at most once per eclass."
>
> If nobody knows a reason for it, then I suggest removing of this
> sentence.
>
> Ulrich

git log -S'at most once per eclass' implies that vapier asked for this to be 
added, but doesn't say why.  vapier, do you remember what the reason was?

[gentoo-pms] Clarify line continuation in make.defaults

[Jacob Godserv]

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

This patch fixes a fairly small issue, but one that "got" me enough
times, while writing a PMS-compatible tool, to make me want to patch.

The wording on how a quoted string might continue over more than one
line is only barely enough to grasp its meaning. It requires some deep
logical thought to figure out what's actually meant here, so I've
added a little bit of extra explanation.

I found that nano set to COLUMNS=107 produced word wrapping similar to
the rest of the file, but let me know if I missed other formatting
rules I ought to know about.

-- 
    Jacob

    "For then there will be great distress, unequaled
    from the beginning of the world until now — and never
    to be equaled again. If those days had not been cut
    short, no one would survive, but for the sake of the
    elect those days will be shortened."

    Are you ready?

[-- Attachment #2: profiles.tex.patch --]
[-- Type: application/octet-stream, Size: 750 bytes --]

--- profiles.tex	2010-01-13 13:28:25.103670768 -0500
+++ profiles.tex	2010-01-13 13:35:50.712458151 -0500
@@ -58,7 +58,8 @@
 \item Variables to the right of the equals sign in the form \t{\$\{foo\}} or \t{\$foo} are recognised and
   expanded from variables previously set in this or earlier \t{make.defaults} files.
 \item One logical line may be continued over multiple physical lines by escaping the newline with a
-  backslash. This is also permitted inside quoted strings.
+  backslash. A quoted string may also continue over multiple physical lines in this fasion, so that 
+  the quoted string can begin, continue, and end on two or more separate lines.
 \item Backslashes, except for line continuations, are not allowed.
 \end{compactitem}
 

Re: [gentoo-pms] Clarify line continuation in make.defaults

[Christian Faulhammer]

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

Hi,

Jacob Godserv <jacobgodserv@gmail.com>:
> The wording on how a quoted string might continue over more than one
> line is only barely enough to grasp its meaning. It requires some deep
> logical thought to figure out what's actually meant here, so I've
> added a little bit of extra explanation.

 That's fine by me.  If you prepare the patch with git format-patch,
you would be able to see your name in the VCS system.  We will wait for
comments from others, thanks for your contribution.

> I found that nano set to COLUMNS=107 produced word wrapping similar to
> the rest of the file, but let me know if I missed other formatting
> rules I ought to know about.

 A thing I would like to talk about it.  Why is the line wrap the way
it is?  Emacs always complains and he has the authority regarding line
wrap.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-pms] Fill column (was: Re: Clarify line continuation in make.defaults)

[Ulrich Mueller]

>>>>> On Wed, 13 Jan 2010, Christian Faulhammer wrote:

>  A thing I would like to talk about it.  Why is the line wrap the way
> it is?  Emacs always complains and he has the authority regarding line
> wrap.

Lines with a width of 100 characters are hard to read, therefore I
would much prefer a more conventional value like 70 or 72. Maybe with
exceptions for some of the tables.

A good time for making such a change would be when EAPI 3 is finished.
What do you think?

Ulrich

Re: [gentoo-pms] Fill column (was: Re: Clarify line continuation in make.defaults)

[Ciaran McCreesh]

2010/1/17 Ulrich Mueller <ulm@gentoo.org>:
>>>>>> On Wed, 13 Jan 2010, Christian Faulhammer wrote:
>>  A thing I would like to talk about it.  Why is the line wrap the way
>> it is?  Emacs always complains and he has the authority regarding line
>> wrap.
>
> Lines with a width of 100 characters are hard to read, therefore I
> would much prefer a more conventional value like 70 or 72. Maybe with
> exceptions for some of the tables.
>
> A good time for making such a change would be when EAPI 3 is finished.
> What do you think?

Oh heck no. There's no excuse for using 70 or 80 columns for source
code any more. My old laptop can fit 100 across the screen
comfortably, which is much cleaner to work with.

This bikeshed does not need repainting bright pink with orange spots.

-- 
Ciaran McCreesh

Re: [gentoo-pms] Fill column

[Christian Faulhammer]

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

Hi,

Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:
> > Lines with a width of 100 characters are hard to read, therefore I
> > would much prefer a more conventional value like 70 or 72. Maybe
> > with exceptions for some of the tables.
> >
> > A good time for making such a change would be when EAPI 3 is
> > finished. What do you think?
> 
> Oh heck no. There's no excuse for using 70 or 80 columns for source
> code any more. My old laptop can fit 100 across the screen
> comfortably, which is much cleaner to work with.

 We don't talk about source code but continous text even if having some
mark-up around.  And best readability for such text is around 60
characters per line, languages with long words may have more.

> This bikeshed does not need repainting bright pink with orange spots.

 And you don't want us to argue about the colour, right?

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-pms] Fill column

[Ciaran McCreesh]

2010/1/17 Christian Faulhammer <fauli@gentoo.org>:
>> Oh heck no. There's no excuse for using 70 or 80 columns for source
>> code any more. My old laptop can fit 100 across the screen
>> comfortably, which is much cleaner to work with.
>
>  We don't talk about source code but continous text even if having some
> mark-up around.  And best readability for such text is around 60
> characters per line, languages with long words may have more.

And the *generated* text is wrapped that way, or however else we want
it to be. We're discussing the source code, however, which is a whole
other thing, and none of your readability studies for printed texts
are relevant for it.

>> This bikeshed does not need repainting bright pink with orange spots.
>
>  And you don't want us to argue about the colour, right?

I don't want you to go and break 'git blame' etc and screw around with
something that doesn't need changing, yes. The not-quite-arbitrary
decision of "what fits on my laptop screen" that was originally made
is equally as good as or better than any alternative.

-- 
Ciaran McCreesh

Re: [gentoo-pms] Fill column

[Christian Faulhammer]

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

Hi,

Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:
> 2010/1/17 Christian Faulhammer <fauli@gentoo.org>:
> >> Oh heck no. There's no excuse for using 70 or 80 columns for source
> >> code any more. My old laptop can fit 100 across the screen
> >> comfortably, which is much cleaner to work with.
> >
> >  We don't talk about source code but continous text even if having
> > some mark-up around.  And best readability for such text is around
> > 60 characters per line, languages with long words may have more.
> 
> And the *generated* text is wrapped that way, or however else we want
> it to be. We're discussing the source code, however, which is a whole
> other thing, and none of your readability studies for printed texts
> are relevant for it.

 But usually I read diffs on the screen and seldomly read PMS in
formatted text, so not my readability studies but scientific facts
apply here as well.

> I don't want you to go and break 'git blame' etc and screw around with
> something that doesn't need changing, yes. The not-quite-arbitrary
> decision of "what fits on my laptop screen" that was originally made
> is equally as good as or better than any alternative.

 git blame is an argument, right.  The line wrapping goes on my nerve
for quite some time but I postponed any complaints until some real work
is done.

V-Li


-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-pms] Fill column

[Ciaran McCreesh]

2010/1/17 Christian Faulhammer <fauli@gentoo.org>:
>  git blame breakage is no argument here, as the initial import damages
> that anyway.

No, that's still useful, since it shows things that've been around
since the beginning and that haven't been tidied up.

> Usually everyone agrees on 80 characters

80 characters is for people who use dumb terminals that don't support
any other size. It's annoyingly restrictive for anything else.

> Derivating from that must be justified better than "it fits my screen".

No, changing it from what it is currently requires better
justification than "a piece of hardware that no-one's used for twenty
years does it that way".

Also, please stop stealthily changing bits of wrapping as you go
along. That's even worse.

-- 
Ciaran McCreesh

Re: [gentoo-pms] Fill column

[Ciaran McCreesh]

2010/1/17 Ulrich Mueller <ulm@kph.uni-mainz.de>:
>>>>>> On Sun, 17 Jan 2010, Ciaran McCreesh wrote:
>> 80 characters is for people who use dumb terminals that don't support any other size. It's annoyingly restrictive for anything else.
>
> Then let's change it to 300 characters width, which can be easily displayed on modern dual-headed displays. 100 characters is still too restrictive and cramps my style.

Since you're now being silly, I take it we all agree upon leaving it
as it is. Good.

-- 
Ciaran McCreesh