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?