I've started to redo my patches to nmh, and have some questions on
how people would like them implemented. This mail will ask some
questions about the patch for per folder component/filter/etc files.
1 - In my current patch I added searchpath after etcpath in config/config.c,
so that I could theoretically use the original for certain files. Can
anyone think of any cases where this would be needed/useful? Should I
call the routine searchpath to make the new function clearer, or etcpath?
2 - In earlier discussion, Dan indicated that he would like a flag to turn
this feature on. I'd like to get agreement on details. Where do we look
for component files:
a - If fixed path (Starting with '/', '~', './' or '../'), only one choice.
b - Current, or selected folder
c - Recursive search upwards from current folder, up to:
d - User nmh directory
e - /etc/nmh (or whatever is the value of nmhetcdir)
Of these, b and c are new. We can turn either or both on/off with
commandline flags. Do we want them on in the default case?
- Advantage of turning them off in the default case is better backwards
compatibility.
- Advantage of turning them on in the default case is that this feature
is intended to give you better control of the default case. The whole
intention is to allow more control without having to use flags.
- I can not imagine any real compatibility problems from b. I can
imagine compatibility problems from c for those people using an old
version of exmh that did b and not c. (That was fixed, wasn't it?)
I haven't heard any complaints in the exmh camp after going from
b to b+c.
- I'm not sure we should even allow this to be turned off. I can not
imagine it getting much use and you should always leave out useless
bits, because it is very hard to take them away later.
- If we add flags, what should they be called? -search/recurs/recurse/
fsd (folder specific defaults:)
- Compile time option?
- I'm not sure what the impact of public folders would be. I have
never used them, any ideas? Did anyone consider this when this was
implemented in exmh? (Yes I know, wrong list).
3 - In my current version, for comp I change what happens when you use a
+folder argument and no msg argument. Traditionally this means you use
the current msg from that folder as a draft, in my version this just
takes the component files from that folder.
I can imagine this would break some things people are currently doing.
I'll try to explain my rationale, and then ask for a better solution.
The searchpath function needs to know what folder to operate on.
Without the option to indicate this on the commandline, the current
folder mechanism is the only available mechanism. It's not always
clear to the user (perhaps using multiple windows) what his current
folder is. Using 'comp +folder' is the natural response, but would
do something different. This may of course not be the same for
experienced users.
Some solutions?
- Use a different flag (-compfolder? yuk)
- Combine with a flag from nr 2 above, turning this feature on or off
Perhaps a bit of a long story, but I really want this feature in, and
want to make sure everybody is happy with it.
Regards,
Tobias