From: Intransition <transfire@...>
Date: 2012-03-11T05:30:09+09:00
Subject: Re: Configuration Convention

------=_Part_731_452422.1331411406532
Content-Type: multipart/alternative; 
	boundary="----=_Part_732_20562803.1331411406533"

------=_Part_732_20562803.1331411406533
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit



On Friday, March 9, 2012 11:20:43 PM UTC-5, Gavin Sinclair wrote:
>
> On Tue, Mar 6, 2012 at 2:14 PM, Intransition <transfire@gmail.com> wrote:
>
>> While there are obviously some files that will always remain (e.g. .git), 
>> I wonder if it is possible for a convention to ever develop to mitigate all 
>> this. Most likely that would be in the form of a common directory to hold 
>> all these files, although conceivably, it could be in the form of a couple 
>> of shared files --one for Ruby code and one for YAML.
>>
>
> I agree.  It's insane not to have all configuration files in a "config" 
> directory.  But you can understand how it's evolved, and sadly it's not 
> going to change.
>

I think there is a chance that it still could. Basically, I see two paths 
--a low road and a high road. The low road is simply that "directory 
listings" use a bit more intelligence in sorting order. Something like:

    .quietdir1/
    .quietdir2/
     nomaldir/
     Louddir/
     CAPSDIR/
    .quietrc1
    .quietrc2
    normal1.ext1
    normal3.ext1
    normal2.ext2
    Loudfiles1
    Loudfiles2
    CAPFILES1
    CAPFILES2

Something like that, maybe even offer a couple of intelligent variations 
(e.g. group the same extensions together or not). While not a true 
de-cluttering solution. It would at least help a lot. Maybe if enough of up 
put in support requests to Github they would incorporate something like 
this. And even easier, maybe someone could write a better `ls`?

The high road, on the other hand, is for a very sophisticted solution to be 
developed that has very compelling set of features, if then adopted by just 
one highly popular project, it stands a reasonable chance of wide-spread 
adoption.

These load and high roads are not mutually exclusive. So both are worth 
pursuit.


------=_Part_732_20562803.1331411406533
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<br><br>On Friday, March 9, 2012 11:20:43 PM UTC-5, Gavin Sinclair wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div class="gmail_quote">On Tue, Mar 6, 2012 at 2:14 PM, Intransition <span dir="ltr">&lt;<a href="mailto:transfire@gmail.com" target="_blank">transfire@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>While there are obviously some files that will always remain (e.g. .git), I wonder if it is possible for a convention to ever develop to mitigate all this. Most likely that would be in the form of a common directory to hold all these files, although conceivably, it could be in the form of a couple of shared files --one for Ruby code and one for YAML.</div>

<div></div></blockquote></div><br><div>I agree. &nbsp;It's insane not to have all configuration files in a "config" directory. &nbsp;But you can understand how it's evolved, and sadly it's not going to change.</div></blockquote><div><br>I think there is a chance that it still could. Basically, I see two paths --a low road and a high road. The low road is simply that "directory listings" use a bit more intelligence in sorting order. Something like:<br><br>
&nbsp;&nbsp;&nbsp; .quietdir1/<br>

&nbsp;&nbsp;&nbsp; .quietdir2/<br>&nbsp;&nbsp;&nbsp;&nbsp;

nomaldir/<br>&nbsp;&nbsp;&nbsp;&nbsp; Louddir/<br>&nbsp;&nbsp;&nbsp;&nbsp; CAPSDIR/<br>&nbsp;&nbsp;&nbsp; .quietrc1<br>
&nbsp;&nbsp;&nbsp; .quietrc2<br>&nbsp;&nbsp;&nbsp; normal1.ext1<br>
&nbsp;&nbsp;&nbsp; normal3.ext1<br>
&nbsp;&nbsp;&nbsp; normal2.ext2<br>
&nbsp;&nbsp;&nbsp; Loudfiles1<br>
&nbsp;&nbsp;&nbsp; Loudfiles2<br>
&nbsp;&nbsp;&nbsp; CAPFILES1<br>&nbsp;&nbsp;&nbsp; CAPFILES2<br><br>Something like that, maybe even offer a couple of intelligent variations (e.g. group the same extensions together or not). While not a true de-cluttering solution. It would at least help a lot. Maybe if enough of up put in support requests to Github they would incorporate something like this. And even easier, maybe someone could write a better `ls`?<br><br>The high road, on the other hand, is for a very sophisticted solution to be developed that has very compelling set of features, if then adopted by just one highly popular project, it stands a reasonable chance of wide-spread adoption.<br><br>These load and high roads are not mutually exclusive. So both are worth pursuit.<br><br></div>
------=_Part_732_20562803.1331411406533--

------=_Part_731_452422.1331411406532--