macros - is there any logic about when they work or not?
I have been trying to add a number of macros to mutt and have been
having all sorts of trouble. Basically the problem is that not all
macro definitions work in all menus, in particular:-
Very few macro definitions that I have tried work in the
'generic' menu. I have tried both single and two character macros
and only one or two combinations seem to work at all.
Only some macros work in the other menus, I have been testing
mostly in the 'index' menu. Mostly the macros that don't work
seem to be single character ones, the two character macros I
have tried do seem to work in the index menu.
So, for example, the following macros in my .muttrc file *don't*
work (though they all appear OK on the help screen):-
macro generic ,s "s{mailandnews.co.uk}"
macro generic ,c "c{mailandnews.co.uk}"
macro generic ^X ":source ~/.mutt/"
macro index ^X ":source ~/.mutt/"
But the following ones do work:-
macro generic \\b ":source ~/.mutt/muttrc\r"
macro generic \\d ":source ~/.mutt/demon\r"
macro generic \\c ":source ~/.mutt/cgreen\r"
macro generic \\i ":source ~/.mutt/isbd\r"
macro index ,s "s{mailandnews.co.uk}"
macro index ,c "c{mailandnews.co.uk}"
This all seems a bit unsatisfactory and vague to me, is there any way
to decide whether a particular macro will work or not other than
just trying it?
--
Chris Green ([EMAIL PROTECTED])
Home: [EMAIL PROTECTED] Work: [EMAIL PROTECTED]
WWW: http://www.isbd.co.uk/
Any way to set edit_headers only when forwarding mail
Is there any way to use mutt's hooks to set the $edit_headers variable to TRUE only when forwarding mail? I.e. I don't want to see/edit the headers when I'm composing and replying to mail normally but I *do* want to be able to edit the headers directly when I'm forwarding mail. -- Chris Green ([EMAIL PROTECTED]) Home: [EMAIL PROTECTED] Work: [EMAIL PROTECTED] WWW: http://www.isbd.co.uk/
Re: Any way to set edit_headers only when forwarding mail
Chris Green <[EMAIL PROTECTED]> wrote on Mon, 29 Nov 1999: > Is there any way to use mutt's hooks to set the $edit_headers variable > to TRUE only when forwarding mail? I don't know about the hooks, possibly, but I'd go for the approach where you create a macro for the "f" key instead, which sets $edit_headers, calls the forward function, and then unsets the variable. Hooks are nice but they don't have to be used for *everything*... 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 / Editing is a rewording activity.
Errors compiling 1.0i and 1.1.1i
Hi, `make install' gives me lots of warnings like the following (both for mutt1.0i and 1.1.1i): pop.c:336: warning: ANSI C forbids braced-groups within expressions system specifications: Debian 2.1 (Linux 2.2.10) gcc 2.7.2.3-12 make 3.77-4 the configure flags are: --with-sharedir="/usr/local/share/mutt" --with-slang --with-mailpath="/var/spool/mail" --enable-pop --with-regex --enable-locales-fix --enable-exact-address --with-charmaps="/usr/share/i18n/charmaps" --enable-PGP2 --enable-PGP5 --enable-PGP6 --enable-GPG --with-mixmaster="/usr/local/Mix" --enable-compressed and mutt -v: System: Linux 2.2.10 [using slang 10202] Opciones especificadas al compilar: -DOMAIN -HOMESPOOL +USE_SETGID +USE_DOTLOCK +USE_FCNTL -USE_FLOCK -USE_IMAP +USE_POP -HAVE_REGCOMP +USE_GNU_REGEX +HAVE_COLOR +HAVE_PGP5 +HAVE_PGP6 +HAVE_GPG -BUFFY_SIZE +EXACT_ADDRESS +ENABLE_NLS SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/spool/mail" SHAREDIR="/usr/local/share/mutt" SYSCONFDIR="/usr/local/etc" ISPELL="/usr/bin/ispell" _PGPPATH="/usr/local/bin/pgp" _PGPV3PATH="/usr/local/bin/pgp" _PGPGPGPATH="/usr/local/bin/gpg" TIA -- Horacio LC_mutt=es_ES mailto:[EMAIL PROTECTED]http://carlotha.ciberia.es/mutt/ ~ Spain ~ Spanje ~ Spanien Key fingerprint = F4EE AE5E 2F01 0DB3 62F2 A9F4 AD31 7093 4233 7AE6
Re: Errors compiling 1.0i and 1.1.1i
On Sun, Nov 28, 1999 at 02:00:07AM +0100, J Horacio MG wrote: > `make install' gives me lots of warnings like the following (both for > mutt1.0i and 1.1.1i): > > pop.c:336: warning: ANSI C forbids braced-groups within expressions They're only warnings. Anyway I think that stuff oughta be fixed. -- Ralf Hildebrandt <[EMAIL PROTECTED]> www.stahl.bau.tu-bs.de/~hildeb Boy, backups sure are a lot faster since I linked /dev/st0 to /dev/null...
Re: Quotes in macros [Was: macros - is there any logic about when they work or not?]
On Mon 11/29/99 at 09:26 AM +, Chris Green <[EMAIL PROTECTED]> wrote:
> So, for example, the following macros in my .muttrc file *don't*
> work (though they all appear OK on the help screen):-
>
> macro generic ,s "s{mailandnews.co.uk}"
> macro generic ,c "c{mailandnews.co.uk}"
> macro generic ^X ":source ~/.mutt/"
> macro index ^X ":source ~/.mutt/"
>
> But the following ones do work:-
>
> macro generic \\b ":source ~/.mutt/muttrc\r"
> macro generic \\d ":source ~/.mutt/demon\r"
> macro generic \\c ":source ~/.mutt/cgreen\r"
> macro generic \\i ":source ~/.mutt/isbd\r"
> macro index ,s "s{mailandnews.co.uk}"
> macro index ,c "c{mailandnews.co.uk}"
I believe that in your first two and last two macros above, the quotation
marks are unnecessary, since if I'm not mistaken quotes are only needed if
you have one or more spaces in whatever sequence you've defined. Though
apparently macros will function whether you have the quotes there or not.
But (sorry) I don't know why the top four macros won't work.
--
// [EMAIL PROTECTED] //
Both? [Re: ... slang/ncurses?]
This may sound stupid, but I have to know... could I have two different compilations of mutt, so that I can choose to work with the version compiled with slang from the console, and with the v. compiled with ncurses from an xterm? If this makes no sense at all, please, don't even bother to answer. Else, could you give some details? TIA -- Horacio LC_mutt=es_ES mailto:[EMAIL PROTECTED]http://carlotha.ciberia.es/mutt/ ~ Spain ~ Spanje ~ Spanien Key fingerprint = F4EE AE5E 2F01 0DB3 62F2 A9F4 AD31 7093 4233 7AE6
Re: mbox2maildir (was Re: Dazed & Confused)
On 0, Bennett Todd <[EMAIL PROTECTED]> wrote: > 1999-11-27-02:57:18 Nathan Cullen: > > Okay, I'm sold. :) But first, is there a simple way to convert my > > current mbox folders(files) into maildir format? Is this handled by > > mutt or another utility? > > It can be done in mutt; once you've set mbox_type="Maildir" you can visit an > mbox, tag everything (T~A) and then save all tagged messages to another folder > (;sfoldername) and if foldername doesn't already exist, mutt will create it in > its new default format, Maildir. > Where do you ? In .muttrc? Are the double quotes required? What is the difference between mbox_type and $mbox_type in .muttrc? Subba Rao [EMAIL PROTECTED] http://pws.prserv.net/truemax/
Re: Both? [Re: ... slang/ncurses?]
> This may sound stupid, but I have to know... could I have two different > compilations of mutt, so that I can choose to work with the version > compiled with slang from the console, and with the v. compiled with > ncurses from an xterm? Why not? Just configure it --with-slang, make, make install, and rename the executable (mv -i /usr/local/bin/mutt /usr/local/bin/mutt-slang), then configure it again, this time --with-curses, and install the other executable by hand (mv -i mutt /usr/local/bin/mutt-curses). Finally install a script at /usr/local/bin/mutt which decides which executable to run, depending on the circumstances, perhaps by looking at $TERM or $TERMINFO. Edmund
Re: The mbox_type variable [was Re: mbox2maildir]
On Mon 11/29/99 at 08:14 AM -0500, Subba Rao <[EMAIL PROTECTED]> wrote: > Where do you ? In .muttrc? Where? Well, I put it alphabetically, just after "set mbox..." and just before "set mime_forward..." Maybe I'm not understanding the question. You can put it anywhere you like, as long as it's somewhere in your .muttrc. > Are the double quotes required? No. Here's what I have in my .muttrc: set mbox_type=maildir # Which of the 4 mailbox formats I use. (Anything you put to the right of the '#' is just a comment, or note to yourself, that will not be acted upon, command-wise.) > What is the difference between mbox_type and $mbox_type in .muttrc? Don't use the dollar-sign in your .muttrc. That just means that it's a variable, when you're referring to it in discussion or whatever. -- // [EMAIL PROTECTED] //
Re: Bug in mutt for Solaris?
When the attachment arrived at your work address, it was probably just appended to your mail spool. A lot of mail agents, including mutt, simply look for a the header: >From in order to determine the start of a new message. Assuming that the attachment was a plain-text file, mutt just interpreted all the "From"s in there as the start of a new message. A safer way of sending a file such as this would be to gzip it up and send it along. On Mon, Nov 29, 1999 at 08:20:06AM +0200, Marc Silver wrote: > Hey there, > > I think I've stumbled across an interesting bug in mutt for Solaris. > I could be wrong, but that's why I'm posting to this list first... :) > > Last night, I sent an email to my work email address, and with it, > I attached my /var/mail/$USER file. This morning, upon coming into > work, I found that the mail I sent had been stripped of it's attachment, > and that the contents had been added to my existing /var/mail/$USER > file is this a feature, because as far as I'm concerned, it's > a bug that could potentially cause some damage. > > Here is some info on the mutt client I'm using at work; > > Mutt 1.0pre3i (1999-09-25) > Copyright (C) 1996-9 Michael R. Elkins and others. > Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. > Mutt is free software, and you are welcome to redistribute it > under certain conditions; type `mutt -vv' for details. > > System: SunOS 5.6 [using slang 10003] > Compile options: > -DOMAIN > -HOMESPOOL -USE_SETGID +USE_DOTLOCK +USE_FCNTL -USE_FLOCK > -USE_IMAP -USE_POP +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_PGP2 >-BUFFY_SIZE > -EXACT_ADDRESS +ENABLE_NLS > SENDMAIL="/usr/lib/sendmail" > MAILPATH="/var/mail" > SHAREDIR="/usr/local/share/mutt" > SYSCONFDIR="/usr/local/etc" > ISPELL="/usr/local/bin/ispell" > _PGPPATH="/usr/local/bin/pgp" > _PGPV2PATH="/usr/local/bin/pgp" > To contact the developers, please mail to <[EMAIL PROTECTED]>. > > Any help on this would be much appreciated. > Cheers, > Marc > > > -- > > Marc Silver > IS Hosting Infrastructure > The Internet Solution > Tel: (+27 11) 283 5500 > Fax: (+27 11) 283 5001 > E-mail: [EMAIL PROTECTED] > Web: www.is.co.za -- Vikram Adukia [EMAIL PROTECTED] (847) 632-3407
Re: rereading aliases file
On Sun, 28 Nov 1999, Peter Dominguez wrote: > Is there a command to force mutt to reread the aliases file. I add aliases > using vim. :source /path/to/alias-file CU Dirk -- Dirk Pirschel E-Mail: [EMAIL PROTECTED] (PGP key on request) The required OS was Windows 95 or better, so I installed Linux.
Re: mbox2maildir (was Re: Dazed & Confused)
1999-11-29-08:14:41 Subba Rao: > Where do you ? In .muttrc? As with all such commands, you can put it in your .muttrc and restart mutt; you can put it in your .muttrc and type :source .muttrc or you can just preceed it with a colon, and directly type :set mbox_type="Maildir" > Are the double quotes required? I'm not sure. I just typed it the way it appeared in my .muttrc. For whatever it's worth, the example in /etc/Muttrc seems to have the arg in double-quotes. > What is the difference between mbox_type and $mbox_type in .muttrc? $mbox_type I don't know about. Where do you use it? -Bennett PGP signature
color problem
Hi all, I hope this isn't an old conversation, but... I'm having problems with quoted colorings. At one point I thought the mutt viewer would use a different color for each of the adjoining lines below >color1 >>color2 >>>color1 >>color2 They display in different colors in vim, but they are all the same in the viewer? Does the viewer have that capacity? I'm using mutt-1.0pre3i-1. Please reply directly as I'm not on this list, I will provide my .muttrc for anyone who wants to see it, and I'm attaching my mutt wrapper for those who would like to try it, it launches fetchmail -d while mutt is running and allows only the first instance of mutt to be read-write. TIA, // George -- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ GEORGE GEORGALISICXC 858.621.9488 [EMAIL PROTECTED]NIKI PO Box 3342 http://galis.org La Jolla, CA 92038 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Re: Strange message formatting tags
Hi, Mikko! > Does anyone know what kind of email text formatting tags are these: > > "+ACI-+ACI-" or, appearing alone, "+ACE-" (at the end of > message text). > > The headers for the email where these appear say this: > > MIME-Version: 1.0 > Content-Type: text/plain; > charset="utf-7" > Content-Transfer-Encoding: quoted-printable > X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Let me think... ACI could stand for ``Attachment for Crashing Interpreters'' (such as Outlook) and ACE for ``Attempt to Crash Email-systems''; thus, > "tell the email sender to use a non-broken email program". is, as you thought, the perfect answer to do either side the greatest favor. Thank you for supplying this little piece of fun for the mutt community. -- Matthias Lampert, Germany -- Matthias
Re: Strange message formatting tags
On Mon, Nov 29, 1999 at 06:04:10AM +0200, Mikko Hänninen wrote: > Hi, > > Does anyone know what kind of email text formatting tags are these: > > "+ACI-+ACI-" or, appearing alone, "+ACE-" (at the end of > message text). > > The headers for the email where these appear say this: > > MIME-Version: 1.0 > Content-Type: text/plain; > charset="utf-7" ^ Visit http://czyborra.com/utf/#UTF-7 for more info. Cite: All of the above UTFs produce 8bit bytes that are not in ASCII and that will get stripped on any terminal that is still set to character size 7 or any mail gateway that ensures RFC 822's rule that mail messages have to be in ASCII. To solve that problem, David Goldsmith and Mark Davis invented a mail-safe transformation format UTF-7. It was first published in ftp://ftp.isi.edu/in-notes/rfc1642.txt">RFC 1642 in 1994, prominently included as Appendix A.1 in The Unicode Standard, Version 2.0, and now updated in ftp://ftp.isi.edu/in-notes/rfc2152.txt">RFC 2152. Mutt already supports utf-8. Supporting utf-7 would not hurt (or would it?) Best regards, Marius Gedminas -- One picture is worth 128K words.
Re: Errors compiling 1.0i and 1.1.1i
On Mon, Nov 29, 1999 at 12:14:20PM +0100, Ralf Hildebrandt wrote: > On Sun, Nov 28, 1999 at 02:00:07AM +0100, J Horacio MG wrote: > > > `make install' gives me lots of warnings like the following (both for > > mutt1.0i and 1.1.1i): > > > > pop.c:336: warning: ANSI C forbids braced-groups within expressions > > They're only warnings. > Anyway I think that stuff oughta be fixed. You see this warning because /usr/include/ctype.h (from glibc) contains some clever optimized #defines for tolower()/toupper() that make use of GCC extended features. This is harmless and appears only when you give gcc both -O and -pedantic switches. Scared me a lot when I first saw them ;) HTH Marius Gedminas -- Any sufficiently advanced bug is indistinguishable from a feature. -- Rich Kulawiec
Re: macros - is there any logic about when they work or not?
Chris Green <[EMAIL PROTECTED]> wrote on Mon, 29 Nov 1999:
> So, for example, the following macros in my .muttrc file *don't*
> work (though they all appear OK on the help screen):-
>
> macro generic ,s "s{mailandnews.co.uk}"
> macro generic ,c "c{mailandnews.co.uk}"
Don't know about these two... I'm not sure about the generic bindings,
never played around with them. I've always used just index/pager
macros, they work well enough for me.
> macro generic ^X ":source ~/.mutt/"
> macro index ^X ":source ~/.mutt/"
But here, I suspect you want to use \cX instead. When I try the above
commands, they work fine for me -- when I first type ^ followed by an X.
> This all seems a bit unsatisfactory and vague to me, is there any way
> to decide whether a particular macro will work or not other than
> just trying it?
I've never had any problems with macros that I've not been able to
(finally) determine a specific cause for, but admittedly finding the
reason has not been easy in some places.
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 /
"NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent... Hi Echelon!"
Re: fetch-mail
Jeffrey L. Taylor [[EMAIL PROTECTED]] wrote: > I am having problems getting my mail. I have two question, one OT. I > have 'G' bound to a fetchmail macro. 1) How can I invoke the original > binding 'fetch-mail'? From the docs, I would expect ':fetch-mail' to > work. Mutt complains about an unknown command. :exec fetch-mail -- Jeremy Blosser | [EMAIL PROTECTED] | http://jblosser.firinn.org/ -+-+-- "If Microsoft can change and compete on quality, I've won." -- L. Torvalds PGP signature
Re: fetch-mail
Jeffrey L. Taylor <[EMAIL PROTECTED]> wrote on Sun, 28 Nov 1999: > I am having problems getting my mail. I have two question, one OT. I > have 'G' bound to a fetchmail macro. 1) How can I invoke the original > binding 'fetch-mail'? From the docs, I would expect ':fetch-mail' to > work. Mutt complains about an unknown command. Try this: : (I didn't look up the function name, if you have it right then the above should work.) > 2) Fetchmail is using > maildrop as an MTA. Maildrop complains about can't dot-lock. How do > I find out what it can't lock, who has it locked, and how to break the > lock (I am using Maildir mailboxes)? You shouldn't need any locking for Maildir, tell maildrop not to use any locking for that folder. I forget how to do that, I don't use maildrop, but I remember seeing just yesterday some references to locking issues in the maildrop man page. It's probably all documented there... 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 / Microsoft is not the answer. Microsoft is the question. NO is the answer.
Re: color problem
George Georgalis [[EMAIL PROTECTED]] wrote: > I'm having problems with quoted colorings. At one point I thought the > mutt viewer would use a different color for each of the adjoining lines > below > > >color1 > >>color2 > >>>color1 > >>color2 > > They display in different colors in vim, but they are all the > same in the viewer? Does the viewer have that capacity? I'm using > mutt-1.0pre3i-1. The pager has that ability, and the lines show in different colors for me. Here are the relevant lines from my .muttrc: color quoted greendefault color quoted1 yellow default color quoted2 greendefault color quoted3 yellow default -- Jeremy Blosser | [EMAIL PROTECTED] | http://jblosser.firinn.org/ -+-+-- "If Microsoft can change and compete on quality, I've won." -- L. Torvalds PGP signature
Re: color problem
> George Georgalis [[EMAIL PROTECTED]] wrote: > > I'm having problems with quoted colorings. At one point I thought the > > mutt viewer would use a different color for each of the adjoining lines > > below > > > > >color1 > > >>color2 > > >>>color1 > > >>color2 They are all the same color for me, too. However, the following lines look different: >color1 > color2 > color3 > color4 It's not even consistent. Sometimes, the "color2" line will be shown in color1. Anything with multiple quotes (>) ends up in color1. I'm using mutt-1.0-pre-something. So, I don't know how it determines what colors to use. Sometimes it'll even change colors in mid-viewing, if I scroll the page. _ _ _ _ ___ ___ "Use the source, Luke!"- ( \/ ( \/ (__ (__ ) | Scott Scriven (Toy Keeper / XYZZ)| \ / \ / // // | mailto:[EMAIL PROTECTED] | / \ / / //_ //_ | irc:serdevian.dyn.omnipotent.net | (_/\_(_/ (___(___) | http://www.vis.colostate.edu/~scriven/ |
Re: color problem
Scott Scriven [[EMAIL PROTECTED]] wrote: > > George Georgalis [[EMAIL PROTECTED]] wrote: > > > I'm having problems with quoted colorings. At one point I thought the > > > mutt viewer would use a different color for each of the adjoining lines > > > below > > > > > > >color1 > > > >>color2 > > > >>>color1 > > > >>color2 > > They are all the same color for me, too. However, the > following lines look different: > > >color1 > > color2 > > color3 > > color4 > > It's not even consistent. Sometimes, the "color2" line will be > shown in color1. Anything with multiple quotes (>) ends up in > color1. I'm using mutt-1.0-pre-something. Well, I'm guessing the value of $quote_regexp comes into play here, but see below. > So, I don't know how it determines what colors to use. > Sometimes it'll even change colors in mid-viewing, if I scroll > the page. This really sounds like an issue of your $TERM or term library... I'd try other options and see if you can figure it out (other terminal emulators, etc.). -- Jeremy Blosser | [EMAIL PROTECTED] | http://jblosser.firinn.org/ -+-+-- "If Microsoft can change and compete on quality, I've won." -- L. Torvalds PGP signature
Re: Eterm && Message to button
Peter Dominguez [[EMAIL PROTECTED]] wrote:
> I am new to Eterm && mutt. Can someone tell me how to add addresses
> to Jeremy Blosser's Message to button?
Edit mutt.menu and add lines like:
{bob} [EMAIL PROTECTED]\r
after the
./New Message To/*
line.
--
Jeremy Blosser | [EMAIL PROTECTED] | http://jblosser.firinn.org/
-+-+--
"If Microsoft can change and compete on quality, I've won." -- L. Torvalds
PGP signature
Re: color problem
George Georgalis <[EMAIL PROTECTED]> wrote: > > >color1 > >>color2 > >>>color1 > >>color2 > > They display in different colors in vim, but they are all the same in > the viewer? For me, they show up in different colors. You need two things to make this work: 1. Some colors defined for multiple quote levels 2. A proper quote_regexp that will match repeated quote levels properly Here's my settings for (1): color quoted green black color quoted1white black color quoted2brightred black color quoted3magenta black color quoted4red black And here's my setting for (2): set quote_regexp="^([ \t]?[ \t]?[>:|])+" Mutt will notice and colore more than five levels of quoting; it will simply re-use the colors again, if I remember rightly. The quote_regexp format is very important. It must match *only* the text at the front of the line, that forms the "quote" section. If it ends up matching the entire line, then all quotes will appear at the same "level." The reason for this is that Mutt looks at the *length* of the string that matches the regular expression. Each time a new length is seen, it is treated as a new level of quoting. Note, longer lengths are not treated as deeper levels, just *different* levels. Have fun. -- David DeSimone | "The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson UX WTEC Engineer |PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
