scott(_dot_)blachowicz(_at_)seaslug(_dot_)org said:
Wouldn't it be more consistent with other filename specs to have a
relative path be relative to your nmhdir and a path starting with a "/
" be an absolute filename?
Yes, and no. The confpath was intended to mirror the generic 'Path'
that is in the mh-profile. I think I prefer confdir, with the option
of using absolute paths. The disadvantage to doing it as a subdir
of your nmhdir is that some external programs will assume any subdir
is a folder. (exmh, ...?)
I just had a thought...what if you WANT a components file override on
a shared folder and you want that override for all users of the
folder?
Symlink. So:
.comps/
work/
private/
shared -> /.../nmh/.comps/shared
work/
proj1/
proj2/
private/
shared -> /.../nmh/shared
This is a big advantage of this option. This structure allows a secure
way of dealing with shared folders with shared comps, my old structure
does not.
How are things handled if you scan a directory that's not under your
nmhdir? For example:
scan +/home/scott/archives/y2002
scan +/home/scott/nnml/mail/misc
...whatever...
Maybe there needs to be a way to specify a folder-relative "confdir"?
We could do a number of things:
- nothing, these are not default folders, so they have no folder defaults.
- Replace the dir-tree containing comps files with a per-folder subdir
that contains all defaults. So:
work/
.comps
proj1/
proj2/
.comps
private/
.comps/
The recursive option should only work for folders, not for fixed paths.
- Make a separate subdirtree that mirrors the entire filesystem.
.comps/
root/
home/scott/archives/y2002/
nmhdir/
work/
work/
- Add a -compdir option that says where to get the defaults from?
Can't think of any really clean solution, except for the 'do nothing' one.
Tob