I've open the following bug on launchpad for this issue:
A non-hidden default source tree
https://bugs.launchpad.net/asdf/+bug/1293278
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
A programming language is low level
when its programs require attention to the irrel
>>: Faré
>: janderson
>> Daniel, if you want changes only every 5 to 10 years, do like
>> janderson: try an upgrade every 5 years, find that it breaks your code
>> somehow and downgrade back to the old version without further
>> investigation. Then maybe 10 years from now you'll get the system
>>
>>> They weren't done in secret, but many of them were just commits with no
>>> discussion on the list.
>>>
>> As long as the change hasn't been released, it's up for discussion.
>
> Do you seriously expect people to review the commit stream for
> potentially harmful changes/addition ?
>
Can you na
On Thu, 2014-03-13 at 14:52 -0400, Faré wrote:
> >> It's not like my changes were done in secret.
> >
> > They weren't done in secret, but many of them were just commits with no
> > discussion on the list.
> >
> As long as the change hasn't been released, it's up for discussion.
Do you seriously e
>> It's not like my changes were done in secret.
>
> They weren't done in secret, but many of them were just commits with no
> discussion on the list.
>
As long as the change hasn't been released, it's up for discussion.
And it's much easier to discuss code that was committed than ideas in
the air.
> Where are the release notes ? asdf-3.0.3.tar.gz(a tar bomb) contains no
> such thing, nor the git repository.
>
The debian/changelog doubles as release notes. I just updated the
README to point at them.
Release notes are otherwise posted to this mailing-list as part of
each release's announcemen
I smell a need for a CDR, c'nest pas?
Tersely pecked on my iPad
On Mar 13, 2014, at 18:42, Faré wrote:
> : dherring
: sionescu
>>> : rpgoldman
>> : sionescu
>
> For essential infrastructure like what ASDF claims to be, I expect major
> changes to happen less than once every 5
On Thu, 2014-03-13 at 13:42 -0400, Faré wrote:
[...]
> force and force-not were done well. The interaction between the two
> was not well thought out, but obviously no one relied on the
> interaction before force-not was implemented, so that was backward
> compatible, and the recent change keeps th
Daniel Herring wrote:
> In systems like OS-X-style "disk images" and Java-style jarfiles, the
> entire application is self-contained. Thus it is quite appropriate for
> the full path to be user-visible, for deleting the file is uninstalling
> the app.
FWIW, Faré's new bundle operations begin to g
: dherring
>>>: sionescu
>>: rpgoldman
>: sionescu
For essential infrastructure like what ASDF claims to be, I expect major
changes to happen less than once every 5 to 10 years.
Daniel, if you want changes only every 5 to 10 years, do like
janderson: try an upgrade every 5 years
Stelian Ionescu wrote:
> The backwards-compatibility is not complete, though. When we're talking
> about glibc, we're talking about versioning functions and keeping the
> old entry points bug-to-bug compatible for ever while the new version of
> that function is simply an addition.
That's simply n
Stelian Ionescu wrote:
> Issuing a warning that OPERATION is being directly subclassed is not
> backwards-compatibility.
For the record, that is NOT the solution that has been pushed.
Instead, after a lot of discussion from Faré, Anton, and others, we
developed a solution that preserved the funct
On Thu, 2014-03-13 at 11:34 -0500, Robert P. Goldman wrote:
> Stelian Ionescu wrote:
> > On Wed, 2014-03-12 at 23:30 -0400, Daniel Herring wrote:
> >> On Wed, 12 Mar 2014, Faré wrote:
> >>
> >>> Major changes like that happen less than once a year (ASDF 2 in 2010,
> >>> ASDF 3 in 2013, ASDF 3.1 soo
Stelian Ionescu wrote:
> On Wed, 2014-03-12 at 23:30 -0400, Daniel Herring wrote:
>> On Wed, 12 Mar 2014, Faré wrote:
>>
>>> Major changes like that happen less than once a year (ASDF 2 in 2010,
>>> ASDF 3 in 2013, ASDF 3.1 soon in 2014), and while
>>> backward-compatibility has always been a huge
good morning;
On 13 Mar 2014, at 08:34, Attila Lendvai wrote:
>> I *do* get the objection that Pascal had, and I absolutely agree that we
>> should not choose a directory name that will collide with existing
>> users' directories.
>
>
> […]
>
> but hopefully by the time my children are old en
On Wed, 2014-03-12 at 23:30 -0400, Daniel Herring wrote:
> On Wed, 12 Mar 2014, Faré wrote:
>
> > Major changes like that happen less than once a year (ASDF 2 in 2010,
> > ASDF 3 in 2013, ASDF 3.1 soon in 2014), and while
> > backward-compatibility has always been a huge priority, improvements
> >
If asdf provides a simple and well documented way of disabling a default
directory, the it can be any name. Then it can be ensured that future users are
happy, and at the same time, current setups are unaffected.
Pascal
Sent from my iPad
On 13 Mar 2014, at 08:34, Attila Lendvai wrote:
>> I *
> I *do* get the objection that Pascal had, and I absolutely agree that we
> should not choose a directory name that will collide with existing
> users' directories.
when reading this i imagined my future child some decades down the road
reading the ASDF manual (hopefull only for historical reaso
> Ok good. Then how about having ASDF loudly announce that it is registering
> the default directory (e.g. ~/cl/), as well as providing the hint about
> using a .conf file with the right syntax with :tree, if the user wants to
> exclude certain subdirectories.
>
> The goal here is to make the addit
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 c
>>: rpgoldman
>: dherring
>> 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
>>
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
Seriously, my source code is not config data, so IMO the XDG standard has
nothing to say about where it's placed. Unlike the case for config files.
If my source code is to be hidden from me in a config directory what, pray tell
is my home directory for?
On March 12, 2014 10:10:20 PM CDT, Daniel
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
On Wed, 12 Mar 2014, Faré wrote:
Major changes like that happen less than once a year (ASDF 2 in 2010,
ASDF 3 in 2013, ASDF 3.1 soon in 2014), and while
backward-compatibility has always been a huge priority, improvements
sometimes do mean the recommended way of using ASDF changes, for the
bette
On Wed, 12 Mar 2014, Robert P. Goldman wrote:
~/asdf-local-paths/
would work for me.
Squawks sooner rather than later, please.
If we are decided on adding a default path, please make it consistent with
the other XDG stuff in ASDF...
I'm not XDG guru, but here's a link to the standard...
On Wed, 12 Mar 2014, Dave Cooper wrote:
Ok good. Then how about having ASDF loudly announce that it is registering the
default directory (e.g. ~/cl/), as well as providing the hint about using a
.conf file with the right syntax with :tree, if the user wants to exclude
certain subdirectories.
On Wed, 12 Mar 2014, Faré wrote:
1- I think we should proceed and add a default path anyway.
~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one
complain about that.
You could make it ~/local/common-lisp/ if you're into larger paths.
The computer I'm currently on uses ~/lisp f
On Wed, Mar 12, 2014 at 7:24 PM, Zach Beane wrote:
> Faré writes:
>
>> On Wed, Mar 12, 2014 at 6:07 PM, Pascal Costanza wrote:
>>> Can I set CL_SOURCE_REGISTRY to a value that deactivates all "default"
>>> paths? Then I don't care what the default is...
>>>
>> Yes, the example I gave you did th
Faré writes:
> On Wed, Mar 12, 2014 at 6:07 PM, Pascal Costanza wrote:
>> Can I set CL_SOURCE_REGISTRY to a value that deactivates all "default"
>> paths? Then I don't care what the default is...
>>
> Yes, the example I gave you did that:
>
> export CL_SOURCE_REGISTRY=~/lisp//
>
> As you can se
Sent from my iPad
> On 12 Mar 2014, at 23:39, Faré wrote:
>
>> On Wed, Mar 12, 2014 at 6:07 PM, Pascal Costanza wrote:
>> Can I set CL_SOURCE_REGISTRY to a value that deactivates all "default"
>> paths? Then I don't care what the default is...
> Yes, the example I gave you did that:
>
> expor
On Wed, Mar 12, 2014 at 6:07 PM, Pascal Costanza wrote:
> Can I set CL_SOURCE_REGISTRY to a value that deactivates all "default" paths?
> Then I don't care what the default is...
>
Yes, the example I gave you did that:
export CL_SOURCE_REGISTRY=~/lisp//
As you can see with (asdf::parse-source-r
Can I set CL_SOURCE_REGISTRY to a value that deactivates all "default" paths?
Then I don't care what the default is...
Pascal
Sent from my iPad
On 12 Mar 2014, at 22:14, Faré wrote:
: Faré
>>> : p-cos
>> : rpgoldman
>
>>> asdf is not a tool for beginners. Beginners will either deal with
>>>: Faré
>>: p-cos
>: rpgoldman
>> asdf is not a tool for beginners. Beginners will either deal with a bare
>> Common Lisp implementation, or they want to experiment with third-party
>> libraries, in which case they want to use quicklisp these days. Once you
>> need to define your own systems,
On Wed, Mar 12, 2014 at 3:08 PM, Zach Beane wrote:
> Faré writes:
>
>> On Wed, Mar 12, 2014 at 2:25 PM, Zach Beane wrote:
>>> Dave Cooper writes:
>>>
On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane wrote:
I don't think I want to read loud announcements from ASDF. If it isn't
> a
Pascal Costanza wrote:
>
~/common-lisp/ is slightly more pretentious, but probably works, too.
>> That would be my preference.
>>
~/cl/ is taking a lot of familiarity, and maybe I should keep it my
personal configuration rather than a recommended default.
>>> These last two have bee
>>> ~/common-lisp/ is slightly more pretentious, but probably works, too.
> That would be my preference.
>
>>> ~/cl/ is taking a lot of familiarity, and maybe I should keep it my
>>> personal configuration rather than a recommended default.
>>
>> These last two have been rejected by Pascal and
Yuck...
Sent from my iPad
> On 12 Mar 2014, at 18:41, Dave Cooper wrote:
>
>
> On Wed, Mar 12, 2014 at 1:04 PM, Faré wrote:
>
>
>> 1- I think we should proceed and add a default path anyway.
>> ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one
>> complain about that.
>>
asdf is not a tool for beginners. Beginners will either deal with a bare Common
Lisp implementation, or they want to experiment with third-party libraries, in
which case they want to use quicklisp these days. Once you need to define your
own systems, you're not a beginner anymore, and a good tut
On Wed, Mar 12, 2014 at 3:17 PM, Robert P. Goldman wrote:
> Faré wrote:
>> ~/local/common-lisp/ has the advantage of being clutter-limiting,
>> XDG-like if not strictly XDG, clean, etc., and just one character
>> longer than your proposal.
>
> I am less excited about the future and find it more ap
Faré wrote:
> 1- I think we should proceed and add a default path anyway.
> ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one
> complain about that.
> You could make it ~/local/common-lisp/ if you're into larger paths.
>> >
>> > I think I will put
Faré writes:
> On Wed, Mar 12, 2014 at 2:25 PM, Zach Beane wrote:
>> Dave Cooper writes:
>>
>>> On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane wrote:
>>>
>>> I don't think I want to read loud announcements from ASDF. If it isn't
acting like I want, I'd rather read about how to make it do wha
1- I think we should proceed and add a default path anyway.
~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one
complain about that.
You could make it ~/local/common-lisp/ if you're into larger paths.
>
> I think I will put "asdf" into the pathname, per our ea
On Wed, Mar 12, 2014 at 2:25 PM, Zach Beane wrote:
> Dave Cooper writes:
>
>> On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane wrote:
>>
>> I don't think I want to read loud announcements from ASDF. If it isn't
>>> acting like I want, I'd rather read about how to make it do what I want
>>> in a tutor
otti<mailto:marc...@cs.nyu.edu>
Cc: ASDF-devel<mailto:asdf-devel@common-lisp.net>
Subject: Re: [asdf-devel] Alternate default lisp system location
Marco Antoniotti writes:
> On Mar 12, 2014, at 15:32 , Zach Beane wrote:
>
>> Robert Goldman writes:
>>
>>> Zach Beane w
Faré wrote:
> On Wed, Mar 12, 2014 at 1:41 PM, Dave Cooper
> wrote:
>> On Wed, Mar 12, 2014 at 1:04 PM, Faré wrote:
>>
>>
>>> 1- I think we should proceed and add a default path anyway.
>>> ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one
>>> complain about that.
>>> You co
Zach Beane wrote:
> Dave Cooper writes:
>
>> On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane wrote:
>>
>> I don't think I want to read loud announcements from ASDF. If it isn't
>>> acting like I want, I'd rather read about how to make it do what I want
>>> in a tutorial or manual.
>>
>>
>> Loud anno
Dave Cooper wrote:
> The goal here is to make the addition of the default registry directory
> as painless and surprise-free as possible for anyone who already happens
> to have stuff floating around in the new default directory.
No, that would be the *subsidiary* goal.
The *primary* goal will b
Dave Cooper writes:
> On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane wrote:
>
> I don't think I want to read loud announcements from ASDF. If it isn't
>> acting like I want, I'd rather read about how to make it do what I want
>> in a tutorial or manual.
>
>
>
> Loud announcement only in the initial
On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane wrote:
I don't think I want to read loud announcements from ASDF. If it isn't
> acting like I want, I'd rather read about how to make it do what I want
> in a tutorial or manual.
Loud announcement only in the initial ASDF release when the new default
Dave Cooper writes:
>> The source-registry :tree thing already provides for recursive exclusions.
>
>
>
> Ok good. Then how about having ASDF loudly announce that it is registering
> the default directory (e.g. ~/cl/), as well as providing the hint about
> using a .conf file with the right syntax
> The source-registry :tree thing already provides for recursive exclusions.
Ok good. Then how about having ASDF loudly announce that it is registering
the default directory (e.g. ~/cl/), as well as providing the hint about
using a .conf file with the right syntax with :tree, if the user wants t
On Wed, Mar 12, 2014 at 1:41 PM, Dave Cooper wrote:
>
> On Wed, Mar 12, 2014 at 1:04 PM, Faré wrote:
>
>
>>
>> 1- I think we should proceed and add a default path anyway.
>> ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one
>> complain about that.
>> You could make it ~/local
On Wed, Mar 12, 2014 at 1:04 PM, Faré wrote:
> 1- I think we should proceed and add a default path anyway.
> ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one
> complain about that.
> You could make it ~/local/common-lisp/ if you're into larger paths.
>
How about providin
Yay for the bikeshedding.
1- I think we should proceed and add a default path anyway.
~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one
complain about that.
You could make it ~/local/common-lisp/ if you're into larger paths.
2- Yes, we can add a programmatic way to manually r
Zach Beane wrote:
> Marco Antoniotti writes:
>
>> On Mar 12, 2014, at 15:32 , Zach Beane wrote:
>>
>>> Robert Goldman writes:
>>>
Zach Beane wrote:
> The complexity of the registry configuration is one reason why I added
> the ~/quicklisp/local-projects/ mechanism.
Right, so I
Marco Antoniotti writes:
> On Mar 12, 2014, at 15:32 , Zach Beane wrote:
>
>> Robert Goldman writes:
>>
>>> Zach Beane wrote:
The complexity of the registry configuration is one reason why I added
the ~/quicklisp/local-projects/ mechanism.
>>>
>>> Right, so I don't see why there's s
Stelian Ionescu wrote:
>> > I think you will find that the configuration of the source search path
>> > is *very* complex, indeed too complex for a beginner.
>
> If it's complex, simplify it. You'd piling more stuff on top of the
> current behaviour.
>
>
No, that is not the case.
I would be *s
On Wed, 2014-03-12 at 10:04 -0500, Robert P. Goldman wrote:
> Stelian Ionescu wrote:
> > It's very easy not to have a default directory at all.
>
> I'm sorry, I don't agree that this claim is correct.
You don't agree that it's always easier not to do anything ? Really ?
> I have just pushed my
> I think you will find that the configuration of the source search path
> is *very* complex, indeed too complex for a beginner. It's great for
> hackers with complex requirements, but there's too much to be read if
> you just want to make one or two simple systems.
FTR, even i was mildly irritat
On Mar 12, 2014, at 15:32 , Zach Beane wrote:
> Robert Goldman writes:
>
>> Zach Beane wrote:
>>> The complexity of the registry configuration is one reason why I added
>>> the ~/quicklisp/local-projects/ mechanism.
>>
>> Right, so I don't see why there's such a huge objection to having a
>>
Stelian Ionescu wrote:
> It's very easy not to have a default directory at all.
I'm sorry, I don't agree that this claim is correct. I have just pushed
my current draft of the ASDF manual, and I urge you to read it.
I think you will find that the configuration of the source search path
is *very*
On Wed, 2014-03-12 at 09:20 -0500, Robert P. Goldman wrote:
> Stelian Ionescu wrote:
> > 1) install Quicklisp, it's easy and painless
> > 2) put your projects in $QUICKLISPDIR/local-projects/
> >
> > done.
>
> I get you, but I don't like it.
>
> That's like saying "I want to make my first C prog
On Wed, 2014-03-12 at 09:23 -0500, Robert Goldman wrote:
> Zach Beane wrote:
> > The complexity of the registry configuration is one reason why I added
> > the ~/quicklisp/local-projects/ mechanism.
>
> Right, so I don't see why there's such a huge objection to having a
> similar mechanism for ASD
Robert Goldman writes:
> Zach Beane wrote:
>> The complexity of the registry configuration is one reason why I added
>> the ~/quicklisp/local-projects/ mechanism.
>
> Right, so I don't see why there's such a huge objection to having a
> similar mechanism for ASDF. Stellian suggests using
> ~/qui
Zach Beane wrote:
> The complexity of the registry configuration is one reason why I added
> the ~/quicklisp/local-projects/ mechanism.
Right, so I don't see why there's such a huge objection to having a
similar mechanism for ASDF. Stellian suggests using
~/quicklisp/local-projects/. So why is i
Attila Lendvai wrote:
>> to expose so a :tree recursion there would be very annoying. And please
>> don't tell me to :ignore-inherited-configuration, for what's the point
>> of the default configuration if so many people either don't use it or
>> have to explicitly ignore it ?
>
> well, for now it
Stelian Ionescu wrote:
> 1) install Quicklisp, it's easy and painless
> 2) put your projects in $QUICKLISPDIR/local-projects/
>
> done.
I get you, but I don't like it.
That's like saying "I want to make my first C program." "OK, let me
teach you how to use apt-get."
Maybe this is the right answ
On Wed, 2014-03-12 at 08:51 -0500, Robert P. Goldman wrote:
> Stelian Ionescu wrote:
> > On Thu, 2014-02-27 at 22:30 -0600, Robert P. Goldman wrote:
> >> How would you all feel about an alternate default location for lisp
> >> systems, in addition to
> >>
> >> ~/.local/share/common-lisp/source/
> >
> to expose so a :tree recursion there would be very annoying. And please
> don't tell me to :ignore-inherited-configuration, for what's the point
> of the default configuration if so many people either don't use it or
> have to explicitly ignore it ?
well, for now it's two hard-core hackers, for
"Robert P. Goldman" writes:
> Stelian Ionescu wrote:
>> On Thu, 2014-02-27 at 22:30 -0600, Robert P. Goldman wrote:
>>> How would you all feel about an alternate default location for lisp
>>> systems, in addition to
>>>
>>> ~/.local/share/common-lisp/source/
>>>
>>> I'm sure that .local was chose
Stelian Ionescu wrote:
> On Thu, 2014-02-27 at 22:30 -0600, Robert P. Goldman wrote:
>> How would you all feel about an alternate default location for lisp
>> systems, in addition to
>>
>> ~/.local/share/common-lisp/source/
>>
>> I'm sure that .local was chosen out of the (in)finite wisdom of XDG,
On Thu, 2014-02-27 at 22:30 -0600, Robert P. Goldman wrote:
> How would you all feel about an alternate default location for lisp
> systems, in addition to
>
> ~/.local/share/common-lisp/source/
>
> I'm sure that .local was chosen out of the (in)finite wisdom of XDG, but
> it just seems odd to me
Pascal Costanza wrote:
> This has the potential of messing up already existing configurations
> (again!). The choice of ~/lisp would certainly mess up mine, and I can
> imagine many other scenarios. Please don't do that.
[By "this" we mean "by default searching ~/common-lisp/ and/or ~/cl/ for
so
Pascal Costanza wrote:
> I'm expecting asdf to suddenly see asd files that it shouldn't. (In my
> configuration, only ~/lisp/develop/ contains "active" systems, the rest of
> ~/lisp may contain "inactive" ones - for example, alternate versions of the
> same systems.)
Can you clarify?
Do you te
On Wed, Mar 12, 2014 at 3:16 AM, Pascal Costanza wrote:
> I'm expecting asdf to suddenly see asd files that it shouldn't. (In my
> configuration, only ~/lisp/develop/ contains "active" systems, the rest of
> ~/lisp may contain "inactive" ones - for example, alternate versions of the
> same syst
I'm expecting asdf to suddenly see asd files that it shouldn't. (In my
configuration, only ~/lisp/develop/ contains "active" systems, the rest of
~/lisp may contain "inactive" ones - for example, alternate versions of the
same systems.)
Pascal
Sent from my iPad
> On 12 Mar 2014, at 08:04, Far
On Wed, Mar 12, 2014 at 2:49 AM, Pascal Costanza wrote:
> This has the potential of messing up already existing configurations
> (again!). The choice of ~/lisp would certainly mess up mine, and I can
> imagine many other scenarios. Please don't do that.
>
I'm not sure what you mean by "messing u
This has the potential of messing up already existing configurations (again!).
The choice of ~/lisp would certainly mess up mine, and I can imagine many other
scenarios. Please don't do that.
Thanks,
Pascal
Sent from my iPad
> On 12 Mar 2014, at 04:44, "Robert P. Goldman" wrote:
>
> Faré wro
Faré wrote:
>> On Thu, Feb 27, 2014 at 11:30 PM, Robert P. Goldman
>> wrote:
>>> >> How would you all feel about an alternate default location for lisp
>>> >> systems, in addition to
>>> >>
>>> >> ~/.local/share/common-lisp/source/
>>> >>
> NB: I think a new additional location under ~/ for CL co
On Fri, Feb 28, 2014 at 3:28 AM, Faré wrote:
> On Thu, Feb 27, 2014 at 11:30 PM, Robert P. Goldman
> wrote:
>> How would you all feel about an alternate default location for lisp
>> systems, in addition to
>>
>> ~/.local/share/common-lisp/source/
>>
NB: I think a new additional location under ~/
On Thu, Feb 27, 2014 at 11:30 PM, Robert P. Goldman wrote:
> How would you all feel about an alternate default location for lisp
> systems, in addition to
>
> ~/.local/share/common-lisp/source/
>
I hesitated about it, but ended not promoting something.
I personally use ~/cl/ but I fear it's too sh
How would you all feel about an alternate default location for lisp
systems, in addition to
~/.local/share/common-lisp/source/
I'm sure that .local was chosen out of the (in)finite wisdom of XDG, but
it just seems odd to me to hide the lisp systems from the user, which we
are doing by putting the
83 matches
Mail list logo
