I get all you're saying, but I don't think it's relevant. This is for people who want to WRITE code, so hiding their code from them in a config directory doesn't make sense.

I'm fine with putting config files in those hidden directories(although I feel compelled to say that XDG makes that you complicated), but not source code that people want to edit. People shouldn't have to play ls -a hide and seek to find their own source code...

On March 12, 2014 11:20:23 PM CDT, Daniel Herring <dherring@tentpost.com> wrote:
On Wed, 12 Mar 2014, Robert P. Goldman wrote:

 I am sorry, but I promise you that this will NOT be consistent with XDG. I have no idea why those people think it's a good idea to put files in directories where ls cannot find them.
 
 ASDF already has a deeply-nested, invisible-to-ls location that is XDG compliant where you can put your files if that's what floats your boat.
 
 It was writing a description of where to put your files in this XDG-compliant location that convinced me that we needed an alternative that was obvious and easily accessible.
 
 In case you haven't guessed, I'm not a fan of this standard! :-)

I would agree that XDG is over-engineered and under-specified.

However, ls finds dot files just fine (alias ls="ls -A" if it helps), and 
"normal use
 rs"
usually install programs in "system directories", not their 
home directory.

Given the current CL ecosystem, things are constantly changing, 
implementations provide little fasl compatibility, CL installs are often 
per-user, etc.  Thus the current best default for sources is in $HOME.  I 
would argue that the use of $HOME is the real problem, and "hiding" things 
is the right solution for users (as opposed to developers who can be 
expected to memorize a slightly obscure path).

Two default paths is not better than one.

There is a reason MS Windows has "hide system files" enabled by default. 
Some things are too complicated for "casual users", and an obscure 
"~/common-lisp" is just asking for grandma to delete the folder she 
"doesn't want"...

In systems like OS-X-style "disk images" and Java-style jarfiles, the 
entire application is self-contained.  Thus it is quite appropriate fo
 r 
the full path to be user-visible, for deleting the file is uninstalling 
the app.

- Daniel

P.S.  In case I've gone off-kilter, I promise to get some sleep before any 
further replies.


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.