Honorable Senator,
I hopefully fixed your issue in 1.723, and another issue in 1.724.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Procrastination is great. It gives me a lot more time to do things that I'm never going to do.
On 14 May 2010 05:06, szergling senatorzergling@gmail.com wrote:
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:
- 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)
- 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.
- 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>>