![](https://secure.gravatar.com/avatar/28698375e19f799696f925da9bfdfd59.jpg?s=120&d=mm&r=g)
On 5/12/10, Faré <fahree@gmail.com> wrote:
Yes, I agree the exclude API is not very clean, sorry about that. If you have a better design to propose, I'm all ears.
<<snip>> I would if I could. :) While my original thoughts on this appear simple at first, on further examination, I have become confused with a couple of issues. Some suggestions and questions: 1. I think most hackers would expect that *default-exclusions* should not be overridden if the user provides an :exclude directive. (setf *default-exclusions* rest) should be something like (appendf *default-exclusions* rest) 2. What does it mean to inherit a configuration? Will exclusions be shared? For example, suppose directory "/a/b/x/" is meant to be excluded, and is specified in the user config file (which :inherit-configuration). If the system config (being inherited, if I understand correctly) specifies the tree "/a/b/", x/ (being a subdirectory) will get re-included again. 3. At the risk of confusing the meaning of "inherit" with CLOS inheritance, I was going to propose solving the "order of directive specification" issue by pre-reading all config info into a first class configuration object. This may facilitate inspecting/reasoning over them as well as supporting more direct interactions between directives. Thanks all I can think of for now... Yong.
On 11 May 2010 04:37, szergling <senatorzergling@gmail.com> wrote:
Hi list,
Is it intended that :exclude in
~/.config/common-lisp/source-registry.conf
should come before the :tree directive(s)[1]?
To me, the manual seems to specify that the order in which the directives are provided does not matter.
<<snip>>