FYI: MIME RFC's
This link is to 'gmime'. The site starts off with a list of MIME RFC's that the program deals with. I have no idea if these are all the important or necesssary ones, but the list will certainly give you an idea for what's involved in making a good email client these days. A few of us were talking about 'mutt' and RFC's a few meetings back, so I thought I'd pass it along. -- - Martin J. Brown, Jr. - - [EMAIL PROTECTED] - Public PGP Key ID: 0xDB184F7B keyserver: http://certserver.pgp.com/ msg29970/pgp0.pgp Description: PGP signature
Re: basic shell funtionality?
Hi, * Lukas Schroeder [02-07-30 23:37:57 +0200] wrote: does mutt have some basic shell functionality built in? i'd like to 'cd' and 'pwd', so that i can conveniently store attachments where i want them - especially when i have to store multiple attachments in a row into a directory that is not $PWD... quitting mutt and returning is quite inconvenient, so is a second terminal at times to move the files to their target directory... I've made a short patch adding a variable ``attach_dir'' which is the default location to save attachements to. If it is empty, mutt uses the current directory; if not the specified is prepended so that you can already see at the prompt where your files will end up. bye, Rocco [how to save attachements to a specific dir is becoming a FAQ, btw]
Re: basic shell funtionality?
On Wed, Jul 31, 2002 at 11:12:11AM +0200, Rocco Rutte wrote: * Lukas Schroeder [02-07-30 23:37:57 +0200] wrote: does mutt have some basic shell functionality built in? i'd like to 'cd' and 'pwd', so that i can conveniently store attachments where i want them - especially when i I've made a short patch adding a variable ``attach_dir'' which is the default location to save attachements to. If it is empty, mutt uses the current directory; if not the specified is prepended so that you can already see at the prompt where your files will end up. but i have to save all attachments into that single directory? that's basically what i excercise now: save to ~/tmp and move the files later, to where they should've gone in the first place... what i have in mind is functionality similar to vim's :cd and :pwd commands. that would make my day(s)... this is not yet implemented, is it? regards, -lukas
Re: problem about subjects in asian charsets
On Tue, Jul 30, 2002 at 04:54:18PM +0800, Isaac Claymore wrote: However, whenever I send emails with a subject in Chinese, the receiver gets something like this :Subject: =?zh_cn.gb2312?B?uf65/g==?=, although all other parts of the mail are fine. Thanks for hints and suggestions.(please CC to me, i'm not on this list) Having not seen any of the replies (yet?), may I add here my apparently similar problem? (No mention of an archive at mutt.org, or in the FAQ) Despite the following in ~/.muttrc : set charset=iso-8859-1 set use_8bitmime set allow_8bit charset-hook US-ASCII ISO-8859-1 # Above didn't fix it, so charset-hook x-unknownISO-8859-1 # try these as well. my otherwise friendly mutt lists a received iso-8859-1 test email as: 100 N + Jul 19 Erik Christians ( 4) Forbl?ffende Ul?selig V?s Subsequent display of the email contents by mutt shows: Subject: Forbl\370ffende Ul\346selig V\345s But hitting e , to examine the mail in vim, shows the correct text: Subject: Forbløffende Ulæselig Vås A couple of hour's snuffling about the web revealed Sven's .muttrc, and a few others, but neither those hints nor the manpage cast enough light for me to see the solution, so far. Would whatever helped Isaac also fix this one? Regards, Erik
muttprofile (new)
Hello, I did some changes to Muttprofile (originally written by Martti Rahkila). Basically I just added a small GUI to make it look similar to Mutt's internal view of aliases, but for profiles then. I know Mutt is very good with different hooks for different mailboxes etc, but sometimes it's useable to have a selection of different profiles, and then I wanted it to work like it's part of Mutt. Check it out at the url below if you're interested, there's also a screenshot demonstrating how it looks like. http://ratblast.net/muttprofile cheers, rikard
Re: basic shell funtionality?
Hi, * Lukas Schroeder [02-07-31 12:17:44 +0200] wrote: On Wed, Jul 31, 2002 at 11:12:11AM +0200, Rocco Rutte wrote: I've made a short patch adding a variable ``attach_dir'' which is the default location to save attachements to. If it is empty, mutt uses the current directory; if not the specified is prepended so that you can already see at the prompt where your files will end up. but i have to save all attachments into that single directory? It depends. What you have to do (with the patch applied) is just to go to the attachements menu and: ':set attach_dir=location' Then save all attachements you want to have in $location. If you want to save others to a different location, just do: ':set attach_dir=location2' (you would have to do the same with ':cd' and ':pwd', btw) what i have in mind is functionality similar to vim's :cd and :pwd commands. that would make my day(s)... this is not yet implemented, is it? 'cd' and 'pwd' are not implemented, but with my patch they both work for attachements. The 'cd' command in mutt then reads: ':set attach_dir=...' and 'pwd' reads: ':set ?attach_dir' to find out the current location. And as I said, the prompt now contains the full filename (i.e. the full pathname + the full filename) instead of just the filename without knowing where it'll end up. bye, Rocco
Re: problem about subjects in asian charsets
On Tue, Jul 30, 2002 at 10:38:55PM +0200, Alain Bench wrote: Hello Isaac, On Tuesday, July 30, 2002 at 4:54:18 PM +0800, Isaac Claymore wrote: whenever I send emails with a subject in Chinese, the receiver gets something like this :Subject: =?zh_cn.gb2312?B?uf65/g==?= This gets decodable (everywhere?) once the zh_cn. removed. So if your iconv knows it, try to set gb2312 only: set charset=gb2312 set send_charset=us-ascii:iso-8859-1:gb2312 It works ;) BTW here with libiconv 1.8: $ iconv -l | grep 2312 CHINESE GB_2312-80 ISO-IR-58 CSISO58GB231280 CN-GB EUC-CN EUCCN GB2312 CSGB2312 HZ HZ-GB-2312 please CC to me, i'm not on this list Inform Mutt about this, using lists [EMAIL PROTECTED] and set followup_to directives. I've read 'man muttrc' about 'lists' 'followup_to', and your instruction is pretty helpful, thanks man. HTH, and bye! Alain.
Re: muttprofile (new)
On Wed, Jul 31, 2002 at 12:30:52PM +0200, Rocco Rutte wrote: Hi, * Rikard Florin [02-07-31 12:17:50 +0200] wrote: http://ratblast.net/muttprofile Perl, how cool is that! I'm planning to start a project (on sourceforge or whereever) which just bundles a few but very useful (preferebly perl) scripts dealing with .muttrc. Some alias conversion scripts, muttrc2html, maybe muttrcbuilder and the like. A script dealing with profiles would perfectly fit in my ideas. Interested? Anyone else interested in hacking some perl? I'm always interested in hacking perl :) -- Dan Boger [EMAIL PROTECTED] msg29977/pgp0.pgp Description: PGP signature
Re: muttprofile (new)
Hi, * Rikard Florin [02-07-31 12:17:50 +0200] wrote: http://ratblast.net/muttprofile Perl, how cool is that! I'm planning to start a project (on sourceforge or whereever) which just bundles a few but very useful (preferebly perl) scripts dealing with .muttrc. Some alias conversion scripts, muttrc2html, maybe muttrcbuilder and the like. A script dealing with profiles would perfectly fit in my ideas. Interested? Anyone else interested in hacking some perl? bye, Rocco
Re: muttprofile (new)
On Jul 31, 2002 at 12:30:52PM, Rocco Rutte wrote: Perl, how cool is that! I'm planning to start a project (on sourceforge or whereever) which just bundles a few but very useful (preferebly perl) scripts dealing with .muttrc. Some alias conversion scripts, muttrc2html, maybe muttrcbuilder and the like. A script dealing with profiles would perfectly fit in my ideas. Interested? Anyone else interested in hacking some perl? speaking for myself I have way too little experience of Perl to be part of something like this. I just hacked around a bit and I think I better spare the world any other treatments coming from my side... ;) although, sounds like a cool idea otherwise and I would gladly see development of Muttprofile continued. I just think that I've brought it as far as I can for now. I just recently converted from Pine to Mutt and I feel totally in love every time I use it! cheers, rikard
Display of non-ascii chars
Dear all, I have some issue with the displaying of non-ascii chars in my mail. I have to admit that I am not 100% sure that this is a mutt-issue or more shell or terminal related. Sorry if it is off-topic, I have tried all kinds of things to get this right. If an incoming mail contains accents or other non-ascii things, they seem to show up as '?' or even blanks within mutt. This is most annoying. For instance if I look at a 'From' line in a mail that displays perfectly in Evolution mail (contains two different 'e' accents), it shows: From: =?iso-8859-1?Q?H=E9l=E8ne_Corthals?= [EMAIL PROTECTED] in 'less' on the terminal, and the same line in 'mutt' is displayed as: From: H?el?ne Corthals Again, I have tried to change char-sets in mutt and other settings that I thought might help, all to no avail. Any hints or suggestions are indeed much appreciated! -- Erik van der Meulen [EMAIL PROTECTED]
Re: Display of non-ascii chars
On Wed, Jul 31, 2002 at 01:46:24PM +0200, Roman Neuhauser wrote: looks like you have $LANG set to C, POSIX, or something like that. what happens if you just cat(1) the message (i. e. view it w/o any intervening program)? i'd guess it won't come up right either. Thanks a lot for your reply. You are right. It comes up just like in 'less' roman@freepuppy ~ 865:1 echo $LANG cs_CZ.ISO8859-2 Mine gives (as you had guessed) 'C' roman@freepuppy ~ 866:0 grep charset .mail/mutt/muttrc set charset = iso-8859-2 set send_charset = us-ascii:iso-8859-2:utf-8 I get just: charset=iso-8859-1 From this I deduce that my problem is in the $LANG. Any suggestion on how and where to change that? I am on a Debian 2.2 box. Thanks again! -- Erik van der Meulen [EMAIL PROTECTED]
Re: Display of non-ascii chars
Date: Wed, 31 Jul 2002 13:32:49 +0200 From: Erik van der Meulen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Display of non-ascii chars Dear all, I have some issue with the displaying of non-ascii chars in my mail. I have to admit that I am not 100% sure that this is a mutt-issue or more shell or terminal related. Sorry if it is off-topic, I have tried all kinds of things to get this right. this is both mutt and terminal issue If an incoming mail contains accents or other non-ascii things, they seem to show up as '?' or even blanks within mutt. This is most annoying. For instance if I look at a 'From' line in a mail that displays perfectly in Evolution mail (contains two different 'e' accents), it shows: From: =?iso-8859-1?Q?H=E9l=E8ne_Corthals?= [EMAIL PROTECTED] looks like you have $LANG set to C, POSIX, or something like that. what happens if you just cat(1) the message (i. e. view it w/o any intervening program)? i'd guess it won't come up right either. in 'less' on the terminal, and the same line in 'mutt' is displayed as: From: H?el?ne Corthals Again, I have tried to change char-sets in mutt and other settings that I thought might help, all to no avail. Any hints or suggestions are indeed much appreciated! roman@freepuppy ~ 865:1 echo $LANG cs_CZ.ISO8859-2 roman@freepuppy ~ 866:0 grep charset .mail/mutt/muttrc set charset = iso-8859-2 set send_charset = us-ascii:iso-8859-2:utf-8 -- FreeBSD 4.6-STABLE 1:41PM up 21:17, 9 users, load averages: 0.00, 0.00, 0.00
Re: muttprofile (new)
On Wed, Jul 31, 2002 at 12:30:52PM +0200, Rocco Rutte wrote: useful (preferebly perl) scripts dealing with .muttrc. Some alias conversion scripts, muttrc2html, maybe muttrcbuilder and the like. A script dealing with profiles would perfectly fit in my ideas. Interested? Anyone else interested in hacking some perl? i have some things to offer as well. i have a script that builds up gpg-enabled correspondants and sets up the appropriate send hooks for them. the pgp_reply* vars are fine for setting that stuff on replies, but not for new emails. in general though it would be nice to have a lot of these scripts distributed with mutt. and if need be for dependancies packagers could have mutt-perl, mutt-python, etc packages so that the main mutt package wouldn't depend on any interpreters (which seems to really piss people off for some moronic reason or another). i recently upgraded my system and i still need to go snarf down the stuff my word2text script needed; it would be nice if mutt had that with the package (or if it had a script that had wv as a dependancy to encourage linux distro makers to include it). kevin -- [EMAIL PROTECTED] that a believer is happier than a skeptic is no more to fork()'ed on 37058400the point than the fact that a drunken man is happier meatspace place: home than a sober one. the happiness of credulity is a http://ie.suberic.net/~kevin cheap dangerous quality -- g.b. shaw msg29983/pgp0.pgp Description: PGP signature
Re: Display of non-ascii chars
Date: Wed, 31 Jul 2002 13:58:48 +0200 From: Erik van der Meulen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Display of non-ascii chars On Wed, Jul 31, 2002 at 01:46:24PM +0200, Roman Neuhauser wrote: looks like you have $LANG set to C, POSIX, or something like that. what happens if you just cat(1) the message (i. e. view it w/o any intervening program)? i'd guess it won't come up right either. Thanks a lot for your reply. You are right. It comes up just like in 'less' ok, so it's your terminal (or rather, environment) that's not set up as you need. roman@freepuppy ~ 865:1 echo $LANG cs_CZ.ISO8859-2 Mine gives (as you had guessed) 'C' From this I deduce that my problem is in the $LANG. yes Any suggestion on how and where to change that? I am on a Debian 2.2 box. you can fix it by % setenv LANG en_US.ISO8859-1 or % export LANG=en_US.ISO8859-1 depending on the type of shell you use. permanent fix lies in your shell's start up files. export $LANG with appropriate value from there. -- FreeBSD 4.6-STABLE 2:12PM up 21:48, 9 users, load averages: 0.03, 0.05, 0.01
Re: Display of non-ascii chars
On Wed, Jul 31, 2002 at 02:16:09PM +0200, Roman Neuhauser wrote: % setenv LANG en_US.ISO8859-1 or % export LANG=en_US.ISO8859-1 depending on the type of shell you use. permanent fix lies in your shell's start up files. export $LANG with appropriate value from there. Thanks a mil! I have added this to my .bash_profile and it seems to work just fine! (and since we are performing magic here anyway, you wouldn't happen to know of a way to COMPOSE such characters, rather than just reading them?) Much obliged. -- Erik van der Meulen [EMAIL PROTECTED]
Packaging mutt script, was: muttprofile (new)
Hello, in the .muttprofile(new) Kevin said: in general though it would be nice to have a lot of these scripts distributed with mutt. and if need be for dependancies packagers could have mutt-perl, mutt-python, etc packages so that the main mutt package wouldn't depend on any interpreters (which seems to really piss people off for some moronic reason or another). Both personally, and as leader of the RULE project (see below) I would really appreciate something like this, i.e. one package, to be eventually delivered as .rpm, .deb, .tgz, whatever, that collects *all* these things. The problem with mutt is that it is indeed the most powerful MUA available, but this depends quite strongly from having already discovered and set up all the utilities mentioned here today and on the main mutt sites. A package like this would not certainly spare from RTFM, but would save a lot of time, and make the transition from pompous mailers much faster and easier! Myself, I volunteer to test/maintain the RPM version for RULE! Ciao, Marco Fioretti Red Hat 7.3 for low memory: www.rule-projects.org/
Re: muttprofile (new)
On Wed, Jul 31, 2002 at 12:30:52PM +0200, Rocco Rutte wrote: useful (preferebly perl) scripts dealing with .muttrc. Some alias conversion scripts, muttrc2html, maybe muttrcbuilder and the like. A script dealing with profiles would perfectly fit in my ideas. Interested? Anyone else interested in hacking some perl? i have some things to offer as well. i have a script that builds up gpg-enabled correspondants and sets up the appropriate send hooks for them. the pgp_reply* vars are fine for setting that stuff on replies, but not for new emails. in general though it would be nice to have a lot of these scripts distributed with mutt. and if need be for dependancies packagers could have mutt-perl, mutt-python, etc packages so that the main mutt package wouldn't depend on any interpreters (which seems to really piss people off for some moronic reason or another). i recently upgraded my system and i still need to go snarf down the stuff my word2text script needed; it would be nice if mutt had that with the package (or if it had a script that had wv as a dependancy to encourage linux distro makers to include it). kevin -- [EMAIL PROTECTED] that a believer is happier than a skeptic is no more to fork()'ed on 37058400the point than the fact that a drunken man is happier meatspace place: home than a sober one. the happiness of credulity is a http://ie.suberic.net/~kevin cheap dangerous quality -- g.b. shaw msg29987/pgp0.pgp Description: PGP signature
Re: utilities - extra archive
* kevin lyda [EMAIL PROTECTED] [2002-07-31 12:08]: On Wed, Jul 31, 2002 at 12:30:52PM +0200, Rocco Rutte wrote: useful (preferebly perl) scripts dealing with .muttrc. Some alias conversion scripts, muttrc2html, maybe muttrcbuilder and the like. A script dealing with profiles would perfectly fit in my ideas. Interested? Anyone else interested in hacking some perl? i have some things to offer as well. i have a script that builds up gpg-enabled correspondants and sets up the appropriate send hooks for them. the pgp_reply* vars are fine for setting that stuff on replies, but not for new emails. in general though it would be nice to have a lot of these scripts distributed with mutt. well, from my experience with vim it is better to distribute utilities in an extra archive, something like mutt-contrib-yymmdd.tar.gz. and if need be for dependancies packagers could have mutt-perl, mutt-python, etc packages so that the main mutt package wouldn't depend on any interpreters (which seems to really piss people off for some moronic reason or another). you'll understand when your system can have only a small hard disk. ;-) i recently upgraded my system and i still need to go snarf down the stuff my word2text script needed; it would be nice if mutt had that with the package (or if it had a script that had wv as a dependancy to encourage linux distro makers to include it). i'd rather not bundle mutt with all utilities. after all, many people might not have a need for these at all. what's needed is better documentation with hint for download, installation, configuration, setup examples and links to webpages. Sven [using antiword rather than word2text] -- ANTIWORD 0.33 [2002-07-05] - Full support for documents from WinWord 2.0 - Some support for documents from Word-for-DOS and WinWord 1.x http://www.antiword.org/ - http://www.winfield.demon.nl/
Re: problem about subjects in asian charsets
Hi Erik, On Wednesday, July 31, 2002 at 7:26:25 PM +1000, Erik Christiansen wrote: 100 N + Jul 19 Erik Christians ( 4) Forbl?ffende Ul?selig V?s Subject: Forbl\370ffende Ul\346selig V\345s Would whatever helped Isaac also fix this one? No: completely different problem. Your's is even not a Mutt problem, just bad system's locale configuration. Try to set LC_CTYPE to a suitable locale for your language, country and character set. Bye!Alain.
Re: basic shell funtionality?
* Lukas Schroeder [EMAIL PROTECTED] [2002-07-31 09:23]: what i have in mind is functionality similar to vim's :cd and :pwd commands. that would make my day(s)... this is not yet implemented, is it? no. you can add this to your list of wishes.. Sven
Re: Pipe:ing messages - behavior changed?
* Peter Schuller [EMAIL PROTECTED] [2002-07-30 17:52]: Since upgrading mutt to the latest version the | command seems to only pipe what's on screen, not the entire raw message. Is this the intended behavior or is it a bug? Is it possible for me as a user to override it? the on screen text results from the display_filter and what is weeded by the (un)ignore commands and whether you are showing the full header or not. (using display-toggle-weed) so check the values for display_filter and weed, all your (un)ignore commands and the current status of display-toggle-weed. have fun. ;-) Sven
Re: Display of non-ascii chars
Thanks a mil! I have added this to my .bash_profile and it seems to work just fine! (and since we are performing magic here anyway, you wouldn't happen to know of a way to COMPOSE such characters, rather than just reading them?) If you use the vim editor for composing messages, then you can set up digraphs to enter non-ASCII characters; it also supports a completely general but more awkward input method where you can type control-V followed by the decimal character code of the character you want, or the letter 'u' followed by the hexadecimal Unicode code point. Any more general solution for use outside of your editor depends even more on the environment in which you are running mutt. If you're running it in an X terminal program on the console of the Unix box, for instance, you can set up an XIM (X Input Manager) server, or manually remap certain key combinations via the xmodmap program. If you're connecting from a terminal program on a Windows box, then you can usually install international virtual keyboard layouts and switch between them with hotkeys or a system tray icon. There's also the vim-like solution of holding down the Alt key and typing a decimal character code on the numeric keypad (although that only works for 8-bit values, not Unicode code points); and of course you can always paste from the Character Map system accessory. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754 -- Steele's Plagiarism of Somebody's Philosophy: Everybody should believe in something -- and I believe I'll have another drink.
Re: option decsription - always give default value
* Vincent Lefevre [EMAIL PROTECTED] [2002-07-30 13:30]: On Tue, Jul 30, 2002 at 14:40:00 +0200, Sven Guckes wrote: a better way is that of vim which includes the info that the option/variable is only available when some code is in binary as indicated by +feature in the outut of the :version command. Yes, we should have something like that in Mutt. anyone? And when it depends on the configuration, the default value shouldn't be given, as it may be wrong (this would confuse the user). it? anyway.. the default value should *always* be documented. whether or not the code for the option is in the mutt binary is another matter altogether. besides - will mutt adopt option shortnames like vim? example: df for display_filter let me give an example: Name: display_filter (short name: df) Type: boolean, quadoption, number, path, regex, string; email address, folder magic, sort order. Default: (well, the default is empty for this option) Requires: --configure-long-option-name Description: blah blah blah.. Example: set display_filter=/bin/sed -f $HOME/.mutt/display_filter.default.sed Note: Full pathname to filter program is required. The shell magic '~' for $HOME is *not* evaluated, but you can use $HOME instead. additions, corrections, ideas? Sven
Re: FYI: MIME RFC's - spruce.sf.net/gmime ?
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2002-07-31 06:41]: This link is to 'gmime'. link? what link? The site starts off with a list of MIME RFC's that the program deals with. http://spruce.sourceforge.net/gmime/ ? I have no idea if these are all the important or necesssary ones, but the list will certainly give you an idea for what's involved in making a good email client these days. someone should tell the folks who program LotusNotes and OutlookExpress -- but i guess it's too late for that now. ;-) A few of us were talking about 'mutt' and RFC's a few meetings back, so I thought I'd pass it along. ;-) Sven
Re: option decsription - always give default value
On Wed, Jul 31, 2002 at 16:34:18 +0200, Sven Guckes wrote: * Vincent Lefevre [EMAIL PROTECTED] [2002-07-30 13:30]: And when it depends on the configuration, the default value shouldn't be given, as it may be wrong (this would confuse the user). it? the default value. If the default value given by the manual is not the same as the real default value used by Mutt, it is very confusing. anyway.. the default value should *always* be documented. What do you mean by documented? -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
RFE: regex backrefs
I know this has been brought up before, but I just thought I'd voice my deep desire: mutt should be able to have backrefs to its regexen. If I get a 'vote' in future development, this is how I would cast it. My C is crappy, or I'd shut up and code it. Imagine the power available in something as simple as: folder-hook =friends\.([a-z]+) my_hdr From: jsmith-\[EMAIL PROTECTED] This is only a tiny fraction of the Supreme Cosmic Power that this could unlock. -- rjbs msg29996/pgp0.pgp Description: PGP signature
Re: RFE: regex backrefs
On Wed, Jul 31, 2002 at 05:08:25PM +0200, Roman Neuhauser wrote: my deep desire: mutt should be able to have backrefs to its regexen. this reminds me: how hard would it be to make mutt use libpcre? And, how much would it slow down / bloat up mutt, if at all? -- rjbs msg29997/pgp0.pgp Description: PGP signature
Re: RFE: regex backrefs
Date: Wed, 31 Jul 2002 10:57:39 -0400 From: Ricardo SIGNES [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RFE: regex backrefs I know this has been brought up before, but I just thought I'd voice my deep desire: mutt should be able to have backrefs to its regexen. If I get a 'vote' in future development, this is how I would cast it. My C is crappy, or I'd shut up and code it. Imagine the power available in something as simple as: folder-hook =friends\.([a-z]+)my_hdr From: jsmith-\[EMAIL PROTECTED] This is only a tiny fraction of the Supreme Cosmic Power that this could unlock. this reminds me: how hard would it be to make mutt use libpcre? -- FreeBSD 4.6-STABLE 5:07PM up 1 day, 43 mins, 4 users, load averages: 0.04, 0.04, 0.01
Re: RFE: regex backrefs
* Ricardo SIGNES ([EMAIL PROTECTED]) [01 Aug 2002 01:21]: On Wed, Jul 31, 2002 at 05:08:25PM +0200, Roman Neuhauser wrote: this reminds me: how hard would it be to make mutt use libpcre? And, how much would it slow down / bloat up mutt, if at all? Strictly speaking, if used as a shared library, and existing regexp support is blown away and replaced, then it reduces bloat. The problem is, such a change would probably kill everyone's existing configurations. You'd need something like Vim's \m, \M, \v, \V escapes (magic, no magic, very magic, very no magic), only probably \P (use PCRE; assuming \P isn't taken by PCRE). cheers, -- Iain 'Spoon' Truskett. http://eh.org/~koschei/
Re: RFE: regex backrefs
Date: Thu, 1 Aug 2002 01:25:27 +1000 From: Iain Truskett [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: RFE: regex backrefs * Ricardo SIGNES ([EMAIL PROTECTED]) [01 Aug 2002 01:21]: On Wed, Jul 31, 2002 at 05:08:25PM +0200, Roman Neuhauser wrote: this reminds me: how hard would it be to make mutt use libpcre? And, how much would it slow down / bloat up mutt, if at all? Strictly speaking, if used as a shared library, and existing regexp support is blown away and replaced, then it reduces bloat. The problem is, such a change would probably kill everyone's existing configurations. You'd need something like Vim's \m, \M, \v, \V escapes (magic, no magic, very magic, very no magic), only probably \P (use PCRE; assuming \P isn't taken by PCRE). while i very much appreciate the fact that i can use 1.5 with .muttrc created for 1.2.5i (i think only noted one or two non-bugfix changes between 1.2.5i and 1.5.1i), such changes are what major version number bumps are for. btw, vim's regex support is completely b0rken IMO. its (no) magic switches... weird syntax... ugh. if PCRE was adopted, and used as the only regex library in the next major mutt version, such an escape wouldn't be needed. anyway, PCRE is quite ubiquitous (apache 2, postfix, python, php...), and a de facto standard. standards are god. -- FreeBSD 4.6-STABLE 5:40PM up 1 day, 1:17, 7 users, load averages: 0.00, 0.00, 0.00
Re: RFE: regex backrefs
On Wed, Jul 31, 2002 at 05:54:42PM +0200, Roman Neuhauser wrote: btw, vim's regex support is completely b0rken IMO. its (no) magic switches... weird syntax... ugh. Given that vim's regexes are based on vi's which are based on ed's, and ed was the first UNIX program to *have* regexes, it's hardly fair to call its regex support broken. It just has to be backward-compatible with a regex flavor that has been superceded, so it uses special escapes. It's the same reason that modern grep programs, which have features formerly found only in egrep, use \+ instead of +, \| instead of |, etc. Meanwhile, the 'magic' stuff was orignally put in vi to make the more common cases easier for new users, but it has been expanded in vim to the point where you can set it up to have a fairly modern regex syntax (with fewer backslashes, etc). Vim may not have modern innovations from Perl 5 like non-capturing grouping, lookaround, etc., but it's hardly broken. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754 -- Photographing a volcano is just about the most miserable thing you can do. -- Robert B. Goodman [Who has clearly never tried to use a PDP-10. Ed.]
Re: option description - always give default value
* Vincent Lefevre [EMAIL PROTECTED] [2002-07-31 15:14]: If the default value given by the manual is not the same as the real default value used by Mutt, it is very confusing. errr... that's self-evident, isn't it? the default value should *always* be documented. What do you mean by documented? the manual to muttrc should show it. somehow i think i've been pointing out the bleeding obvious. or is there something i'm missing here? are there any options without a default? (i hope not) are there any options with different defaults according to configure options being used? if so then this should be documented, too. Sven
mutt + procmail + nfs...
ok, i have a mail server that also exports out /home. it has several raid disks is connected to an ups and is generally noisy so it lives in my utility room. my workstation lives in my office and it mounts /home from the mail server. sendmail invokes procmail to deliver my mail on the mail server. i'm thinking of having procmail deliver directly to ~/Mail/inbox. that way i could run mutt on my workstation. however, this is the dreaded mailbox on nfs issue. do procmail and mutt play nice on nfs? kevin -- [EMAIL PROTECTED] that a believer is happier than a skeptic is no more to fork()'ed on 37058400the point than the fact that a drunken man is happier meatspace place: home than a sober one. the happiness of credulity is a http://ie.suberic.net/~kevin cheap dangerous quality -- g.b. shaw msg30003/pgp0.pgp Description: PGP signature
Re: mutt + procmail + nfs...
On Wed, Jul 31, 2002 at 05:45:32PM +0100, kevin lyda wrote: ok, i have a mail server that also exports out /home. it has several raid disks is connected to an ups and is generally noisy so it lives in my utility room. my workstation lives in my office and it mounts /home from the mail server. sendmail invokes procmail to deliver my mail on the mail server. i'm thinking of having procmail deliver directly to ~/Mail/inbox. that way i could run mutt on my workstation. however, this is the dreaded mailbox on nfs issue. do procmail and mutt play nice on nfs? If you use Maildir, yes. -- Ralf Hildebrandt (Im Auftrag des Referat V A) [EMAIL PROTECTED] Charite Campus Virchow-Klinikum Tel. +49 (0)30-450 570-155 Referat V A - Kommunikationsnetze - Fax. +49 (0)30-450 570-916 This is the first age that's paid much attention to the future, which is a little ironic since we may not have one. -- Arthur Clarke
Re: mutt + procmail + nfs...
* kevin lyda [EMAIL PROTECTED] [2002-07-31 12:44]: however, this is the dreaded mailbox on nfs issue. do procmail and mutt play nice on nfs? Mutt and procmail both support Maildir natively. See http://cr.yp.to/proto/maildir.html. (darren) -- Patriotism is the last resource of scoundrels. -- Samuel Johnson
Re: RFE: regex backrefs
* On 2002.07.31, in [EMAIL PROTECTED], * Roman Neuhauser [EMAIL PROTECTED] wrote: Strictly speaking, if used as a shared library, and existing regexp support is blown away and replaced, then it reduces bloat. Not necessarily. I'm not already using pcre, so it still bloats my system to load it whether it's dynamic or static. That's without getting into whether I'd *want* to compile with shared libraries, since I'm on Solaris (where you're bludgeoned into using shared libraries whether you want to or not). Anyway, my point is that this is probably beside the point. :) The problem is, such a change would probably kill everyone's existing configurations. You'd need something like Vim's \m, \M, \v, \V escapes (magic, no magic, very magic, very no magic), only probably \P (use PCRE; assuming \P isn't taken by PCRE). It seems that it should be a relatively simple matter to use pcre instead of the usual regex library on the basis of --with-pcre or somesuch -- that is, it doesn't need to be made the default in order to enable it. If I cared for Perl regexes, I might try to do that... but I like extended regular expressions just fine. However, if someone else wants to try it, it feels like it should work. -- -D.Fresh fruit enriches everyone. Takes the thirst Sun Project, APC/UCCO out of everyday time. A pure whiff of oxygen, University of Chicago painting over a monochrome world in primary colors. [EMAIL PROTECTED] We all know that. It's why everyone loves fruit.
Re: RFE: regex backrefs
Oops, I meant to reply to Roman's text, too, but my delete finger was hyperactive. * On 2002.07.31, in [EMAIL PROTECTED], * Roman Neuhauser [EMAIL PROTECTED] wrote: btw, vim's regex support is completely b0rken IMO. its (no) magic switches... weird syntax... ugh. What Mark said. if PCRE was adopted, and used as the only regex library in the next major mutt version, such an escape wouldn't be needed. anyway, PCRE is quite ubiquitous (apache 2, postfix, python, php...), and a de facto standard. standards are god. I don't think it's any kind of standard, just a somewhat widely-available option. I've never used it, for example -- not overtly, not unless it was sneakily included in the distribution of some software I compiled. Mutt has long tried hard not to require extra stuff to compile. Requiring a functional iconv (meaning installing libiconv if you're not on a complaint system) is a reasonable compromise, given Mutt's design goals. Likewise, you might need ncurses or slang if your native curses are sufficiently broken. But in general, mutt does not require extra software (not even gmake) to be installed before you can compile and/or run it, and that's very, very good. -- -D.Fresh fruit enriches everyone. Takes the thirst Sun Project, APC/UCCO out of everyday time. A pure whiff of oxygen, University of Chicago painting over a monochrome world in primary colors. [EMAIL PROTECTED] We all know that. It's why everyone loves fruit.
Re: option description - always give default value
On Wed, Jul 31, 2002 at 18:26:40 +0200, Sven Guckes wrote: * Vincent Lefevre [EMAIL PROTECTED] [2002-07-31 15:14]: the default value should *always* be documented. What do you mean by documented? the manual to muttrc should show it. OK, so what happens if two Mutt binaries use different default values? are there any options with different defaults according to configure options being used? The default value of dotlock_program depends on the configuration options. if so then this should be documented, too. Yes, and my point was: for these options, the default value shouldn't be written in the manual, because it may be incorrect. The user should get the actual value with :set xxx=[TAB]. And of course, this should be documented. Moreover, if mutt -v could give a hint, this would be useful. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Re: mutt + procmail + nfs...
On Wed, Jul 31, 2002 at 06:46:55PM +0200, Ralf Hildebrandt wrote: however, this is the dreaded mailbox on nfs issue. do procmail and mutt play nice on nfs? If you use Maildir, yes. Maildir has the problem of trading NFS locks for excess synchronous meta-data operations, and synchronous meta-data operations are something not dealt with well by most NFS servers (at least, anything short of Auspex, EMC, or NetApp). There are alternative solutions. For POP3-based systems, Nick Christenson led the way in his Earthlink paper, _A Highly Scalable Electronic Mail Service Using Open Systems_, which you can find at http://www.jetcafe.org/~npc/doc/mail_arch.html. IIRC, they used file creation tricks (just like Maildir does), but instead of breaking out each message into a separate file, they used the v7 mbox file format. You still have some synchronous meta-data issues to deal with, but not nearly on the scale of Maildir, and even those can be at least partially addressed (start with http://www.shub-internet.org/brad/papers/dihses/lisa2000/sld065.htm of my invited talk _The Design and Implementation of Highly Scalable E-mail Systems_, which I presented at LISA 2000). For IMAP-based systems, you would need to use the message store engine from MessagingDirect (they hacked Cyrus so as to pull the locking out of the filesystem and into an NFS-friendly database). Alternatively, you would need to hack Cyrus to pull the file locking out into an NFS-friendly database. You may also be interested to read the book _Sendmail Performance Tuning_ by Nick Christenson -- to be published on September 20, I believe. While the title of the book is about sendmail, I believe that it covers more than just this one program. Disclosure: I was a technical reviewer of this book and Nick was my co-author for the talk I gave at LISA 2000, so I may be a bit biased. ;-) -- Brad Knowles [EMAIL PROTECTED] Senior Consultant for Snow bv ASM Lithography bv + ITMS Unix Competence Center + Room 02.D.2085 De Run 1110 + 5503 LA Veldhoven, NL + GSM +31 654 344 596
Re: option description - default and dependencies
* Vincent Lefevre [EMAIL PROTECTED] [2002-07-31 17:16]: the default value should *always* be documented. What do you mean by documented? the manual to muttrc should show it. OK, so what happens if two Mutt binaries use different default values? different things? ;-) are there any options with different defaults according to configure options being used? The default value of dotlock_program depends on the configuration options. ah, ok, good example! if so then this should be documented, too. Yes, and my point was: for these options, the default value shouldn't be written in the manual, because it may be incorrect. but it still does not help issuing different versions of the manual as getting the correct manual then both depends on $PATH and $MANPATH. and these usually do not fit well together, do they? so the solution is: extend the manual with more information! eg Default: /path/file (unless specified by --some-option) The user should get the actual value with :set xxx=[TAB]. And of course, this should be documented. Moreover, if mutt -v could give a hint, this would be useful. absolutely! in the above case both mutt -v|grep = and :set ?dotlock_program should show its value. and I'd be happy to see some ordering in the version info: DOTLOCKPROG=/path/file EXECSHELL=/bin/sh ISPELL=/import/gnu/bin/ispell MAILPATH=/var/mail SENDMAIL=/var/qmail/bin/sendmail PKGDATADIR=/import/local/share/mutt SYSCONFDIR=/import/local/etc whenever I see the options list I think it *should* be sorted: Compile options: -DOMAIN -DEBUG -HOMESPOOL -USE_SETGID +USE_DOTLOCK -DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP -USE_GSS +USE_SSL -USE_SASL +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +HAVE_PGP +BUFFY_SIZE -EXACT_ADDRESS +SUN_ATTACHMENT +ENABLE_NLS +LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_GETSID +HAVE_GETADDRINFO having to search through this list simply is unbearable. bah![tm] Sven
Re: FYI: MIME RFC's
On Tue, Jul 30, 2002 at 11:41:01PM -0700, [EMAIL PROTECTED] wrote: This link is to 'gmime'. The site starts off with a list of MIME RFC's that the program deals with. I have no idea if these are all the important or necesssary ones, but the list will certainly give you an idea for what's involved in making a good email client these days. A few of us were talking about 'mutt' and RFC's a few meetings back, so I thought I'd pass it along. A couple of big oops... Here's the link (Thanks to Sven for pointing it out): http://spruce.sourceforge.net/gmime/ And I actually meant to send this message 'lilax', my LUG, of which Michael Elkins (one of the mutt authors) is a member, though it works here, too. My apologies for the screw up. - Martin - -- - Martin J. Brown, Jr. - - [EMAIL PROTECTED] - Public PGP Key ID: 0xDB184F7B keyserver: http://certserver.pgp.com/ msg30011/pgp0.pgp Description: PGP signature
where to specify html viewer
When I installed the latest version of mutt, it changed or lost how to view html messages (lynx), and now returns this error: h: lynx-dump: command not found I've looked through the main mutt config and doc's, but can't see where/how to set this to 'lynx', I have no 'lynx-dump' that I can see. How can I fix this ? Thank you. - Martin - -- - Martin J. Brown, Jr. - - [EMAIL PROTECTED] - Public PGP Key ID: 0xDB184F7B keyserver: http://certserver.pgp.com/ msg30012/pgp0.pgp Description: PGP signature
Re: where to specify html viewer
On Wed, Jul 31, 2002 at 02:42:10PM -0400, [EMAIL PROTECTED] wrote: When I installed the latest version of mutt, it changed or lost how to view html messages (lynx), and now returns this error: h: lynx-dump: command not found Look in ~/.mailcap. It appears that you're set up to try to run a command called lynx-dump instead of lynx -dump (note the space) - that is, the lynx command with the -dump option. Which will just show you the raw HTML, by the way, and may not be what you actually want anyway. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754 -- Windows 98 is guaranteed to make your system 98% slower.
Re: where to specify html viewer
On Wed, Jul 31, 2002 at 11:42:10AM -0700, [EMAIL PROTECTED] wrote: When I installed the latest version of mutt, it changed or lost how to view html messages (lynx), and now returns this error: h: lynx-dump: command not found I've looked through the main mutt config and doc's, but can't see where/how to set this to 'lynx', I have no 'lynx-dump' that I can see. looks to me like you are missing a space. i.e. lynx-dump should be lynx -dump. How can I fix this ? check your ~/.mailcap. -- Peter Abplanalp Email: [EMAIL PROTECTED] PGP: pgp.mit.edu msg30014/pgp0.pgp Description: PGP signature
Re: utilities - extra archive
On Wed, Jul 31, 2002 16:00:47 at 04:00:47PM +0200, Sven Guckes wrote: i'd rather not bundle mutt with all utilities. after all, many people might not have a need for these at all. I agreee 100% on this. A mutt-utils.rpm would be extremely useful for newbies (as I mentioned in my other message), but would only bother the expert that already know such add-ons. The two packages have to remain separate, to avoid bloat. what's needed is better documentation with hint for download, installation, configuration, setup examples and links to webpages. Yes, but as a complement. The utils package would contain stuff that has been proved to work with the corresponding version of mutt, and example config files as well. The two things don't overlap. Ciao, Marco Fioretti Red Hat 7.3 in 8 MB of RAM: www.rule-project.org/ -- We need to focus on how to be productive, not just active. Scott McNealy, chairman, CEO, and cofounders, Sun Microsystems.
Re: basic shell funtionality?
Lukas Schroeder wrote: On Wed, Jul 31, 2002 at 11:12:11AM +0200, Rocco Rutte wrote: * Lukas Schroeder [02-07-30 23:37:57 +0200] wrote: does mutt have some basic shell functionality built in? i'd like to 'cd' and 'pwd', so that i can conveniently store attachments where i want them - especially when i I've made a short patch adding a variable ``attach_dir'' which is the default location to save attachements to. If it is empty, mutt uses the current directory; if not the specified is prepended so that you can already see at the prompt where your files will end up. but i have to save all attachments into that single directory? that's basically what i excercise now: save to ~/tmp and move the files later, to where they should've gone in the first place... But you can specify a path name relative to your home directory. By default, mutt suggests a file name in your home directory which you can prepend with the desired relative path. what i have in mind is functionality similar to vim's :cd and :pwd commands. that would make my day(s)... this is not yet implemented, is it? That wouldn't even require a new command. IMHO it would be enough to simply let mutt remember the target directory of the last save operation. For example, if I have numerous attachments of some sort of data, all to be saved into the same directory data, I would specify data/file1.dat as output path name, and in the next save operation mutt would suggest data/file2.dat, i.e. remember that the last attachment was written to directory data. There would be no need to save that information to a file as it would be sufficient to remember it during one mutt session, though it would be nice to set a default directory as with the attach_dir patch. Cheers, Joachim
Re: Packaging mutt script, was: muttprofile (new)
At 2:27 PM +0200 2002/07/31, Marco Fioretti wrote: Both personally, and as leader of the RULE project (see below) I would really appreciate something like this, i.e. one package, to be eventually delivered as .rpm, .deb, .tgz, whatever, that collects *all* these things. You're welcome to take on that task for whatever OSes projects you see fit, but I don't think that it's fair to ask the mutt maintainers to do this for every OS under the sun. No, the original mutt tarball should stick to only code that is specific to mutt, and if it requires or can make use of anything else, that should be made clear in the documentation and in the configure script. Myself, I volunteer to test/maintain the RPM version for RULE! That's wonderful! Thank you. Anyone else? -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: Pipe:ing messages - behavior changed?
Hello Peter, On Tuesday, July 30, 2002 at 8:52:18 PM +0200, Peter Schuller wrote: the | command seems to only pipe what's on screen, not the entire raw message. unset pipe_decode Bye!Alain short Bench.
Re: RFE: regex backrefs
* Mark J. Reed ([EMAIL PROTECTED]) [01 Aug 2002 02:05]: [...] Vim may not have modern innovations from Perl 5 like non-capturing grouping, lookaround, etc., but it's hardly broken. Actually, vim has non-capturing grouping and look-ahead/behind. And with the various magic escapes, you can have it compatible with vi, or you can have it feel rather natural. I'll definitely agree it's not broken, and would say it's more powerful than a lot of other flavours of regex. Plus it has the features an editor needs (matching columns, matching as much of, etc.). I'm not sure mutt needs such features, mind you. The only extension I've needed to mutt's matching facilities was an extension to the patterns (matching a folder). I find the regexs fine. cheers, -- Iain 'Spoon' Truskett. http://eh.org/~koschei/
Re: RFE: regex backrefs
Ricardo SIGNES wrote: I know this has been brought up before, but I just thought I'd voice my deep desire: mutt should be able to have backrefs to its regexen. If I get a 'vote' in future development, this is how I would cast it. My C is crappy, or I'd shut up and code it. Imagine the power available in something as simple as: folder-hook =friends\.([a-z]+)my_hdr From: jsmith-\[EMAIL PROTECTED] While this might look simple, it's more difficult to implement than you might think. Why? Becuse the regexp here is not just one regular expression. The =friends\.([a-z]+) is actually expanded with the $default_hook variable, which by default is ~f %s !~P | ~P ~C %s, thus translating your example above into ~f =friends\.([a-z]+) !~P | ~P ~C =friends\.([a-z]+) So now what does \1 really refer to? It gets even worse when you have multiple *different* regular expressions in complex patterns. It's not that the Mutt developers don't think would be useful to do, its just a bear of a problem to tackle. At any rate, your example above can be solved as follows: 1) create a script which generats folder-hook commands for all of your `friend' mailboxes: #!/bin/sh for i in ~/Mail/friends.*; do echo folder-hook $i my_hdr From: jsmith-`echo $i|sed 's;^.*\.;;'`@friends.domain.org; done 2) source this script from your ~/.muttrc source ~/bin/hookgen.sh|
Re: option description - default and dependencies
* Vincent Lefevre [EMAIL PROTECTED] [2002-07-31 21:03]: so the solution is: extend the manual with more information! eg Default: /path/file (unless specified by --some-option) The user doesn't necessarily know what options have been used, so this is a bad idea to say that. i disagree. the manual should include a section which tells the user how to check for such information. the users who are not capable of finding, reading, or understanding this section should not be using this program in the first place. Sven [not sure whether to add a smiley]
Re: option description - default and dependencies
On Thu, Aug 01, 2002 at 02:09:18 +0200, Sven Guckes wrote: * Vincent Lefevre [EMAIL PROTECTED] [2002-07-31 21:03]: so the solution is: extend the manual with more information! eg Default: /path/file (unless specified by --some-option) The user doesn't necessarily know what options have been used, so this is a bad idea to say that. i disagree. the manual should include a section which tells the user how to check for such information. And how can one find the options used to compile Mutt? -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Re: option description - default and dependencies
* Vincent Lefevre [EMAIL PROTECTED] [07-31-02 21:04]: On Thu, Aug 01, 2002 at 02:09:18 +0200, Sven Guckes wrote: * Vincent Lefevre [EMAIL PROTECTED] [2002-07-31 21:03]: so the solution is: extend the manual with more information! eg Default: /path/file (unless specified by --some-option) The user doesn't necessarily know what options have been used, so this is a bad idea to say that. i disagree. the manual should include a section which tells the user how to check for such information. And how can one find the options used to compile Mutt? Guess you should read the informational files included in the tarball/rpm. They are detailed in the INSTALL file of every mutt version I have ever seen. If you are informed enought to question Sven about the SUBJECT, you should be intelligent enought about file distributions to know this. -- Patrick Shanahan Registered Linux User #207535 @ http://counter.li.org
Re: option description - default and dependencies
On Wed, Jul 31, 2002 at 21:14:18 -0500, Patrick wrote: * Vincent Lefevre [EMAIL PROTECTED] [07-31-02 21:04]: On Thu, Aug 01, 2002 at 02:09:18 +0200, Sven Guckes wrote: * Vincent Lefevre [EMAIL PROTECTED] [2002-07-31 21:03]: so the solution is: extend the manual with more information! eg Default: /path/file (unless specified by --some-option) The user doesn't necessarily know what options have been used, so this is a bad idea to say that. i disagree. the manual should include a section which tells the user how to check for such information. And how can one find the options used to compile Mutt? Guess you should read the informational files included in the tarball/rpm. They are detailed in the INSTALL file of every mutt version I have ever seen. You are not answering my question. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Re: option description - default and dependencies
* Vincent Lefevre ([EMAIL PROTECTED]) [01 Aug 2002 11:56]: [..] And how can one find the options used to compile Mutt? mutt -v cheers, -- Iain, who still finds it odd seeing you in non-Acorn contexts.
Re: option description - default and dependencies
* Vincent Lefevre [EMAIL PROTECTED] [07-31-02 21:25]: On Wed, Jul 31, 2002 at 21:14:18 -0500, Patrick wrote: * Vincent Lefevre [EMAIL PROTECTED] [07-31-02 21:04]: On Thu, Aug 01, 2002 at 02:09:18 +0200, Sven Guckes wrote: * Vincent Lefevre [EMAIL PROTECTED] [2002-07-31 21:03]: so the solution is: extend the manual with more information! eg Default: /path/file (unless specified by --some-option) The user doesn't necessarily know what options have been used, so this is a bad idea to say that. i disagree. the manual should include a section which tells the user how to check for such information. And how can one find the options used to compile Mutt? Guess you should read the informational files included in the tarball/rpm. They are detailed in the INSTALL file of every mutt version I have ever seen. You are not answering my question. You are not reading the post. Paragraph above says: They are detailed in the INSTALL file of every mutt version I have ever seen (tarball/rpm). Partial quote from 1.4i: In most cases, configure will automatically determine everything it needs to know in order to compile. However, there are a few options to `configure'' to help it out, or change the default behavior: --prefix=DIR install Mutt in DIR instead of /usr/local --with-curses=DIR use the curses lib in DIR/lib. If you have ncurses, `configure'' will automatically look in /usr/include/ncurses for the include files. --with-slang[=DIR] use the S-Lang library instead of ncurses. This library seems to work better for some people because it is less picky about proper termcap entries than ncurses. It is recommended that you use at *least* version 0.99-38 with Mutt. If you need to know more of the config options, you will need to read the file yourself. Help yourself, it's good to be inquisitive. hagd, -- Patrick Shanahan Registered Linux User #207535 @ http://counter.li.org
Re: option description - default and dependencies
On Thu, Aug 01, 2002 at 12:25:01 +1000, Iain Truskett wrote: * Vincent Lefevre ([EMAIL PROTECTED]) [01 Aug 2002 11:56]: [..] And how can one find the options used to compile Mutt? mutt -v No, it gives partial information. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Re: option description - default and dependencies
On Wed, Jul 31, 2002 at 21:49:21 -0500, Patrick wrote: Quote from and earlier post by you answering Sven Guckes: whenever I see the options list I think it *should* be sorted: Compile options: -DOMAIN -DEBUG -HOMESPOOL -USE_SETGID +USE_DOTLOCK -DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP -USE_GSS +USE_SSL -USE_SASL +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +HAVE_PGP +BUFFY_SIZE -EXACT_ADDRESS +SUN_ATTACHMENT +ENABLE_NLS +LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_GETSID +HAVE_GETADDRINFO This is only partial information. In particular, it doesn't give default values that may depend on the configuration. They could be added though, but in this case, I don't see why one would give a possibly incorrect value in the manual. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Re: Packaging mutt script, was: muttprofile (new)
On Wed, Jul 31, 2002 23:19:14 at 11:19:14PM +0200, Brad Knowles wrote: You're welcome to take on that task for whatever OSes projects you see fit, but I don't think that it's fair to ask the mutt maintainers to do this for every OS under the sun. No, the original mutt tarball should stick to only code that is specific to mutt, and if it requires or can make use of anything else, that should be made clear in the documentation and in the configure script. Brad, I agree, the utils must remain separate (for that matter, several of them are not even mutt specific...). See what I answered yesterday to Sven in the message Re: utilities - extra archive. In general, I believe in many small packages, not big monolithic things. Note about every OS under the sun. 80% of the utilities we probably want to include are shell or Perl script: the difference between versions for RH versus Debian versus *BSD versus Solaris . should really be quite manageable in this case, shouldn't they. And, in any case, a burden for the maintainers of this *separate* package, not for those of mutt. What about a home page? Is something like this worth a sourceforge URL? If not, I can set up some temp space on the RULE site (where I would eventually talk of this package anyway). Ciao, Marco Fioretti Red Hat 7.3 in 8 MB of RAM: www.rule-project.org -- Our inventions are wont to be pretty toys, which distract our attention from serious things. They are but improved means to an unimproved end, an end which it was already but too easy to arrive at; as railroads lead to Boston or New York. We are in great haste to construct a magnetic telegraph from Maine to Texas; but Maine and Texas, it may be, have nothing important to communicate. -- Henry David Thoreau (from Walden), 1854
How to set ispell to different languages - mutt 1.3.27i
Hi, how can I set in muttrc or in mutt itself at runtime the dictionary of ispell ... e.g. some mails are written in English some in German ... how can I change ispell within mutt to change the dictionary before checking the mail? Thanks in advance -- ... don't touch the bang-bang fruit
Re: problem about subjects in asian charsets
On Wed, Jul 31, 2002 at 01:12:56PM +0200, Alain Bench wrote: No: completely different problem. Your's is even not a Mutt problem, just bad system's locale configuration. Try to set LC_CTYPE to a suitable locale for your language, country and character set. Thanks Alain, for the hint that moved this one forward a bit. It still has the distinct appearance of a mutt problem, though, since: o vim effortlessly displays the iso-8859-1 characters, when invoked from within mutt, to edit the received email. i.e. it does what mutt fails to do. (Even with the current value of for LC_CTYPE.) o Also, when I vim a single line file, and then cat it in an xterm or Eterm: cat /tmp/fred To små børn - If you use mutt, this may not display properly. the iso-8859-1 characters display faultlessly. (So locale hardly seems to be the limitation.) It appears then, to this observer at least, that mutt is demonstrably the source of the doggy-do. (Hopefully this analysis is right, 'cos grubbing around the net for methods to massage LC_CTYPE has so far only revealed stuff that doesn't work for me. :-) Regards, Erik -- _,-_|\Erik Christiansen / \ Research Development Division \_,-.__/ Voice Products Department vNEC Business Solutions Pty. Ltd.
Re: problem about subjects in asian charsets
On Wed, Jul 31, 2002 at 01:12:56PM +0200, Alain Bench wrote: No: completely different problem. Your's is even not a Mutt problem, just bad system's locale configuration. Try to set LC_CTYPE to a suitable locale for your language, country and character set. OK, it seems then that the xterm and vim are more tolerant than mutt, when it comes to ISO8859-1 characters. They work fine with $LANG=C and LC_CTYPE=. Trying Roman Neuhauser's most helpful response on another thread: export LANG=en_AU.ISO8859-1 was enough for mutt, despite previous failures when setting LC_CTYPE to ISO8859-1. Grateful thanks Roman! Given that mutt is suffiently popular to be the one that we trip over, an FAQ entry might save some mailing list bandwidth. :-) Regards, Erik
