Re: mutt and mh/procmail
On 2000-03-01 19:08:10 -0600, Conrad Sabatier wrote: > By the way, is there a simple way to convert my existing folders > to this format? Just set mbox_type=maildir in mutt, go into an old folder, tag all messages, and apply-save them to a new folder. With the "-e" option, you can even do this from the command line. -- http://www.guug.de/~roessler/
Re: Reading HTML Attachments
On 2000-03-01 18:58:08 -0800, -kevin- wrote:
> Change to:
> text/html; netscape -remote 'openFile(%s)';copiousoutput
Bad idea. You'd rather want this:
text/html; netscape -remote 'openFile('%s')'; copiousoutput
Note that the %s itself MUST NOT be enclosed by any form of quoting,
because otherwise strange file names would lead to really strange
effects, and essentially would break out of the quoting.
--
http://www.guug.de/~roessler/
Re: Reading HTML Attachments
John P. Verel <[EMAIL PROTECTED]> wrote on Wed, 01 Mar 2000: > Now, next project is to be able to > "click" on imbeded hyperlinks. The mutt manual (4.12) refers to an > external urlview program. I'm unclear what the manual means in > referring to macro indexetc. Have you done this? The urlview programs takes any text file and looks for URLs in it. (Actually what it looks for can be configured, so you could make it do any kind of things, but the default use is to look for URLs...) The way this works is to set up urlview, and then create a macro in Mutt that will send the contents of the current message to the urlview program. Then in urlview you see all the links and can select any one of them. Urlview is really rather simple, and I remember having no trouble at all setting it up with the documentation that was provided, down to adding the relevant macro (ctrl-b) into my .muttrc. This isn't true "click on the links as I see them" type of feature. That's not really possible with Mutt. However it's possible with xterms, I think there was a program called "dingus" that enabled this. (I'm not sure, dingus may have been adapted into gnome-terminal, I remember once reading something like that... But could mis-remember too.) Regards, Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy & scifi, the Corrs / The *REAL* Y2K is the year 2048.
Re: mutt and mh/procmail
Bennett Todd <[EMAIL PROTECTED]> wrote on Wed, 01 Mar 2000: > So if you open an MH folder, tag all the messages with > > T~A > > then save them all to a new folder with > > ;snew-folder > > (that's a semicolon, it is the "tag prefix") that will convert the > folder. However, since it's pretty darned interactive, it's not > appealing for batch conversion of lots of old folders. For that you > want something command-line. Actually, it's not impossible to use Mutt from the command line for that. I'm not sure whether it's any *easier* than doing something else (a specific script), but it's certainly possible to use the -e command line switch to "push" all the necessary keystrokes into Mutt, eg. mutt -f =folder-to-convert -e 'push T~A\n;snew-folder\nq' The final q for quit may give you a prompt, which can be eliminated by setting the right variable (I forget which right now). The above also assumes you have your $mbox_type variable set to the desired folder format in your .muttrc. And so, to convert a bunch of folders, you only need a shell script wrapper around the above, calling Mutt each time with the right old and new folder names. Again, I'm not sure if this is any easier than using some real command line tools, but I'm sure it can be made to work. :-) Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy & scifi, the Corrs / Signature under construction, beware of falling letters!
Re: Reading HTML Attachments
Kevin, Thanks. Worked like a charm! Now, next project is to be able to "click" on imbeded hyperlinks. The mutt manual (4.12) refers to an external urlview program. I'm unclear what the manual means in referring to macro indexetc. Have you done this? On Wed, Mar 01, 2000 at 06:58:08PM -0800, -kevin- wrote: > John, > > On 00-03-01 20:46, John P. Verel wrote: > > My mailcap entry looks like this: > > > > text/html; netscape -remote openURL\(%s\) > > Change to: > > text/html; netscape -remote 'openFile(%s)';copiousoutput > > -- > -* -kevin-*- > -* sick with the good infection *- > -* [EMAIL PROTECTED] *- > -* http://www.pobox.com/~kathey *-
Re: mutt and mh/procmail
2000-03-01-22:09:44 Doug Wellington:
> Bennett provided a lot of good code to move files around, but I wonder
> if it wouldn't just be easier to use nmh's "packf" command to batch
> convert each of your MH style directories into single mbox style files
> and then deal with them that way...
If packf converts the MH into mbox, then you could use an
mbox2maildir script to finish the job. I attach the one I use.
Or you could probably hackup something cool around procmail's
formail program, which does really brainy splitting of mbox folders,
knows about Content-Length and all that creepy stuff.
-Bennett
#!/usr/bin/perl -w
use strict;
use File::Basename;
use Sys::Hostname;
use IO::File;
$0 = basename $0;
my($syntax) = "syntax: $0 mbox maildir\n";
die $syntax if $#ARGV != 1;
my($mbox, $maildir) = @ARGV;
die "$0: $mbox is not a file\n" unless -f $mbox;
die "$0: can't read $mbox\n" unless -r $mbox;
die "$0: can't open $mbox\n" unless my($fi) = IO::File->new("<$mbox");
-d $maildir or mkdir $maildir,0777 or die "$0: can't create $maildir: $!\n";
die "$0: cannot chdir $maildir\n" unless chdir $maildir;
for (qw(tmp new cur)) {
-d $_ or mkdir $_,0700 or die "$0: can't create $maildir/$_: $!\n";
}
my($time) = time;
my($pid) = 10;
my($hostname) = hostname;
my($msg,$fo);
line: while ($_ = $fi->getline) {
if (/^From /) {
if (defined $msg and defined $fo) {
$fo->close or die;
if (-s "tmp/$msg") {
rename "tmp/$msg", "new/$msg" or die;
} else {
unlink "tmp/$msg" or die;
}
}
$msg = join '.', $time, $pid++, $hostname;
die if -f "tmp/$msg";
$fo = IO::File->new(">tmp/$msg") or
die "$0: can't open $maildir/tmp/$msg: $!\n";
next line;
}
$fo->print($_);
}
if (defined $msg and defined $fo) {
$fo->close or die;
if (-s "tmp/$msg") {
rename "tmp/$msg", "new/$msg" or die;
} else {
unlink "tmp/$msg" or die;
}
}
PGP signature
Re: Reading HTML Attachments
John, On 00-03-01 20:46, John P. Verel wrote: > My mailcap entry looks like this: > > text/html; netscape -remote openURL\(%s\) Change to: text/html; netscape -remote 'openFile(%s)';copiousoutput -- -* -kevin-*- -* sick with the good infection *- -* [EMAIL PROTECTED] *- -* http://www.pobox.com/~kathey *-
Re: mutt and mh/procmail
Previously: >> By the way, is there a simple way to convert my existing folders >> to this format? Bennett provided a lot of good code to move files around, but I wonder if it wouldn't just be easier to use nmh's "packf" command to batch convert each of your MH style directories into single mbox style files and then deal with them that way... -Doug -- Doug Wellington [EMAIL PROTECTED] System and Network Administrator ARL, Division of Neural Systems, Memory and Aging The University of Arizona, Tucson, AZ, USA
print_command (a2ps)
I like using a2ps to do my printing, but I would like to have it use the date/author/subject for some of the footers and headers. Has someone already done this? If so, can you show me your 'print_command' setting? TIA -- -* -kevin-*- -* sick with the good infection *- -* [EMAIL PROTECTED] *- -* http://www.pobox.com/~kathey *-
Reading HTML Attachments
Hi. I've got mutt loaded with the default mime types and mailcap file
that came with the distro and am running under RH 6.1 When I attempt
to view attached HTML, I get the following message:
sh: syntax error near unexpected token `openURL(''
sh: -c: line 1: `netscape -remote openURL('/tmp/AP-Albrights-Future.html')'
My mailcap entry looks like this:
text/html; netscape -remote openURL\(%s\)
Please advise what I'm doing wrong! Thanks.
John
Re: home/end/pageup/pagedown don´t work
On Tue, Feb 22, 2000 at 12:43:50AM +0200, Mikko Hänninen wrote: > I've used cat > /dev/null followed by pressing the key, and seeing > which characters get printed. This may or may not work for you... [...] At least under tcsh (haven't tried it under any other shell), it's as easy to simply type Ctrl-v, then the key you'd like to get the code of. Works like in Vim. Also, when editing the muttrc file to add those "weird" codes, be aware of the fact that often there is an "Escape" in there. Example: In my rxvt under Linux, will produce "^[[8~". Now, the first ^[ is *not* the two characters ^ and [ but a single "Escape" character. You can get it e.g. by editing muttrc with vim and pressing Ctrl-v, then Esc. HTH, Thomas -- - Thomas Ribbrockhttp://www.bigfoot.com/~kaytanICQ#: 15839919 "You have to live on the edge of reality - to make your dreams come true!"
Re: mutt and mh/procmail
2000-03-01-20:08:10 Conrad Sabatier: > I'm going to have to look into this "maildir" format, I think. :-) > > By the way, is there a simple way to convert my existing folders > to this format? Within mutt, if you go :set mbox_type="Maildir" (or put that in your .muttrc), mutt will create new folders in Maildir format by default. So if you open an MH folder, tag all the messages with T~A then save them all to a new folder with ;snew-folder (that's a semicolon, it is the "tag prefix") that will convert the folder. However, since it's pretty darned interactive, it's not appealing for batch conversion of lots of old folders. For that you want something command-line. I don't know what the files in MH format look like, but if their contents look like RFC 822 messages (ideally without the leading "From " line, although mutt doesn't care too much for most purposes) you can just use "mv" to put them into foldername/new/. So if you have a whole bunch of MH folders in ~/Mail/, then perhaps cd ~/Mail for d in *;do mkdir $d/new mv $d/* $d/new # ignore the error mkdir $d/tmp $d/cur done The error to ignore will be something like mv: cannot move `foo/new' to a subdirectory of itself, `foo/new/new' If the files aren't exactly in RFC-822 message format, it might be worth trying to fix them. And if the filenames are particularly unlikely to be unique, it might be worth taking the trouble to rename them. Perhaps cd ~/Mail for d in *;do ( cd $d files=`ls` mkdir tmp new cur n=1 for f in $files;do mv $f cur/`date +%s`.$$_$n.`hostname`:2,S n=`expr $n + 1` done ) done (untested). That version puts them in folders marked as already read, rather than into new. Files in cur/ should have suitable flags. As I said, if the files don't exactly contain RFC 822 messages, it's worth making them so. E.g. if they start with mbox-style "From " lines, you could delete the from lines with perl -pi -e 'print unless 1..1' * Or you could turn the "From " line into a header line, if e.g. you wanted to save the delivery info (some MTAs put envelope sender in the "From " line), with something like perl -pi -e 's/^From /X-From: / if 1..1' * (as I mentioned before, untested). -Bennett PGP signature
Re: mutt and mh/procmail
On 01-Mar-00 Thomas Roessler wrote: > On 2000-03-01 07:15:28 -0600, Conrad Sabatier wrote: > >> Yes, I've noticed that mutt behaves in a rather unreliable >> fashion when it comes to this, too. > > The mh code is far from perfect. It should be fine for converting > legacy mh-style folders to something else, but I wouldn't use it in > production for incoming folders. If there aren't any grave reasons > why you have to stick with mh folders, I'd suggest you switch to > maildir. Well, I went with MH folders when I first setup mutt because my previous mail client (XFMail) had been using them. Thought it would be the simplest way to make sure all of my existing folders and mail were brought into mutt. I'm going to have to look into this "maildir" format, I think. :-) By the way, is there a simple way to convert my existing folders to this format? -- Conrad Sabatier http://members.home.net/conrads/ ICQ# 1147270
Re: Russian charsets and automatic recoding
Denis Chapligin wrote: : How you maked this? How can i explain to mutt about cp1251? For stable branch -- only in compile-time. `charset-hook' and so on -- it's from unstable. My recomendation -- switch to 1.1.x. Yes, this is unstable branch, but wery stable in did. Charset handling in this branch implemented with using external charset files -- this allow add new charsets without recompilation of Mutt, and charset aliases -- without charset hooks. -- Andrew W. Nosenko([EMAIL PROTECTED])
Introduction to Maildir (was Re: mutt and mh/procmail)
2000-03-01-13:46:36 Phil Staub: > While I have some legacy MH folders that I would rather not > re-format, I don't have enough knowledge of maildir to have known > that one-file-per-message is possible with it. Looks like some > further study is indicated. Lemme try and give you a running start. http://www.qmail.org/qmail-manual-html/man5/maildir.html> http://cr.yp.to/proto/maildir.html> And a brief, informal overview. A maildir folder is a directory structure. Given a folder named "foo", there are three directories: foo/tmp/ foo/new/ foo/cur/ (in the order that messages flow through the dirs). To deliver a new message to a maildir, you write it into tmp, close it, then rename it into new. The file should be named to guarantee uniqueness; djb recommends time.pid.hostname, or, if one process wants to write multiple messages, time.pid_count.hostname. Once it's renamed into new/, delivery is complete. MUAs pick up new messages from new/. When they want to change the status of the message, they rename it into cur/, and they can stash flags (e.g. "replied-to", "seen", "marked-for-deletion", etc.) in the filename; djb has specific recommendations on how to do that. Here's a pretty safe maildir writer. Djb has some more rules for further paranoia; but the real world is not likely to bite you if you deliver messages like this. Written in Bourne Shell, but of course it codes into very lean, tight code in most any language. f=`date +%s`.$$.`hostname` cd $maildir cat >tmp/$f mv tmp/$f new/ -Bennett PGP signature
Re: Russian charsets and automatic recoding
Hi On Wed, Mar 01, 2000 at 09:45:14PM +0200, Marius Gedminas wrote: > > knows about a charset. > > > > My mutt does know about windows-1251. I'm using it for the body of > > this message, I think. > > Mine doesn't. Actually, it's not Mutt who doesn't know this charset, > it's my /usr/share/i18n/charmaps/ colection. However > :charset-hook windows-1251 cp1251 > helps: My mutt doesn't understands this command. -- Denis Chapligin
Re: Russian charsets and automatic recoding
Hi On Wed, Mar 01, 2000 at 04:52:19PM +, Edmund GRIMLEY EVANS wrote: > > There is one of message that i can't read with mutt > > It's in "windows-1251". Presumably your mutt doesn't know about that > charset. How can i give such knowledge to mutt? > I think you can tell whether mutt knows about a charset by going to > the compose menu and doing ":exec change-charset" on any text part. If > the charset you specify is not known to mutt, mutt gives an explicit > error. I'm not sure if there's an easier way of asking mutt whether it > knows about a charset. My mutt doesn't understand this command:( > My mutt does know about windows-1251. I'm using it for the body of > this message, I think. How you maked this? How can i explain to mutt about cp1251? > > Edmund > > (Ñàëóòîí! Êèåë âè ôàðòàñ?) unreadable. -- Denis Chapligin
Re: Russian charsets and automatic recoding
On Wed, Mar 01, 2000 at 04:52:19PM +, Edmund GRIMLEY EVANS wrote: > It's in "windows-1251". Presumably your mutt doesn't know about that > charset. > > I think you can tell whether mutt knows about a charset by going to > the compose menu and doing ":exec change-charset" on any text part. If > the charset you specify is not known to mutt, mutt gives an explicit > error. I'm not sure if there's an easier way of asking mutt whether it > knows about a charset. > > My mutt does know about windows-1251. I'm using it for the body of > this message, I think. Mine doesn't. Actually, it's not Mutt who doesn't know this charset, it's my /usr/share/i18n/charmaps/ colection. However :charset-hook windows-1251 cp1251 helps: > (Saluton! Kiel vi fartas?) (I don't have a cyrillic font and ICONV (or whatever Mutt 1.1.x uses) is smart enough to translate everything into ASCII). Once again -- could `charset-hook' be renamed to `charset-alias' before 1.2 please? It's not a hook. Definetely. Not a hook at all. Not even close to that. Marius Gedminas -- First rule of public speaking. First, tell 'em what you're goin' to tell 'em; then tell 'em; then tell 'em what you've tole 'em.
Re: mutt and mh/procmail
On Wed, Mar 01, 2000 at 07:06:42PM +0100, Thomas Roessler wrote: > On 2000-03-01 09:49:23 -0800, Phil Staub wrote: > > > I wouldn't call my reasons "grave", but I do have a certain > > amount of preference for MH folders. > > Let me put my question like this: Is it a preference for MH-style > folders, or is it a preference for the one-file-per-message folder > model? In the latter case, your needs are most probably perfectly > served with maildir. Now, *that* is an interesting question. While I have some legacy MH folders that I would rather not re-format, I don't have enough knowledge of maildir to have known that one-file-per-message is possible with it. Looks like some further study is indicated. Thanks, Phil -- Phil Staub Dragonfly Software Consulting Company. [EMAIL PROTECTED] 8196 SW Hall Blvd, Suite 104 503-641-3440 x33Beaverton, OR 97008 "Unix: because reboots are for hardware upgrades!"
Re: mutt and mh/procmail
On 2000-03-01 09:49:23 -0800, Phil Staub wrote: > I wouldn't call my reasons "grave", but I do have a certain > amount of preference for MH folders. Let me put my question like this: Is it a preference for MH-style folders, or is it a preference for the one-file-per-message folder model? In the latter case, your needs are most probably perfectly served with maildir. -- http://www.guug.de/~roessler/
Re: mutt and mh/procmail
I wouldn't call my reasons "grave", but I do have a certain amount of preference for MH folders. However, given the benefits of mutt over raw MH, it wouldn't exactly be a show stopper if I couldn't use MH for incoming mail. Thanks for your comments. Phil On Wed, Mar 01, 2000 at 02:48:48PM +0100, Thomas Roessler wrote: > On 2000-03-01 07:15:28 -0600, Conrad Sabatier wrote: > > > Yes, I've noticed that mutt behaves in a rather unreliable > > fashion when it comes to this, too. > > The mh code is far from perfect. It should be fine for converting > legacy mh-style folders to something else, but I wouldn't use it in > production for incoming folders. If there aren't any grave reasons > why you have to stick with mh folders, I'd suggest you switch to > maildir. > > -- > http://www.guug.de/~roessler/ > -- Phil Staub Dragonfly Software Consulting Company. [EMAIL PROTECTED] 8196 SW Hall Blvd, Suite 104 503-641-3440 x33Beaverton, OR 97008 "Unix: because reboots are for hardware upgrades!"
Re: checking pop mail in the background
Bevan Broun <[EMAIL PROTECTED]>: > > fetchmail doesn't require that either (I'm not sure if you were implying > > that it did, or not). And it can also be configured to use an > > ssh-tunnel for the pop-retrieval. > > Yes I did think fetchmail required a local smtp, glad Im wrong. I > might give it another look as it seems to be what most people are > using. I'm using fetchmail to call procmail directly. It works. But I am aware of several outstanding bugs in the way fetchmail handles UIDs. If you're leaving messages on the server and your network goes down while fetchmail is polling the server, expect nasty things to happen, like the list of UIDs being lost and masses of old duplicate messages being delivered. Maybe I'll get round to rewriting the UID code one day ... or maybe I'll be persuaded to use an alternative to fetchmail. Edmund
Re: Happy Little Vegemite
On Wed, Mar 01, 2000 at 01:53:34PM +0100, Thomas Roessler wrote: > On 2000-03-01 23:09:22 +1100, Chuck Dale wrote: > > > One way to make things clearer would be to have sections like > > > [colors] > > [keybindings] > > [mailboxes] > > [lists] > > [folder_hooks] > > You are completely free to create a set of configuration files, and > then source them. For instance, create a very simple ~/.muttrc > looking like this: [snip modular settings example] Perhaps what would be more useful would be a terse generic muttrc included with the distribution. The current one is over 70k and nearly 3000 lines. For newbies this can be a little intimidating, even if it is well documented. When I started using mutt back in the early 0.9x days I grabbed Michael's .muttrc which was nicely set up and had inline comments for most of the options. For me, it was just what I needed. If I needed to set an option, there was not much to search through, and the more complicated bits (like folder-hooks) had examples and short documentation sections preceding them. Again, the existing Muttrc is nice in that it has documentation explaining all of the options right there with the option, but I'm wondering if it wouldn't be better to turn that into a documentation file and make a smaller, modularized via comments, example Muttrc. The early header could refer to the larger file or to the manual page on www.mutt.org so that if more information was needed on a particular setting it could be easily found. Most settings could be explained with a simple inline comment, and things like folder hooks could have a couple of examples. I'd even be tempted to make a directory of muttrc files, each with their own names. One named "generic" might be the one that has all the options commented out and set to their defaults, "pinecone" could have the key bindings set to mimic the Another Mail Client, and "tedturner" would have lots of color options set. Just a thought. jf -- John Franklin [EMAIL PROTECTED] ICBM: N37 12'54", W80 27'14" Z+2100'
Re: Russian charsets and automatic recoding
Denis Chapligin <[EMAIL PROTECTED]>: > There is one of message that i can't read with mutt It's in "windows-1251". Presumably your mutt doesn't know about that charset. I think you can tell whether mutt knows about a charset by going to the compose menu and doing ":exec change-charset" on any text part. If the charset you specify is not known to mutt, mutt gives an explicit error. I'm not sure if there's an easier way of asking mutt whether it knows about a charset. My mutt does know about windows-1251. I'm using it for the body of this message, I think. Edmund (Ñàëóòîí! Êèåë âè ôàðòàñ?)
Re: Happy Little Vegemite
On Wed, Mar 01, 2000 at 11:09:22PM +1100, Chuck Dale wrote: > One way to make things clearer would be to have sections like > [colors] > [keybindings] > [mailboxes] > [lists] > [folder_hooks] This seems to work on the assumption that all ~/.muttrc files are one large monolithic list of settings. This doesn't have to be the case. Mine isn't and, if I could be bothered, I could make it even smaller with good use of the `source' command. That said, mine does contain sections as well. I find that the "#" character is a great way of prefixing a section name. > This would bring some structure to the file which it currently lacks.. > It's good to have some structure once every few years.. There already is structure if you decide to use structure. -- Take a look in Hagbard's World: | mutt.octet.filter - autoview octet-streams http://www.hagbard.demon.co.uk/ | mutt.vcard.filter - autoview simple vcards http://www.acemake.com/hagbard/ | muttrc2html - muttrc -> HTML utility Free software, including| muttrc.sl - Jed muttrc mode
Re: mutt and mh/procmail
On 2000-03-01 07:15:28 -0600, Conrad Sabatier wrote: > Yes, I've noticed that mutt behaves in a rather unreliable > fashion when it comes to this, too. The mh code is far from perfect. It should be fine for converting legacy mh-style folders to something else, but I wouldn't use it in production for incoming folders. If there aren't any grave reasons why you have to stick with mh folders, I'd suggest you switch to maildir. -- http://www.guug.de/~roessler/
Re: Russian charsets and automatic recoding
Hi On Wed, Mar 01, 2000 at 02:51:59PM +0200, Andrew W. Nosenko wrote: > : > : How can i make Mutt automaticly recode e-mails from one character set to another >one? > > I not have any problems with it. > Is your `charset' variable set properly? Yes. > What is your local encoding? KOI8-R > What is encoding of recode-failed message (for example)? There is one of message that i can't read with mutt >From chollya Wed Mar 1 16:03:10 2000 Return-path: <[EMAIL PROTECTED]> Envelope-to: [EMAIL PROTECTED] Delivery-date: Wed, 1 Mar 2000 16:11:30 +0200 Received: from [192.168.169.4] (helo=stan) by wbt.ru with smtp (Exim 2.11 #1) id 12Q9qc-7a-00 for [EMAIL PROTECTED]; Wed, 1 Mar 2000 16:11:30 +0200 Message-ID: <000901bf8380$6c97bf40$[EMAIL PROTECTED]> From: =?windows-1251?B?0fLg7ejx6+DiIM7r7uL/4+jt?= <[EMAIL PROTECTED]> To: =?windows-1251?B?1+Dv6/vj6O0gxOXt6PE=?= <[EMAIL PROTECTED]> Subject: =?windows-1251?B?z+jx/Ozu?= Date: Wed, 1 Mar 2000 16:16:25 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Status: RO X-Status: A Content-Length: 13 Lines: 2 Ïèñüìî 1251 -- Denis Chapligin
Re: Happy Little Vegemite
Wrote Eugene Lee on Wed, Mar 01, 2000 at 04:50:09AM -0800: > I don't know if this division of labor will work for all but the most > simplest configurations. An example would be a complex set of folder > hooks where colors, key bindings, save hooks, and other settings. > Now imagine you had different sets of settings for different folders! Hmm yeah I'm beginning to think that this was not a particularly useful idea.. Chuck
Re: Happy Little Vegemite
Wrote Matthew Hawkins on Wed, Mar 01, 2000 at 11:46:58PM +1100: > On 2000-03-01 23:09:22 +1100, Chuck Dale wrote: > > > > > > The problem (as I see it) is that .muttrc goes against the principles > > which Mutt is following. Particularly in modularisation. The .muttrc > > contains absolutely everything configurable in the program - it defines > > the interface (keys, column presentation, folder hooks, colours), mail transfer > > (sendmail settings, mailboxes which receive mail), personal settings > > (real name, personal headers) and a few other random settings as well. > > > > > > Actually it doesn't have to have anything at all. You can get by with > no .muttrc. In fact, sometimes I start mutt with "-F /dev/null" when I > need to do something where I know stuff in my .muttrc is going to stop > me, for example I want to use another IMAP server and have none of my > hooks (which really are tied to my normal server) working. Exactly right - .muttrc doesn't have to do anything at all. But it can also define absolutely everything. This does not make it modular or easy to understand. Big bloated programs like sendmail (ooh is that a bad thing to say?) don't have to do anything at all. You can just use sendmail as an MTA and not set it up as an MDA. This does not make it a good structure. We are talking clearly defining purposes and keeping modules within those purposes. So have a few config files for the various settings, or put them into sections. Mutt may be extremely powerful but you've got to take that power and make it usable by users who aren't as smart as you. This isn't about making mutt make more sense for the current, hardcore users or those who want to put the effort required in to be a hardcore user, this is about making mutt accessible to a few more people who otherwise would never bother trying to understand Mutt and stick with Pine or something. And don't tell say "you can just use the default setup without a .muttrc". Pine has much better new user defaults. So users use Pine. They are disappointed by the lack of depth. They might try mutt but have difficulty getting anywhere. Why not make mutt usable in the default setup? And not just usable in terms of sending and receiving mail, but usable in terms of intuitive ways of switching mailboxes and an interface to change user options rather than editing .muttrc by hand. Users who try mutt don't want the basic operations which they can get anywhere, they want an easy way of using the powerful features that Mutt is always said to have. Mutt seems to have followed the Unix lie: that making interfaces simpler to use for the novice is "dumbing down" the program and that a good program is one that gives the advanced user as many options as possible. The Unix lie says that advanced users are somehow smarter than less experienced users. Of course not, they are just people who've had more time to learn the interface. Make the interface simple for novices but keep all the power and excellent features. These are not opposing ideals. If something is useful and makes sense for advanced users then include an option for it, don't put it near the default. Maybe it would be good to take the useful part out of the Windows lie: that the interface should be as simple as possible for the novice user but have absolutely no depth in terms of customisability or usability for advanced users. Simplicity + Depth I'll just shut up now. Night! Chuck
Re: Happy Little Vegemite
On 2000-03-01 23:09:22 +1100, Chuck Dale wrote: > One way to make things clearer would be to have sections like > [colors] > [keybindings] > [mailboxes] > [lists] > [folder_hooks] You are completely free to create a set of configuration files, and then source them. For instance, create a very simple ~/.muttrc looking like this: source ~/.mutt/settings source ~/.mutt/colors source ~/.mutt/keybindings source ~/.mutt/mailboxes source ~/.mutt/lists source ~/.mutt/hooks source ~/.mutt/aliases set alias_file=~/.mutt/aliases You can then modularize all your configuration with the aid of these files. Actually, I think there are even some samples of this flowing around. You are also free to provide _and_ _maintain_ reasonably documented sample files fitting into this pattern. > 1. Sectionalise the config file to make the options easier to > find. See above. > 2. Provide a graphical tool for newusers in the vein of > fetchmailconf. As Mikko suggested. You are free to write one, as is everyone else. > That's a bad argument. Of course you are never going to make it > "dead easy". But you just keep trying until it is as easy as > possible. And the current Mutt configuration requires way too > much initial effort to understand. I beg your pardon? It's quite sufficient to know that the muttrc(5) manual page exists (as of 1.1 ;), and to remember this fact. You can then easily search for key words and will, in most cases, immediately find the option you are looking for. The same thing is true for the manual's reference section. >> So you think it would be nice to learn things "little by >> little"? Sure, that's possible too, start with no .muttrc at >> all. Then when you run into something you'd like to change, >> read the manual and add the relevant sections to your .muttrc. > But it's very difficult to learn little by little with Mutt. I beg your pardon? > Because Mutt makes very little sense to do even basic mail stuff > the first time you use it. Apart from sending and receiving mail > that is. Hey, that's what mutt is about! You can then easily go to the web site, fetch other users' commented configuration files, browse through them for interesting settings, and start working with them. > There are so many things that are non-intuitive: using folders, What do you mean by "using folders"? The hooks? Or changing to folders? Defining mailboxes? > the help (I don't consider three screens of tersely described > shortcuts to be "help"), and more (I'll think of them later..). Once again, you are free to create a context-sensitive help syste, provided you promise to maintain it, and provided it doesn't bloat the code without end. > The counter to this is that the Mutt user will already have to > know a fair bit about email to get anywhere at all with Mutt. > i.e. have configured fetchmail to get their mail from a POP > server, configured sendmail to send out mail correctly > masqueraded etc. Sorry, but these issues are just far outside of mutt's scope. Mutt is a rather traditional Unix mail user agent, just like elm, mailx, mh, mush, and the like. That is, it leaves jobs which can be done by the underlying system to that system, and doesn't try to duplicate functionality which is present at other places on the system. Getting the mail system configured, getting fetchmail to work (BTW, there is some basic POP support in Mutt), and the like are issues which should be solved by system suppliers. -- http://www.guug.de/~roessler/
Re: mutt and mh/procmail
On Tue, Feb 29, 2000 at 09:57:05PM -0800, Phil Staub wrote: > > My major questions relate to getting mutt to properly detect the fact > that mail has been newly deposited into mh folders that I have > designated in my .muttrc as mailboxes. I've been getting new mail > reported in folders that are completely empty, as well as no report > when new mail *is* in the folders. > > For the record, I am using rcvstore to insert the mail into the > mailboxes, and I do not have either biff or xbiff running to watch for new > mail. Yes, I've noticed that mutt behaves in a rather unreliable fashion when it comes to this, too. I don't use mh's "rcvstore" in procmail, just the simple "foldername/.", which works just fine at adding mail to a folder. Rather than being advised of new mail in mutt, I see messages saying "Mailbox was externally modified. Flags may be wrong." I also see folders marked as having new mail, even after I've just finished reading them and I *know* there's no new mail in them. I'd really like to know how to get new mail notification to work properly, too. Other than this, I think mutt is a fantastic mail client. > I've also read most of the man pages on procmail, and scanned through > the mutt manual. I'm aware of the warning in the procmail pages about > file locking being unreliable for MH mailboxes. > > Finally, I only recently subscribed to the mailing list, and yet > already I've seen other references to problems with new mail > detection, even for those not using mh mailboxes. Perhaps 1.1.7 will > resolve this? Haven't had time to download it yet, but it might be > worth a try. Same here. I do intend to give it a try as soon as I have the time to set it up. :-) -- Conrad Sabatier http://members.home.net/conrads/ ICQ# 1147270
Re: Russian charsets and automatic recoding
Denis Chapligin wrote: : Hi : : How can i make Mutt automaticly recode e-mails from one character set to another one? I not have any problems with it. Is your `charset' variable set properly? What is your local encoding? What is encoding of recode-failed message (for example)? -- Andrew W. Nosenko([EMAIL PROTECTED])
Re: Happy Little Vegemite
On Wed, Mar 01, 2000 at 11:09:22PM +1100, Chuck Dale wrote: : : : :The problem (as I see it) is that .muttrc goes against the principles :which Mutt is following. Particularly in modularisation. The .muttrc :contains absolutely everything configurable in the program - it defines :the interface (keys, column presentation, folder hooks, colours), mail transfer :(sendmail settings, mailboxes which receive mail), personal settings :(real name, personal headers) and a few other random settings as well. : : : :One way to make things clearer would be to have sections like :[colors] :[keybindings] :[mailboxes] :[lists] :[folder_hooks] I don't know if this division of labor will work for all but the most simplest configurations. An example would be a complex set of folder hooks where colors, key bindings, save hooks, and other settings. Now imagine you had different sets of settings for different folders! -- Eugene Lee [EMAIL PROTECTED]
Re: Happy Little Vegemite
On 2000-03-01 23:09:22 +1100, Chuck Dale wrote:
>
>
> The problem (as I see it) is that .muttrc goes against the principles
> which Mutt is following. Particularly in modularisation. The .muttrc
> contains absolutely everything configurable in the program - it defines
> the interface (keys, column presentation, folder hooks, colours), mail transfer
> (sendmail settings, mailboxes which receive mail), personal settings
> (real name, personal headers) and a few other random settings as well.
>
>
Actually it doesn't have to have anything at all. You can get by with
no .muttrc. In fact, sometimes I start mutt with "-F /dev/null" when I
need to do something where I know stuff in my .muttrc is going to stop
me, for example I want to use another IMAP server and have none of my
hooks (which really are tied to my normal server) working.
> One way to make things clearer would be to have sections like
> [colors]
> [keybindings]
> [mailboxes]
> [lists]
> [folder_hooks]
Nothing stops you from laying out your .muttrc file like this. In fact,
this is the exact layout my own personal .muttrc file takes.
Having specifically-named sections as an object to parse is a pointless
waste of space and parsing time. If it really bugs you, use a comment.
For example:
# colors
color index blue default ~F
color index red default ~N
color index magenta default ~T
color index yellow default ~D
# key bindings
bind index p previous-entry
bind index n next-entry
# mailboxes
set imap_user="fred"
set folder="{mail.example.org}INBOX."
set spoolfile="{mail.example.org}INBOX"
# lists
subscribe [EMAIL PROTECTED] [EMAIL PROTECTED]
subscribe [EMAIL PROTECTED]
lists [EMAIL PROTECTED]
# hooks
folder-hook . unscore *
folder-hook . score '~A' +50
folder-hook . score '~F' +50
folder-hook . score '~E' -60
save-hook ~l +%B
--
Matt "...the only place for 63,000 bugs is a rain forest"
Re: Happy Little Vegemite
> They *are* settable within the interface. Just type ":set " > (and keep repeating pressing tab until you get to the setting you want > to change). :-) Of course it won't save the settings > > Anyway, all silliness aside, what's different from doing the changes > "within the interface" as compared to editing a .muttrc file? And you > say that the example .muttrc's are too long and complain too many > options -- that problem won't go away with having an interface? It makes much more sense to be able to change something as you use it rather than set options apart from the interface. This is obviously much easier in a GUI where you can do things like change column widths, move columns around, perform Gimp-style funky rebinding of keys direct in the menus. And then have a preferences dialogue for the more abstract settings. The problem (as I see it) is that .muttrc goes against the principles which Mutt is following. Particularly in modularisation. The .muttrc contains absolutely everything configurable in the program - it defines the interface (keys, column presentation, folder hooks, colours), mail transfer (sendmail settings, mailboxes which receive mail), personal settings (real name, personal headers) and a few other random settings as well. One way to make things clearer would be to have sections like [colors] [keybindings] [mailboxes] [lists] [folder_hooks] This would bring some structure to the file which it currently lacks.. It's good to have some structure once every few years.. > There is not that much difference in having an interactive interface > where you can change settings, than having a config file. Both will > contain the same settings if you use an example .muttrc, and if the > example .muttrc has good comments then it's equal to having > context-sensitive help. You said the word - "Context". Interactive interfaces are much better than a config file because you don't have to search through 280 options in a config file, you can simply choose from the options available in context. For example in the mailbox selection view it would be nice to be able to add a new mailbox to read. But again, this is all mostly much too hard in a text interface because you have no room to drag in a new mailbox, have sliders etc. Actually I'm forgetting the entire context argument and interactive interface thing. It's just not going to happen and would be stupid anyway.. But can I make two recommendations? 1. Sectionalise the config file to make the options easier to find. 2. Provide a graphical tool for newusers in the vein of fetchmailconf. As Mikko suggested. [...] > Mutt has a lot of configuration directives, that's part of the reason > why it is so powerful. No matter how hard you try, you can't make that > "dead easy". Sure good documentation helps, but even that won't get > over the fact that the user does need to learn things in order to use > the configuration effectively. That's a bad argument. Of course you are never going to make it "dead easy". But you just keep trying until it is as easy as possible. And the current Mutt configuration requires way too much initial effort to understand. > So you think it would be nice to learn things "little by little"? Sure, > that's possible too, start with no .muttrc at all. Then when you run > into something you'd like to change, read the manual and add the > relevant sections to your .muttrc. But it's very difficult to learn little by little with Mutt. Because Mutt makes very little sense to do even basic mail stuff the first time you use it. Apart from sending and receiving mail that is. There are so many things that are non-intuitive: using folders, the help (I don't consider three screens of tersely described shortcuts to be "help"), and more (I'll think of them later..). The counter to this is that the Mutt user will already have to know a fair bit about email to get anywhere at all with Mutt. i.e. have configured fetchmail to get their mail from a POP server, configured sendmail to send out mail correctly masqueraded etc. (Sorry for the ranting nature of this message. These are my frank impressions of Mutt after all of two days usage.) Thanks for listening, Chuck
[1.1.7] IMAP segfault
The attached patch fixes a segmentation fault which would occur when
the operates without a Context (this happens, for instance, when you
can't connect to an IMAP folder).
--
http://www.guug.de/~roessler/
Index: imap/util.c
===
RCS file: /home/roessler/cvsroot/mutt/imap/util.c,v
retrieving revision 1.18
diff -u -p -u -r1.18 util.c
--- imap/util.c 2000/02/28 17:54:41 1.18
+++ imap/util.c 2000/03/01 11:56:53
@@ -375,12 +375,12 @@ int imap_wait_keepalive (pid_t pid)
void imap_allow_reopen (CONTEXT *ctx)
{
- if (ctx->magic == M_IMAP && CTX_DATA->selected_ctx == ctx)
+ if (ctx && ctx->magic == M_IMAP && CTX_DATA->selected_ctx == ctx)
CTX_DATA->reopen |= IMAP_REOPEN_ALLOW;
}
void imap_disallow_reopen (CONTEXT *ctx)
{
- if (ctx->magic == M_IMAP && CTX_DATA->selected_ctx == ctx)
+ if (ctx && ctx->magic == M_IMAP && CTX_DATA->selected_ctx == ctx)
CTX_DATA->reopen &= ~IMAP_REOPEN_ALLOW;
}
PGP signature
Re: Threading Characters
Wrote Thomas Roessler on Wed, Mar 01, 2000 at 12:05:34PM +0100: > Funny. Some of the stuff I'm seeing in "Clean" heavily reminds me > of Atari's character set used with their STs, although other things > definately looked different, for instance the shape of the "a". > (Actually, there seems to be an Atari Logo hidden in that font.) > > Anyway, this font seems to have some more encoding issues than the > one you mention: At least here, iso-8859-1 Umlauts (äöüß, ...) > aren't displayed at all. I'm not sure it's really the font you want > to use. It is a really nice font. It is the only monospaced font that I have ever liked. Even if Netscape's proportional fonts look abysmal I'm always happy I can have Clean to look nice for me. The Lucida settings just don't do it for me.. But thanks for the set ascii_chars tip, that made things much more readable.. Thanks for your help, Chuck
Re: Threading Characters
Chuck Dale <[EMAIL PROTECTED]>: > Using my favourite terminal font, Clean (Schumacher), the threading > arrows are all wrong and turn out as little musical notes etc. This font > is installed with the XFree86-75dpi-fonts RPM on my RH6.0 system. > > Is there any way to use different characters for the threading arrows > that would be more displayable by my font? Even if they were not as nice > as the normal ones. set ascii_chars=yes
Re: Threading Characters
On 2000-03-01 21:45:57 +1100, Chuck Dale wrote: > Is there any way to use different characters for the threading > arrows that would be more displayable by my font? Even if they > were not as nice as the normal ones. PS: set ascii_chars. -- http://www.guug.de/~roessler/
Re: Threading Characters
On 2000-03-01 21:45:57 +1100, Chuck Dale wrote: > Using my favourite terminal font, Clean (Schumacher), the > threading arrows are all wrong and turn out as little musical > notes etc. This font is installed with the XFree86-75dpi-fonts > RPM on my RH6.0 system. Funny. Some of the stuff I'm seeing in "Clean" heavily reminds me of Atari's character set used with their STs, although other things definately looked different, for instance the shape of the "a". (Actually, there seems to be an Atari Logo hidden in that font.) Anyway, this font seems to have some more encoding issues than the one you mention: At least here, iso-8859-1 Umlauts (äöüß, ...) aren't displayed at all. I'm not sure it's really the font you want to use. However, at least in some sizes, "Lucida Typewriter" and "fixed" look very similar to "Clean". I'm using these settings with xterm and quite like the resulting look: >> .Xresources << XTerm*boldFont: -*-fixed-bold-*-*-*-14-*-*-*-*-*-iso8859-1 XTerm*font: 7x14 >> << Maybe, this looks sufficiently similar to what you like. -- http://www.guug.de/~roessler/
Threading Characters
Dear List. Using my favourite terminal font, Clean (Schumacher), the threading arrows are all wrong and turn out as little musical notes etc. This font is installed with the XFree86-75dpi-fonts RPM on my RH6.0 system. Is there any way to use different characters for the threading arrows that would be more displayable by my font? Even if they were not as nice as the normal ones. Or any other options short of using a different font? Thanks, Chuck
Re: Mutt colours in xterm
On 2000-03-01 10:12:00 +0100, Thomas Roessler wrote: > The trick should be using a TERM setting which supports color. On > my Debian system, I'm using TERM=xterm-xf86-v33, and it works nicely. I think TERM=xterm-debian (the default in potato at least) gives colour as well. I usually use the one supplied by the author of the terminal emulator I use, TERM=rxvt for Rxvt, etc. Sometimes this involves using tic to add the entry to the terminfo database. I'm a strong believer in the TE author's own terminal capabilities file being the most correct ;) -- Matt "...the only place for 63,000 bugs is a rain forest"
Re: Russian charsets and automatic recoding
Denis Chapligin <[EMAIL PROTECTED]>: > How can i make Mutt automaticly recode e-mails from one character > set to another one? If it's installed properly, it should handle charsets correctly. Do you have a specific problem? I recommend upgrading to 1.0.1, by the way; the only differences between 1.0pre and 1.0.1 are bug fixes. Edmund
Re: Mutt colours in xterm
On Wed, Mar 01, 2000 at 09:01:44AM +, Glyn Millington wrote: > I spent a happy half-hour building mutt-1.7.1i last night,(with ncurses) fired > it up in console mode - colours as usual - brilliant! > > Trying it this morning in an x-term I'm reduced to mono. Not a big problem but > I like the colours and they do make reading easier. Is there anything I need to >tweak either in the system Muttrc or in the building process that I am overlooking. You need to check if your $TERM variable is set to something that supports color (e.g. `xterm-color') or maybe set the $COLORTERM variable. > I'm running Mutt on Mandrake Linux 6.1 (beautiful) - and my Mutt-1.0.1 rpm > supplied with that system does produce colours in an xterm, which suggests, on > reflection, that the trick is in the compiling, but where? AFAIR Mutt from Mandrake RPMs is compiled with slang, not ncurses. Unfortunatelly, all versions of S-Lang that I've seen have problems with Alt+ combinations (as witnessed in the Mutt's INSTALL file), so I'd suggest trying `export TERM=xterm-color'. Marius Gedminas -- MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development. -- [EMAIL PROTECTED]
Re: Mutt colours in xterm
On 2000-03-01 09:01:44 +, Glyn Millington wrote: > Mail-Followup-To: Glyn Millington <[EMAIL PROTECTED]>, > Mutt Mailing List <[EMAIL PROTECTED]> Most probably, you want to read README.UPGRADE and change the "lists" settings in your configuration file. ,-) > Trying it this morning in an x-term I'm reduced to mono. Not a > big problem but I like the colours and they do make reading > easier. Is there anything I need to tweak either in the system > Muttrc or in the building process that I am overlooking. The trick should be using a TERM setting which supports color. On my Debian system, I'm using TERM=xterm-xf86-v33, and it works nicely. In order to get this nicely set, add the following lines to your ~/.Xresources file: #ifdef COLOR *customization: -color XTerm*termName: xterm-xf86-v33 #endif -- http://www.guug.de/~roessler/
Re: Happy Little Vegemite
On Wed, Mar 01, 2000 at 10:13:41AM +1100 or thereabouts, Chuck Dale wrote: > Wrote Mikko Hänninen on Tue, Feb 29, 2000 at 09:34:37PM +0200: > > If you ask me, I wouldn't use sendmail as a newbie's MTA, the beast is > > not for the faint at heart. > > And the ironic thing is that sendmail is pretty much the newbie's MTA. > Think how many RedHat installs are running sendmail without the user > knowing what it is.. > > But that's no reason to not explain things better. If I read less > "sendmail is extremely complex" and "it is very difficult to get a hold > of" and more actual sendmail documentation I'm sure it wouldn't seem so > complex. I dunno. I leave mine well alone. But I have seen "simple" sendmail.cf files, and I have heard people who know what they're doing complain about their more complicated ones. And they still reach for the gigantic book when they change anything. By contrast, the exim config file is a delight. I had to alter something very urgently once, and it was a piece of cake (and worked). I agree that the FAQ or documentation explaining clearly, "MTAs do this, this and this. Here are links to common ones. MUAs do this, this and this. Mutt is an example. Neither of them filter incoming email into folders. For that you need procmail, maildrop (?) or (whatever): here are links" right at the start might help. It's on the webpage, and very clear there. But in the mutt manual as well might be a thought. > > > There are way too many options in the sample config file. > > > At least the standard ones which users might like to change should be > > > put at the top of the file and the more esoteric below that. > > > > There are some really good example .muttrc-files on the web (Telsa's > > example comes to mind *grin*). Aww. Sweetie :) > I did actually read a number of these (Telsa's was first), but they are > very long files to try and fit into your head. I'd much prefer lots of > those settings to also be settable within the interface where I actually > want the change rather than reading a config file. They're hugely long, yes. I know mine is. What I did want to do (in my Copious Free Time) was to do something else, with a list of "what do you want to alter? Your headers. Folders. How you sort things" and put little links in to the few headers you need, so that people who just want to add pgp/gnupg don't have to wade through folder-hooks and people who want folder-hooks don't have to read about getting mutt to get your multiple addresses right. It's on my to-do list. But it's not going to happen for a while; I know that much. :( Telsa
Russian charsets and automatic recoding
Hi How can i make Mutt automaticly recode e-mails from one character set to another one? -- Denis Chapligin
Mutt colours in xterm
: The soul is greater than the hum of its parts Hi. I spent a happy half-hour building mutt-1.7.1i last night,(with ncurses) fired it up in console mode - colours as usual - brilliant! Trying it this morning in an x-term I'm reduced to mono. Not a big problem but I like the colours and they do make reading easier. Is there anything I need to tweak either in the system Muttrc or in the building process that I am overlooking. I'm running Mutt on Mandrake Linux 6.1 (beautiful) - and my Mutt-1.0.1 rpm supplied with that system does produce colours in an xterm, which suggests, on reflection, that the trick is in the compiling, but where? Can anyone help brighten my e-mail? TIA Glyn M.
Re: Happy Little Vegemite
Mikko Hänninen ([EMAIL PROTECTED]) wrote : > > You can actually get by with *no* .muttrc, pretty much everything in > Mutt has reasonable defaults. When I was starting with mutt I just get Sven's config, edit hostname and headers and run mutt. When I needed to change something I look into documentation and change it. > It would be nice if Mutt did have some sort of configuration tool like > the Linux kernel "make menuconfig" -- but that shouldn't necessarily be > part of the Mutt program itself, just an additional tool. Even with > that you wouldn't be able to (easily?) create hooks and such, at least > no complex hooks, so at some point you will have to resort to config > file editing if you'd want a really complex configuration. I don't think so, becouse make menuconfig mess new unix users, becouse they don't read documentation just try it and if is somethink wrong they wrote emails to conferece. I think configure is pretty nice. I remember time when you was manualy edit Makefile for compiler options. > > In my opinion the best way to help newbies create their first .muttrc's > would be a tool like the linux "make menuconfig" that could have > different sections (basic settings, POP setup, IMAP setup, mailboxes, > mailing lists, misc advanced settings, ...) and then have > context-sensitive help for each setting, direct from the Mutt manual > SGML file. However, doing something like that is a fair bit of work, > and I know I don't have the time to do it. > This is absolutly wrong way! Becouse if you give newbie tool to create simple config file, they'll expect tool to create complex config file. -- Keso don't worry about glory
