bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: --lock-flags now configurable, and some mu_argp reorg


From: Sergey Poznyakoff
Subject: Re: --lock-flags now configurable, and some mu_argp reorg
Date: Thu, 11 Apr 2002 13:39:15 +0300

> - I couldn't get control over the f**ing order argp was printing
>   options for --help. I wanted:
[...]
> There was some code to auto-number things, but it didn't work, and
> I couldn't figure out why, so I hard coded groups, and now it works.
> 
> If theres a nicer way to get a nice order, I'd love to hear.

Yes, there is. Committed to repository. Group numbering follows
the order in which the corresponding capabilities were listed.

By the way, shouldn't sieve understand --license option as other
utilities do?

>   I can add back the .mu. prefix for config files if thats not
>   sufficient, but I really like the directory of config files, an
>   idea I shamelessly stole from mutt.

I've commented it in my previous posting. I think it's time we came to
an agreement about the file-naming scheme:

1. The directory for config files is quite OK. I like the idea, too.
2. Naming utility-specific configs in "~/.<utility>rc" fashion would
   be quite OK, but it breaks mail functionality.

To restore broken mail functionality, there are three possible ways:

1. Rename its mailutils-specific config file to something else.

   Drawback: This will produce an inconsitency in the naming scheme.
   Besides, corresponging code in mu_argp.c will look quite kludgy.

2. Do not use mailutils-specific config for this utility at all.

   Seems quite OK, since it has its own traditional configuration
   file. 
   Drawback: Inconsistency again. Besides, neither --mail-spool
   nor --lock-flags are covered by the traditional ~/.mailrc

3. Use another naming scheme for config files.

(Of course, I do not consider dropping the traditional ~/.mailrc
functionality, it will be worse than anything)

Personally, I'd vote for number 3. The format of our configs is
mailutils-specific so keeping their names mailutils-specific seems
quite logical. Again, there may be someone who has good reasons for
using both mailutils and some other mail software, and it'd be
a good thing if the configuration files won't collide.

Opinions?
 
Regards,
Sergey




reply via email to

[Prev in Thread] Current Thread [Next in Thread]