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
