Hi Nick, nmh 1.4 is out. I hope you have some time soon to package it up.
Could you please comment on Ken's questions about the following configuration items? Since I like the way you configure nmh on Debian, I'd like to ensure that his suggestions are consistent with the way you configure nmh. Thanks! Ken Hornstein <k...@pobox.com> writes: > Alright, in preparation for finally cleaning up our suboptimal autoconf > mess, I am tackling acconfig.h (a template which users can edit to > change defaults). My feeling is all of that should either be controlled > by autoconf or we take a decision on whether or not to keep or remove > that code. Here is the list: > > LOCKDIR - A directory to place lock files in if you're using > DOT_LOCKING. I've never been happy with nmh's use of > dot locking, but do people actually use this? It's > easy enough to add the support for this to autoconf. > > DBMPWD - The comment says "Define this if your passwords are > stored in some type of distributed name service, such as > NIS, or NIS+." This only affects aliasbr.c ... and I > guess what it does is controls whether or not names > are cached from calls to getpwnam(). This has been > turned on forever, I propose just removing the #ifdefs > and making that code the default. > > DUMB - Strangely, turning ON DUMB means you get an RFC 822 > parser. If DUMB is NOT defined, you get MMDF and UUCP > parsing as well. I'm going to go out on a limb here and say > we can safely remove MMDF & UUCP address parsing :-) > Oh, on that note there's some code #ifdef'd as BANG > which uses UUCP mailing syntax. I'm just going to go > ahead and remove that because I am 100% sure no one > needs it. > > REALLYDUMB - What this does is prevent adrsprintf() from appending a > local hostname if a username doesn't have one. You know, > I really think this should be a run-time option instead. > Anyone care if I make it so it is? (The default can > be off to match current behavior). > > FIX_NON_Y2K_COMPLIANT_MUA_DATES > - Meh, at this point I'd say garbage collect this code, > but I have no strong feelings. Either we should keep it > and remove the #ifdefs, or get rid of it entirely. > Thoughts? > > RPATHS - Construct Return-Path headers from "From " lines. > I say keep it, since it's been around forever (a fair > amount of code, actually). > > SLOCAL_MBOX - If defined, use mbox format with slocal when saving to > your mail spool, otherwise, use MMDF. I say keep it > and ditch MMDF support. > > MHRC - Handle the ~ for filenames; this is a keeper, right? > > BUILTIN_FTP - This was the only code I didn't add IPv6 code to. It's > turned on right now, but I have to question how useful it > is (it's built-in ftp support for mhn). I haven't seen > MIME messages with external-body parts in forever, and > even if we did get any I think this work should be forked > off to an external ftp program or something like curl. > Thoughts? Actually, I wonder how many MUAs support > MIME external-body anyway (okay, a quick Google shows > that it's non-zero, but I suspect that a lot of it is > done via http rather than ftp anyway). > > POPSERVICE - Easy enough to autoconf it, but it's command-line selectable > anyway. Maybe simply hardcode the default? > > DEFAULT_FOLDER_MODE - Leave these two as hardcoded defaults? > DEFAULT_MESSAGE_MODE > > LINK - The same? > > ATTVIBUG - Is this an issue anymore? > > --Ken > > _______________________________________________ > Nmh-workers mailing list > Nmh-workers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/nmh-workers > -- Bill Wohler <woh...@newt.com> aka <bill.woh...@nasa.gov> http://www.newt.com/wohler/ GnuPG ID:610BD9AD _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers