Re: Current Mailbox Shortcut?
On Mon, Feb 15, 1999 at 16:45:24 -0500, Randall J. Million wrote: I sent out this reuqest a while back, but later lost the patch that made this possible. I also thought that it would be included in the main distribution. (The patch made the ^ (caret) a shortcut for the current mailbox.) I made the patch. It was originally made for 0.94.13, but it still works without change on 0.95.3. Since 0.94.13 was a development version it was originally only sent to Randall and the mutt-dev list. But here it is in mutt-users for the first time. Regards, - Byrial --- lib.c~ Fri Oct 16 14:50:45 1998 +++ lib.c Tue Oct 20 20:29:20 1998 @@ -253,6 +253,8 @@ char *mutt_expand_path (char *s, size_t q = Spoolfile; else if (*s == '-') q = LastFolder; +else if (*s == '^' Context) + q = Context-path; else return s; --- doc/manual.sgml.in~ Fri Oct 16 14:50:43 1998 +++ doc/manual.sgml.in Tue Oct 20 20:32:08 1998 @@ -1683,6 +1683,7 @@ path. itemgt; -- refers to your ref id="mbox" name="dollar;mbox" file itemlt; -- refers to your ref id="record" name="dollar;record" file item- -- refers to the file you've last visited +item^ -- refers to the current open mailbox if any itemtilde; -- refers to your home directory item= or + -- refers to your ref id="folder" name="dollar;folder" directory item@em/alias/ -- refers to the ref id="save-hook"
Re: disable X-Mailer:? (was: [Announce] Mutt 0.95.3 is out.)
On Fri, Feb 12, 1999 at 17:42:37 -0800, Claus Assmann wrote: Question: how can I disable the X-Mailer: header? Apropos the X-Mailer header: I think I somewhere read about a try to make a standardized "User-Agent" header to replace the various X-* headers used by mailers and newsreaders to identify themselves. I don't know the current state of this. Should Mutt change to use a User-Agent header? Regards, - Byrial
Patches on the list [was: Alias and saving question]
On Thu, Feb 18, 1999 at 11:56:32 +0100, Hans Bogaards wrote: This results in a question: Is it alright if I send patches like this to the mutt-user list or should I send it to the developers list? Currently I'm not subscribed to the developers list, because I'm not actively following the development at the moment (lack of time). I think it is fine to send patches here which can be useful for mutt's users. But highly experimental or potential dangerous patches, and patches to development releases should go to mutt-dev. Regards, - Byrial
Re: Setting the subject line
On Tue, Mar 09, 1999 at 12:19:31 -0500, Rob Reid wrote:
send-hook tea@astro "my_hdr Subject: Tea and cookies in the Astrolounge at 3:30"
send-hook !tea@astro "unmy_hdr Subject"
Everything works except the subject line, which shows up on the _n_e_x_t
message I write, even if it isn't to "tea@astro". Can anybody help me
(free cookie if you show up here at 3:30 on a Tuesday :) or explain
why my From: line gets set properly but my Subject line is delayed
until the next message?
The subject will not set in messages sent to tea@astro because
subjects are handled before the send-hooks are executed. And when
you send the next message, its subject will for the same reason be
set before the send-hooks remove the "my_hdr Subject"-setting again.
Another bug is that "my_hdr Subject" cannot be turned off by
unsetting $hdrs.
And send-hooks are not executed at all when sending in batchmode.
All 3 things should be fixed in the attached patch.
Regards
- Byrial
--- send.c-old Thu Jan 14 00:55:59 1999
+++ send.c Wed Mar 10 18:14:02 1999
@@ -192,47 +192,35 @@ static int edit_address (ADDRESS **a, /*
static int edit_envelope (ENVELOPE *en)
{
- char buf[HUGE_STRING];
- LIST *uh = UserHeader;
-
if (edit_address (en-to, "To: ") == -1 || en-to == NULL)
return (-1);
if (option (OPTASKCC) edit_address (en-cc, "Cc: ") == -1)
return (-1);
if (option (OPTASKBCC) edit_address (en-bcc, "Bcc: ") == -1)
return (-1);
+ return 0;
+}
- if (en-subject)
+static int edit_subject (char *subject[])
+{
+ char buf[HUGE_STRING];
+
+ if (*subject)
{
if (option (OPTFASTREPLY))
return (0);
else
- strfcpy (buf, en-subject, sizeof (buf));
+ strfcpy (buf, *subject, sizeof (buf));
}
- else
- {
-char *p;
-buf[0] = 0;
-for (; uh; uh = uh-next)
-{
- if (mutt_strncasecmp ("subject:", uh-data, 8) == 0)
- {
- p = uh-data + 8;
- SKIPWS (p);
- strncpy (buf, p, sizeof (buf));
- }
-}
- }
-
if (mutt_get_field ("Subject: ", buf, sizeof (buf), 0) != 0 ||
(!buf[0] query_quadoption (OPT_SUBJECT, _("No subject, abort?")) != 0))
{
mutt_message _("No subject, aborting.");
return (-1);
}
- safe_free ((void **) en-subject);
- en-subject = safe_strdup (buf);
+ safe_free ((void **) subject);
+ *subject = safe_strdup (buf);
return 0;
}
@@ -274,10 +262,15 @@ static void process_user_header (ENVELOP
rfc822_free_address (env-reply_to);
env-reply_to = rfc822_parse_adrlist (env-reply_to, uh-data + 9);
}
+else if (mutt_strncasecmp ("subject:", uh-data, 8) == 0)
+{
+ /* Don't overrule the default subject settings in replies and forwards */
+ if (! env-subject)
+ env-subject = safe_strdup (uh-data);
+}
else if (mutt_strncasecmp ("to:", uh-data, 3) != 0
mutt_strncasecmp ("cc:", uh-data, 3) != 0
-mutt_strncasecmp ("bcc:", uh-data, 4) != 0
-mutt_strncasecmp ("subject:", uh-data, 8) != 0)
+mutt_strncasecmp ("bcc:", uh-data, 4) != 0)
{
if (last)
{
@@ -965,6 +958,7 @@ ci_send_message (int flags, /* send mod
if (option (OPTHDRS))
{
process_user_recips (msg-env);
+ mutt_send_hook (msg);
process_user_header (msg-env);
}
}
@@ -1008,6 +1002,15 @@ ci_send_message (int flags, /* send mod
if (option (OPTHDRS))
process_user_header (msg-env);
+
+
+if (! (flags SENDMAILX)
+ ! (option (OPTAUTOEDIT) option (OPTEDITHDRS))
+ ! ((flags SENDREPLY) option (OPTFASTREPLY)))
+{
+ if (edit_subject (msg-env-subject) == -1)
+ goto cleanup;
+}
Re: Setting the subject line
On Thu, Mar 11, 1999 at 20:38:23 -0800, David Ellement wrote:
On 990310, at 18:38:14, Byrial Jensen wrote:
All 3 things should be fixed in the attached patch.
BTW someone told me that all 3 things aren't bugs, but intentional
(and undodumented!) features. It may be so, but then I prefer to
remove these "features".
After applying this patch, the "Subject:" prompt always begins with "@":
Sorry, I forgot to initialize the variable to hold a new subject.
Correction attached.
- Byrial
--- send.c~ Wed Mar 10 18:14:02 1999
+++ send.c Fri Mar 12 08:38:30 1999
@@ -212,6 +212,8 @@ static int edit_subject (char *subject[]
else
strfcpy (buf, *subject, sizeof (buf));
}
+ else
+buf[0] = 0;
if (mutt_get_field ("Subject: ", buf, sizeof (buf), 0) != 0 ||
(!buf[0] query_quadoption (OPT_SUBJECT, _("No subject, abort?")) != 0))
Re: ispell handling
On Fri, Mar 12, 1999 at 12:21:05 -0600, David DeSimone wrote:
Vikas Agnihotri [EMAIL PROTECTED] wrote:
If you are using a non-standard ispell which does NOT accept '-x', you
can always 'set ispell=/path/to/ispell' in your muttrc.
No you can't, because it's hard-coded in the source.
You can make a script to call ispell without the option
('/path/to/ispell $2') and 'set ispell=/path/to/script'
in your muttrc.
- Byrial
Re: Setting the subject line
On Sun, Mar 14, 1999 at 18:20:57 -0500, Rob Reid wrote: Thanks, Byrial, for fixing the my_hdr Subject: problem. At 2:55 AM EST on March 12 Byrial Jensen sent off: BTW someone told me that all 3 things aren't bugs, but intentional (and undodumented!) features. It may be so, but then I prefer to remove these "features". Can you (or the intender) explain why those things were intentional? Well, I can't. I have to leave this question to the intender. There was one small problem with your patch, though: I ended up with Subject: Subject: blah blah blah... when I tried using my_hdr Subject: blah blah blah... The attached patch _f_o_r_ _m_u_t_t_s_ _a_l_r_e_a_d_y_ _p_a_t_c_h_e_d_ _w_i_t_h_ _p_a_t_c_h_-_0_._9_5_._4_._b_j_._m_y___h_d_r___s_u_b_j_e_c_t fixes that so that Subject: only appears once. Thnk you for fixing that. I have just putted the whole patch including your fix on my mutt patch webpage. Find it at URL: http://www.image.dk/~byrial/mutt/patches/. Regards, - Byrial
Re: limit question
On Mon, Apr 19, 1999 at 10:36:15 -0700, Robert Chien wrote: 3. Binding ^L to unlimit in the source code? so that when you press '?' for help and search for 'limit', it'll come up? You can put comments into your macro defintions so searching will work fine without changing the source code. macro index \cl l.\n unlimit -- Byrial
Re: Adding to date header
On Wed, Apr 21, 1999 at 16:22:23 +0200, [EMAIL PROTECTED] wrote:
Hi there,
is it possible to add anything to the date header?
It now reads:
Date: Wed, 21 Apr 1999 10:36:03 +0200
and I'd like it to read something like:
Date: Wed, 21 Apr 1999 (2752 ad U.c.) 10:36:03 +0200
^^
perhaps in a way it calculates current year + 753 (that possibly belongs
to the date_format string, but where is it located?
It can't be done without changing the source. But fortunately
that's rather easy to do in this case.
Edit sendlib.c and find the function "mutt_make_date" around line
1146 and replace it with this code:
char *mutt_make_date (char *s, size_t len)
{
time_t t = time (NULL);
struct tm *l = localtime (t);
time_t tz = mutt_local_tz (t);
tz /= 60;
snprintf (s, len,
"Date: %s, %d %s %d (%d ad U.c.) %02d:%02d:%02d %+03d%02d\n",
Weekdays[l-tm_wday], l-tm_mday, Months[l-tm_mon],
l-tm_year + 1900, l-tm_year + 1900 + 753,
l-tm_hour, l-tm_min, l-tm_sec,
tz / 60, abs (tz) % 60);
return (s);
}
I don't make a patch because it would conflict with the bugfix
patch posted by TLR a few days ago to fix the Date:-header if the
local timezone isn't a whole number of hours. The fix is included
in the above code.
BTW what happened 2752 years ago?
--
Byrial
Re: Adding to date header
On Wed, Apr 21, 1999 at 17:37:22 -0500, David Shaw wrote: On Wed, Apr 21, 1999 at 04:23:43PM -0500, David DeSimone wrote: is it possible to add anything to the date header? Date: Wed, 21 Apr 1999 (2752 ad U.c.) 10:36:03 +0200 ^^ Aren't there RFC requirements about what a Date: header is supposed to look like? Yes. 822 specified it and 1123 changed the format a little (made it Y2K happy among other things). Strictly speaking, the above format is illegal, so who knows how another mail program will parse it. Well, as I read RFC 822, the above format for the Date header is perfectly legal. You may place comments enclosed in parentheses almost everywhere in headers. There may be mail programs which cannot parse it, but it will the fault of these programs. -- Byrial
Re: Problem wit attachments
On Fri, May 28, 1999 at 15:38:54 +0200, Attila Csosz wrote:
I tried to mail me a test message with attachment( it contained a file
test.arj ). Using mutt everythig is OK. I see in the attachment list the
correct file name( pressing v key ). But when I fetched this mail with
a windows based e-mail client( AKMail ) I see the attacment but the
attachment has no name.
There are two places where the file name of an attachment can
placed:
1) In the "Content-Type:"-header. This was defined in the now
obsolete RFC 1341, but the newer RFC 2046 says about this:
RFC 1341 also defined the use of a "NAME"
parameter which gave a suggested file name to be used if the data
were to be written to a file. This has been deprecated in
anticipation of a separate Content-Disposition header field, to be
defined in a subsequent RFC.
2) In the "Content-Disposition:"-header according to RFC 2183.
Mutt understands both methods for storing the file name when
reading, but only uses the second method when generation new
attachments.
So if other e-mail clients cannot find the file name of attachments
made by mutt, it could be because they are too old to recognize the
Content-Disposition:-header.
It would not be hard to let mutt use both methods also when
writing, and I don't think that it would do any harm.
This patch should do it, but I haven't tested it!
--- sendlib.c.orig Wed Apr 21 21:40:26 1999
+++ sendlib.c Sat May 29 12:16:27 1999
@@ -423,15 +423,8 @@ int mutt_write_mime_header (BODY *a, FIL
}
}
- fputc ('\n', f);
-
- if (a-description)
-fprintf(f, "Content-Description: %s\n", a-description);
-
if (a-use_disp (a-disposition == DISPATTACH || a-filename || a-d_filename))
{
-fprintf (f, "Content-Disposition: %s", DISPOSITION (a-disposition));
-
if(!(fn = a-d_filename))
fn = a-filename;
@@ -445,11 +438,20 @@ int mutt_write_mime_header (BODY *a, FIL
buffer[0] = 0;
rfc822_cat (buffer, sizeof (buffer), t, MimeSpecials);
- fprintf (f, "; filename=%s", buffer);
-}
-fputc ('\n', f);
+ fprintf (f, "; name=%s\n"/* Finish the Content-Type header */
+ "Content-Disposition: %s; filename=%s",
+ buffer, DISPOSITION (a-disposition), buffer);
+}
+else
+ fprintf (f, "\n" /* Finish the Content-Type header */
+ "Content-Disposition: %s", DISPOSITION (a-disposition));
}
+
+ fputc ('\n', f);
+
+ if (a-description)
+fprintf(f, "Content-Description: %s\n", a-description);
if (a-encoding != ENC7BIT)
fprintf(f, "Content-Transfer-Encoding: %s\n", ENCODING (a-encoding));
--
Byrial
Re: Replying with headers
On Mon, May 31, 1999 at 13:32:34 -0400, Rob Reid wrote: At 5:39 AM EDT on May 31 Byrial Jensen sent off: If you like, I could make a patch for you with a new $reply_weed configuration variable -- it would only take a few minutes. Maybe it'd be easier to set editor to something like sed "magic for deleting unwanted header lines" | your_regular_editor It depends on who you are. It is easier for me to patch mutt than to make a sed scrict. All the necessary source code exists, you just need to change the flags passed from include_reply() to mutt_copy_message(). But yes, anyone less familiar with mutt's source than me might prefer to do the thing by so other means (sed, perl, editor macros or whatever he is familiar with). -- Byrial
Re: Replying with headers
On Wed, May 26, 1999 at 15:28:01 +0200, Gerrit Holl wrote: I mean that if I reply, I see the specified headers by the previous mail. I've "header" turned on now, but if I reply, I see _all_ headers quoted, including the ones I ignored. The ones I ignore are only ignored when reading mail... It is still unclear to me what you want to do, but I think that you maybe wish to quote some of headers, but not all of them in your replies. If this is the case, then the answer is that you can't. You can quote all headers (by setting $header) or no headers (by unsetting $header) in replies, but there is no equivalent to $forward_weed when replying. If you like, I could make a patch for you with a new $reply_weed configuration variable -- it would only take a few minutes. -- Byrial
Re: Reloading .muttrc
On Wed, Jun 09, 1999 at 16:16:00 -0400, Mike Broome wrote: You can load your .muttrc with the command ":source .muttrc". However, this will not actually reload your settings. It will load the settings in .muttrc in top of any current settings. For testing some changes (especially some hooks), I've found no other solution than to quit and restart mutt so as to get a clean .muttrc load from scratch. You can reset all variables to their default values with ":reset all" before sourcing .muttrc, but other configuration (key bindings, macros, colors, hooks etc.) cannot be reset in a simple way. -- Byrial
Re: A pager_format question
On Sun, Jun 27, 1999 at 13:53:52 +0200, Salvatore Sciacco wrote: Hello, when your are reading messages with the pager it would be useful to have some information about how many unread (new/old) messages you have left to read. I see this info is available for the status_format variable, but it isn't for the pager_format. There is a way to add this printf value? Maybe a patch, I'm using 95.6i No, but you can keep you index status line onscreen while you are in the pager by setting the numeric variable "pager_index_lines" to 1 or higher. -- Byrial
Re: send hook for signature
On Fri, Jul 02, 1999 at 11:04:04 +0200, Renaud Colinet wrote:
I personally use the followings when posting to mutt-users-list (English
speaking):
#
#Specify signature and attribution with respect to recipient
send-hook . set signature=~/.signature
send-hook . 'set attribution="le %d, %n a écrit :"'
# Let my .sig and attribution be in English for mutt-users list
send-hook mutt-users set signature=~/.sig.eng
send-hook mutt-users 'set attribution="on %d, %n wrote:"'
It seems that from these settings that you have an English date
included in your French attribution text. You don't need to have
that if you have working locales on your machine.
Instead you could do like this:
set locale=fr_FR
send-hook . 'set attribution="le %{%b %d}, %n a écrit :"'
send-hook mutt-users 'set attribution="on %{!%b %d}, %n wrote:"'
# The "!" disables use of French locale in the English text
Or like this:
send-hook . 'set locale=fr_FR attribution="le %{%b %d}, %n a écrit :"'
send-hook mutt-users 'set locale=en_US attribution="on %{%b %d}, %n wrote:"'
--
Byrial
Re: trivial feature request
On Mon, Aug 09, 1999 at 14:25:19 -0500, David DeSimone wrote: I think relative jumps are not very useful, and that a macro that leaves the pager and comes back is quite sufficient for the rare case where a user types their PGP passphrase incorrectly. Some screen-flicker is the price to pay for fat fingers. :) A macro like this: macro pager A exitdisplay-message will not give more screen flicker than using a relative jump would, because the screen isn't updated while executing macros. (See mutt_refresh() in curs_lib.c for implentation details). So I see no reason at all for relative jumps. -- Regards, Byrial
Re: Index character used for Old messages
On Fri, Aug 13, 1999 at 21:47:38 +, Tom Gilbert wrote: Hi guys, Is there any way I can change the character used to indicate an Old message (unread but not new) when mark_old is set? It currently uses O, but I would prefer n or U or something more appropriate... Any options? Yes, change the source and rebuild. The used character are hardcoded into this expression in hdrline.c: (THREAD_NEW ? 'n' : (THREAD_OLD ? 'o' : ((hdr-read (ctx ctx-msgnotreadyet != hdr-msgno)) ? (hdr-replied ? 'r' : ' ') : (hdr-old ? 'O' : 'N' Just change the 'O' to 'U' or some other character. -- Byrial
Re: managing folders
On Tue, Oct 12, 1999 at 09:37:08 -0700, Larry Fletcher wrote: Is there any way to expire messages in selected folders similar to the way messages in newsgroups are expired? Yes, you can use the "delete-pattern" command with a pattern to give the oldest messages. E.g. to delete all messages received more than 20 days ago type "D~r20d" and enter. Or you can bind the key sequence to a key with a macro: macro index E "D~r20denter" "Expire messages older than 20 days" Or to limit the number of messages a folder will hold, so when new messages are added old messages scroll off? No, I don't see how this could be done. -- Byrial
Re: managing folders
On Fri, Oct 15, 1999 at 12:38:20 -0700, Larry Fletcher wrote: On Oct 15, 1999, Byrial Jensen wrote: Is there any way to expire messages in selected folders similar to the way messages in newsgroups are expired? Yes, you can use the "delete-pattern" command with a pattern to give the oldest messages. E.g. to delete all messages received more than 20 days ago type "D~r20d" and enter. Or you can bind the key sequence to a key with a macro: macro index E "D~r20denter" "Expire messages older than 20 days" Thanks! This isn't the completely automated solution I was looking for, but it's definitely a step in the right direction. I think that you can do it automatically with this command: mutt -f folder-to-expire -e 'set delete;push D~r20denterq' -- Byrial
Re: managing folders
On Sat, Oct 16, 1999 at 17:42:40 +0300, Mikko Hänninen wrote: Eric Smith [EMAIL PROTECTED] wrote on Sat, 16 Oct 1999: | mutt -f folder-to-expire -e 'set delete;push D~r20denterq' BTW, how would one modify this so that insted of deleting it copies to another folder or even better adds it to a folder-to-expire.tar.gz. You need to tag the messages instead of deleting (T, not D). Then you need to to add a second command which saves the tagged messages to a folder of your choice, something like ";s=folderenter" added before the quit. Shouldn't be too difficult to work out. However there is a problem here. If no messages were tagged then the tag-prefix will have no effect, and what happens to be the current message will then be expired. This problem can arise with many macros, too. It might be a good idea to solve such kind of problems by ignoring the command immediately after a tag-prefix command when there are no tagged messages when executing macros or push commands. BTW. The tag-prefix ";" should be escaped with a backslash, or the argument to the push command should be quoted. Otherwise the ";" will be interpreted as a command separator. -- Byrial
Re: managing folders
On Mon, Oct 18, 1999 at 11:26:18 +0200, Dirk Huebner wrote: this is just another addition to the other solutions :-) Perhaps using "folder-hooks" would also be an appropriate solution for you. In my case it is the perfect way. I use the following: folder-hook =trash 'push T~r2w!~F\n\;delete\x' Replace "delete" with "delete-message" to avoid the first error message. This one deletes all mails older than 2 weeks when entering the trash-folder. ... all mails older than 2 weeks (~r2w) which are not flagged (!~F). But take care! If no mails match the pattern, then the tag-prefix (\;) will have no effect, and what happens to be the current message will be marked for deletion. In this case it will not get deleted because of the finishing exit command (\x) which lets mutt exit without modifying the mailbox. But if it is removed, you risk to delete the wrong mail! It is much safer to use the delete-pattern command: folder-hook =trash 'push D~r2w!~F\n' Or: folder-hook =lists/mutt 'push T~r2w!~F\n\;s=lists/mutt_backup\n\x' This one saves 2week old mails from mutt-users to mutt_backup. Again if no mails match the pattern (older than 2 weeks and not flagged), a wrong mail is copied to mutt_backup (but again not deleted because of the exit command). I don't know any good fix for this. -- Byrial
Re: managing folders
On Tue, Oct 19, 1999 at 08:46:53 +0200, Dirk Huebner wrote: Not long ago (exactly Tue, 19 Oct 1999) Byrial Jensen wrote: Replace "delete" with "delete-message" to avoid the first error message. Do you get error messages? Yes, I got "Key is not bound." You must have the keybinding: bind index delete delete-message which I don't have. Therefore I changed the key name "delete" to the function name "delete-message" in the push command. BTW the command "push string" can mean 3 different things: 1. If there exists a key named string, execute the function bound to that key, or else 2. if there exists a function named string, execute that function, or else 3. execute the functions bound to the keys , s, t, r, i, n, g, . Again if no mails match the pattern (older than 2 weeks and not flagged), a wrong mail is copied to mutt_backup (but again not deleted because of the exit command). Oh my god, you are right! Haven't seen that. But it seems as if always the current message is saved then. Pressing "u" should work then. So the followig should fix the problem: folder-hook =lists/mutt 'push uT~r2w!~F\n\;s=lists/mutt_backup\n\x' Well, not really. You should place the 'u' (for undelete-message) after the save operation to get any effect: folder-hook =lists/mutt 'push T~r2w!~F\n\;s=lists/mutt_backup\nu' But even if you do so, it will not work properly: - If some messages were tagged, and the current message happens to one of them, then it will not deleted from the "mutt" folder as it should. - And if no messages were tagged, then the current message will still be saved to the "mutt_backup" folder even though the 'u' saves it from being deleted from the "mutt" folder. -- Byrial
Re: my_hdr From vs set use_from
On Sun, Oct 31, 1999 at 23:19:31 +0100, Rejo Zenger wrote: ++ 08/10/99 11:37 +0200 - Thomas Roessler: The $from variable is present only in the unstable branch. With 1.0i, is it still not included? No, as Thomas said only in unstable branch. You have to use Mutt 1.1 to get the $from variable. -- Byrial
Re: problems with MB
On Mon, Nov 01, 1999 at 17:56:57 +0200, Mikko Hänninen wrote: Pieter Wenk [EMAIL PROTECTED] wrote on Mon, 01 Nov 1999: I don't think you can continue lines with \ at the end, like you can do with shell scripts or some other configuration files. Lines in mutt configuration files (muttrc and mailcap files) can be continued with \ -- or saying it another way, the newline character otherwise ending the line can be escaped. Just make sure that you don't have spaces after after the \. having long lines (Mutt understands about lines longer than 80 characters), Yes, there is in fact no other limit to line length than the size of the available memory. P.S. Mikko, something seems wrong with your configuration or is it maybe a bug in Mutt? Pieter had a "Mail-Followup-To: [EMAIL PROTECTED]" header in his message. Nevertheless did you send him a CC of your answer. And I have seen several similar cases from other persons, too. I wonder why the M-F-T header doesn't seem to work. -- Byrial
Re: Display output of a script
On Tue, Nov 02, 1999 at 14:57:27 +0100, Wojciech Kalka wrote: I wrote a perl script which scans all my maildir folders and displays a statistic. ... But I would like to have the output embedded in the mutt screen. I don't think it is possible as it is now. You have to hack on the source. There are many generic functions (the Mutt pager, the menu system and others) there you can use. -- Byrial
Re: no such color
On Sat, Nov 06, 1999 at 19:45:41 -0800, Reed Lai wrote: agree, i got ncurses-5.0 and slang-1.3.9 in my system, but default color didn't work. i saw a message when ./configure, maybe is the key problem... "checking for use_default_colors... (cached) no" ^^ have any idea? What about clearing or editing the configuration cache before reconfiguration for a new ncurses or slang version? rm config.cache ; ./configure -- Byrial
Re: Alternates - an example
On Thu, Nov 11, 1999 at 15:19:38 +0100, Sven Guckes wrote: Btw, mutt would be a LOT more useful for many people if there was an additional flag for your work addresses. Example: set [EMAIL PROTECTED] "Work mails" would then show up with a 'W' and would be selectable with "~W". Then you can easily focus on your work stuff looking at new work mails with command ",W": macro index ,W "l~N ~W\n" One more for the wishlist, I guess. It isn't necessary because you can put your work alternates directly into your macros: macro index ,W "l ~N ~C ^^guckes@work\\.com$\n" "Limit to new work mails" -- Byrial
Re: just another send-hook question
On Fri, Nov 12, 1999 at 07:10:25 +0100, Richard P. Groenewegen wrote: Hi, Here's something that's either trivial or impossible. I want something like send-hook '~t [EMAIL PROTECTED]' 'whatever' but I'll only want this send-hook to work if [EMAIL PROTECTED] is the only recipient. See the section in the manual named "Pattern Modifier". send-hook '^~t [EMAIL PROTECTED]' 'whatever' On a related note: how do I limit to all messages send to [EMAIL PROTECTED] but nobody else :l^~C foo@bar\.com (or to me, but nobody else)? :l^~p -- Byrial
Re: Can there be too many color definitions?
On Fri, Nov 12, 1999 at 11:36:08 +0100, Andy Spiegl wrote: Hm, good idea, but that doesn't answer whether I found a bug in mutt. Any developers reading this? There is a maximum number of color definitions which is imposed by the terminal handling library (curses or slang). When you make a new color definition, mutt will check if the limit is reached and if this is the case it will silently use the "normal" color instead of defining a new one. -- Byrial
Re: text/plain not displayed automatically
On Fri, Nov 12, 1999 at 15:26:56 +0100, Martin Schröder wrote: Hi, when I read the attached mail mutt only displays the signature and tells me it can't find an entry for text/html. I have to view the attachments to see the text/plain part. Any idea what's going wrong? Yes. The mail is of type "multipart/alternative" with 3 parts: - The normal text/plain part - The same text in a text/html part - The signature in anoter text/plain part All 3 parts should have alternative versions of the same information, but they don't in this case. Mutt does the right thing by displaying the last of the alternative parts. RFC 2046 says: the order of body parts is significant. In this case, the alternatives appear in an order of increasing faithfulness to the original content. In general, the best choice is the LAST part of a type supported by the recipient system's local environment. -- Byrial
Re: Expire date ? - checking Expiry: - how?
On Wed, Nov 17, 1999 at 23:01:48 +0100, Sven Guckes wrote: I think Christian is asking for an automatic delete/move on messages with an explicit Expiry header line. You mean an Expires header. You will see an example in the headers of this message. But how would you check whether the expiry in that line applies? RTFM. The pattern ~E matches expired messages. -- Byrial
Re: [wish] flag 'A' for multiple attachments
On Thu, Nov 18, 1999 at 17:59:04 +0200, F.Baubetm" wrote: Some attachment types are widespread, but just glorified Signature files -- like vCards -- or auto-handled -- like PKI. Flagging them would just add clutter. Anything else is worth noting, though. (Except maybe those dopey gif's). How about a config item to specify attachment types not worth flagging ? When Mutt opens a mailbox, it doesn't read the headers of the attachments and thus don't know their type, or even how many there are. -- Byrial
Re: mutt scripting
On Sat, Dec 11, 1999 at 11:00:00 -0500, Subba Rao wrote: On 0, Edmund GRIMLEY EVANS [EMAIL PROTECTED] wrote: You mean like with: mutt -s "Subject here" 'A. Recipient [EMAIL PROTECTED]' msg_file If you try this, I think you'll find the To field gets rewritten as: To: "A . Recipient" [EMAIL PROTECTED] The above recipient specification violates RFC 822. The real name part needs to be quoted when it contains special characters such as a dot. And Mutt doesn't like wrong specifications too much. Try instead: mutt -s "Subject here" '"A. Recipient" [EMAIL PROTECTED]' msg_file When I attempted to send with the following syntax, mutt -s "Subject here" 'A. Recipient [EMAIL PROTECTED]' msg_file it was substituted as follows, 'A. Recipient [EMAIL PROTECTED], '@attglobal.net Hmm. Did you configure Mutt with --enable-exact-address? -- Byrial
Re: mutt scripting
On Sat, Dec 11, 1999 at 19:31:21 -0500, Subba Rao wrote: On 0, Byrial Jensen [EMAIL PROTECTED] wrote: On 0? Check your $attribution variable. When I attempted to send with the following syntax, mutt -s "Subject here" 'A. Recipient [EMAIL PROTECTED]' msg_file it was substituted as follows, 'A. Recipient [EMAIL PROTECTED], '@attglobal.net Hmm. Did you configure Mutt with --enable-exact-address? No, I have not used that option for compiling Mutt. I will recompile with that option and try it. Thanks for the suggesstion. It wasn't really a suggestion. I just thought that it might be because of exact-address -- which I don't use -- that I couldn't reproduce your observations. My real suggestion is to quote the name as specified in RFC 822 because it contains a dot character: mutt -s "Subject here" '"A. Recipient" [EMAIL PROTECTED]' msg_file -- Byrial
Re: Local/GMT Time Sorting/Displaying
On Tue, Jan 04, 2000 at 06:58:45 -0600, Jeremy M. Dolan wrote:
What I would like to have is:
* All message Date: headers displayed in local machine time (C[DS]T)
Mutt cannot rewrite the date header or any other headers when
displaying the message.
* Date part of message index displayed in local machine time
Change "%{%b %d}" to "%[%b %d]" in the default index_format string
and you see the send time of the messages converted to your local
time zone.
* Messages sorted by theyre local dates, no more priority given to
aussies and such =)
You can sort by send time or receive time, but the times are always
converted to the same time zone before sorting so that come in true
chronology if their time stamps are reliable.
--
Byrial
Re: Y100 (was: mutt y2k)
On Tue, Jan 04, 2000 at 16:02:45 +0100, Vincent Lefevre wrote: Fortunately, time machines don't exist. Otherwise I don't know how one could write a mail in year 99; perhaps 0099? What is the minimal year that is accepted? 1970. All times are internally stored as an unsigned integer showing the number of seconds passed since Jan 1, 1970. Mutt cannot handle times before that date. -- Byrial
Re: giving $realname precedence over $reverse_name
On Sun, Jan 09, 2000 at 23:10:31 -0800, Troy Davis wrote:
Is it possible for $realname to take precedence over $reverse_name
(essentially turning $reverse_name into just "reverse_email")?
Occasionally I receive emails to: "Troy Davis (e-mail)" [EMAIL PROTECTED]
or others where responding with that name would be strange. I'm using
1.1.1i.
Suggestions appreciated,
You could try this patch.
--
Byrial
--- send.c~ Sun Jan 9 08:24:22 2000
+++ send.c Mon Jan 10 09:31:50 2000
@@ -826,8 +826,9 @@ static ADDRESS *set_reverse_name (ENVELO
if (tmp)
{
tmp = rfc822_cpy_adr_real (tmp);
-if (!tmp-personal)
- tmp-personal = safe_strdup (Realname);
+if (tmp-personal)
+ free (tmp-personal);
+tmp-personal = safe_strdup (Realname);
}
return (tmp);
}
Re: Getting back to spoolfile
On Mon, Jan 10, 2000 at 22:18:35 +, Telsa Gwynne wrote: 'c' for change, and then '!' for your mailbox. Don't start deleting anything it gives you as a prompt after hitting 'c' (a folder with unread mail in, for example) and then hitting '!'; because that doesn't work. Are you sure? It shold work doing it that way, too. -- Byrial
Re: Output when nothing changes
On Tue, Jan 11, 2000 at 17:40:38 -0800, Larry Lipstone wrote:
I find with my mutt-1.0i running on UnixWare 2.1.3, with TERM=dtterm,
every time the timeout (or whatever) period expires and it checks for
new mail, the program emits a "make cursor visible", then stat()'s the
mail drop, then sends "make cursor invisible".
This causes my poor (yet expensive) ISDN connection to demand-dial [...]
I see the problem. The attached patch should avoid the changes of
the visibility of the cursor after timeouts. (I hope it does, but
I cannot see the difference on my screen, so please test).
The patch is usable on both the stable (1.0) and unstable (1.1.2)
versions.
--
Byrial
--- curs_main.c~Mon Jan 10 10:38:43 2000
+++ curs_main.c Thu Jan 13 11:11:33 2000
@@ -472,7 +472,8 @@ int mutt_index_menu (void)
do_buffy_notify = 1;
}
-mutt_curs_set (0);
+if (op != -1)
+ mutt_curs_set (0);
if (menu-redraw REDRAW_FULL)
{
@@ -520,8 +521,6 @@ int mutt_index_menu (void)
dprint(4, (debugfile, "mutt_index_menu[%d]: Got op %d\n", __LINE__, op));
- mutt_curs_set (1);
-
#if defined (USE_SLANG_CURSES) || defined (HAVE_RESIZETERM)
if (SigWinch)
{
@@ -537,6 +536,8 @@ int mutt_index_menu (void)
if (op == -1)
continue; /* either user abort or timeout */
+
+ mutt_curs_set (1);
/* special handling for the tag-prefix function */
if (op == OP_TAG_PREFIX)
Re: Various unimportant nitpicks
On Sun, Jan 16, 2000 at 13:58:36 +0200, Marius Gedminas wrote: On Sat, Jan 15, 2000 at 09:04:42PM +0100, Byrial Jensen wrote: On Sat, Jan 15, 2000 at 18:54:59 +0200, Marius Gedminas wrote: There is no `help' function in editor context (BTW `editor' is a very misleading name. Until today I thought it meant that mutt had a very basic (maybe like ed(1)) internal editor for composing messages :-) It has. Use "set editor=builtin" to use it. This doesn't work in 1.1.2i. After :set editor=builtin trying to edit a message results in an error from the shell I said that it was possible to *compose* messages using the builtin editor, and it is. You're right that it cannot be used to edit existing messages. There should of course be a check to see if you're trying to do that, so you can get a proper error message instead of core dumps or other strange things. I'm sure someone will post patch to repair that. -- Byrial
Re: Text substitution
On Thu, Jan 20, 2000 at 14:07:36 -0500, Jon Walthour wrote: The problem is that I can't send mail to others internally. Here's why: they have no DNS entry for their POP3 server, just an IP address. So, if I sendmail to [EMAIL PROTECTED], it disappears; if I send it to [EMAIL PROTECTED], it works. Like I said, strange. My question is this: Is it possible to set up an alias or a rule in mutt such that every time I respond to an internal email from Joe Blow with a return address of [EMAIL PROTECTED], it automatically changes it to [EMAIL PROTECTED]? No. But your MTA may have such a function. If anyone has any ideas, I'm all ears because this is driving me crazy!! I would put a line like 198.203.127.3 cpsboe.k12.oh.us in my local /etc/hosts file (or ask the system administrator to do it). Many systems search this file before trying a DNS lookup, but it is a matter of configuration and it is system dependent. -- Byrial
Re: folder-hooks, (un)ignore, and From_
On Thu, Jan 20, 2000 at 15:01:56 +0100, Byrial Jensen wrote: Except "unignore *" that just removes "*" from the ignore list if it is there, and else does nothing -- it doesn't remove all tokens from the ignore list as the manual says. Ups, in fact it does. And "ignore *" removes all tokens from the unignore list. Sorry for the confusion. -- Byrial
Re: Problems with attachments sent elsewhere from mutt
On Mon, Jan 24, 2000 at 12:18:50 -0500, Brolley, Michael wrote: When mutt reads an email from another MIME source, exchange in this case, the message looks like this: X-Mailer: Internet Mail Service (5.5.2650.21) [-- Attachment #1 --] [-- Type: text/plain, Encoding: 7bit, Size: 0.1K --] Let's see what exchange sends out. Timesheet 01-14-00.xls [-- Attachment #2: Timesheet 01-14-00.xls --] [-- Type: application/vnd.ms-excel, Encoding: base64, Size: 27K --] I see that it's sent with the MIME type "application/vnd.ms-excel". [-- application/vnd.ms-excel is unsupported (use 'v' to view this part) --] This is good on inbound mail. I can save this attached file, and Star Office can use this file as an Excel spreadsheet. No problem. You could also add an entry for "application/vnd.ms-excel" to your .mailcap file which allows Mutt to invoke Star Office with the file. The mailcap fil format is explained in Mutt's manual. I would like for mutt to do the same for outgoing mail, but when mutt sends out an email with an attachment, let's say the same spreadsheet file, I get: --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Let mutt try sending out an attachment --EVF5PPMfhYS0aIcm Content-Type: application/excel Content-Disposition: attachment; filename="Timesheet-01-14-00.xls" Content-Transfer-Encoding: base64 0M8R4KGxGuEAPgADAP7/CQAGAAABJgAA EAAA/v///wD+ACUAAAD/ ... This is not good because I cannot extract this attached file back into its original form. I don't understand that. You should be able to save the file using any mailer which understand MIME attachments. How do I configure mutt to send out email attachments the way Exchange, Netscape, Eudora, and countless other MUA's do? Mutt gave it another MIME type than exchange. Mutt gets it default MIME types from the file name extension (.xls) and your mimes.types file. Add the line application/vnd.ms-excel xls to your ~/.mime.types or a system wide mime.types file (again, see Mutt's manual) and if neccessary remove a conflicting line for the ".xls" extension. -- Byrial
Re: Problems with attachments sent elsewhere from mutt
On Mon, Jan 24, 2000 at 10:32:18 -0800, Duncan Watson wrote: The only current workaround for mutt users is to upgrade to version 1.1.1 or 1.1.2 from the development branch which deliberately constructs quoted boundaries. Also the latest stable versions of Mutt (1.0 and 1.0.1) always quote boundary specifications. -- Byrial
Re: save as sorttes
On Tue, Jan 25, 2000 at 12:30:28 -0800, Lars Thon wrote: On Wed, Jan 19, 2000 at 07:36:52PM -0800, Lars Thon wrote: Is there a way to make Mutt save a mailbox in whatever is the current sort order, or do you happen to know some other program that will permenantly sort a mailbox? Mutt always saves messages in the order they were received. I am not aware of any tool which would let you do that. You might mail to [EMAIL PROTECTED] and ask the question. You could make a macro to: 1) copy the current message to some other mailbox, 2) move the cursor to the next message 3) call itself and start it at the first message in the sorted mailbox -- Byrial
Re: Printing Problem in Mutt 0.91.1
On Tue, Jan 25, 2000 at 15:16:52 -0600, Anup N. Patel wrote: Hello, I'm using Mutt Version 0.91.1 and am having trouble printing. I tried setting the "set print_command = "lpr -Plp1", but mutt gives me the following error: "print_command: unknown variable" What is the correct configuration variable. In 0.91.1 ...hmm ... maybe print_cmd? I'm running on Linux 2.0.38. I can not upgrade to the most recent version because I'm not the sys admin here. Please give other alternatives. Thank you in advance. What about asking the sys admin to upgrade? There have been many bug fixes and new features since 0.91. -- Byrial
Re: save as sorttes
On Wed, Jan 26, 2000 at 16:30:45 +0200, Mikko Hänninen wrote: Byrial Jensen [EMAIL PROTECTED] wrote on Wed, 26 Jan 2000: You could make a macro to: 1) copy the current message to some other mailbox, 2) move the cursor to the next message 3) call itself and start it at the first message in the sorted mailbox What would cause this macro to stop? I forget, do macros stop executing if there's an error (ie. can't move further down)? I thought so when I made the suggestion. But I just tested it and inspected the source, and it seems that recursive macros can't be stopped in Mutt 1.0 -- which of course makes them useless. I'm sure that macro executing once were stopped by errors, but I didn't find any notice about this in the changelog. Does anybody know why that was changed? It would be very simple to change back. There should always be some exit condition in recursive functions... Difficult to do with Mutt's macros since there's no conditional execution. Yes, I miss a more powerfull macro language for Mutt. -- Byrial
Re: Coming back to previously _seen_ message
On Wed, Jan 19, 2000 at 13:31:09 -0200, Jorge Godoy wrote: When in a folder with new messages you can go from one to the next new message just pressing "TAB" key. How to come back to the previous new message? Use the function "previous-new". It is default unbound, but you can bind to any key at your choice in your .muttrc. For instance: bind index P previous-new bind pager P previous-new Another thing that would be very interesting it to come back to the prior message you've seen. There is as far as I know no such function in Mutt. -- Byrial
Re: folder-hooks, (un)ignore, and From_
On Thu, Jan 20, 2000 at 17:50:03 +0800, Greg Matheson wrote: X-Mailer: Mutt 0.95.7us It might help to upgrade to Mutt 1.0.1. There have been some fixes to ignore/unignore which make them work better. However don't trust the manual about this topic. Header weeding functions this way: Mutt stores internally two lists: the ignore list and the unignore list. A header is ignored if and only if it matches the ignore list and doesn't match the unignore list. So if you have these commands: ignore x- unignore x-mailer you will see x-mailer headers because it matches the unignore list. The manual says otherwise but is wrong. The ignore command adds its arguments to the ignore list and removes them from the unignore list if they are there. The unignore command adds its arguments to the unignore list and removes them from the ignore list if they are there. Except "unignore *" that just removes "*" from the ignore list if it is there, and else does nothing -- it doesn't remove all tokens from the ignore list as the manual says. -- Byrial
Re: Content-Type: message/partial ?
On Thu, Feb 10, 2000 at 00:41:12 +0200, Mikko Hänninen wrote: Hello all Mutt gurus, Just recently I got a message where the content had apparently been split into 5 separate parts (messages). The headers reveal: Content-Type: message/partial; [...] The message/partial MIME type is defined in RFC 2046. Mutt doesn't support it because nobody yet was written code to do it. Looking at the contents, it looks like it's actually a message/multipart (ie. an email with an attachment) that is split into 5 parts. Is there any way to display this message with(in) Mutt? And to reply? No. I will suggest that you copy the 5 parts in sequence to a new mbox folder, and then reassemble the original message in an editor by deleting the overhead from splitting it in parts: 1) Delete "Subject", "Message-ID", "Encrypted", and "MIME-Version" headers, and all headers starting with "Content-" from the message enclosing the first part. 2) The body of the first message/partial part contains headers too. Delete all except "Subject", "Message-ID", "Encrypted", and "MIME-Version" headers, and except headers starting with "Content-". 3) Join the headers not deleted in 1) and 2). Now you have the real headers of the message. 4) Join all of the bodies by deleting all headers lines and the blank lines between headers and bodies from the other parts. -- Byrial
Re: New mail notification
On Thu, Feb 10, 2000 at 11:57:35 +0100, [EMAIL PROTECTED] wrote: I have found a perl script to convert mbox 2 maildir and I will try to convert my old mail (if you know of any other conversion tool, please let me know). I know one called Mutt. :-) Open the mailbox to be converted, and type the command ":set mbox_type=maildir" so newly created mailboxes will be maildirs. Then tag all messages with "T." and copy them to a new maildir mailbox with ";C". -- Byrial
Re: Per mail index_format ???
On Thu, Feb 10, 2000 at 10:25:15 +0100, Tobias Wagener wrote: I have a maildir with mails of mine and mail of others. Now I want, if the mail is from me, the "index" shows the name of the one the Mails goto, and if the Mail is from someone, I want to see the name of him/her. use %F somewhere in your $index_format configuration variable. -- Byrial
Re: Slightly weird behaviour
On Fri, Feb 11, 2000 at 01:20:52 +1300, Jamie Love wrote: For example, this email will show up as from "To [EMAIL PROTECTED]" which is weird. When I read the message, the From: line has my name/email address there. I think, for some reason it's reading the To: line. Have I missed something from the manual? Yes, the section about $index_format. Anyone know how to fix this to show my email address? Change %F or %L to %f or %n in $index_format. -- Byrial
Re: Reply-To more than one recipient
On Sat, Feb 12, 2000 at 20:29:55 +0100, Horacio MG wrote: Hi, I just realized that I can specify more than one recipient in the reply-to header. 1- is this allowed (conforming to whatever rfcs)? Yes, it is allowed in RFC 822. -- Byrial
Re: Reply-To more than one recipient
On Mon, Feb 14, 2000 at 15:50:42 -0600, David DeSimone wrote: I don't remember if it is legal to put more than one address in the From: header. It is legal according to RFC 822 if and only if you also have a Sender: header which states who among the authors actually sent the message. -- Byrial
Re: color index for list mail
On Thu, Feb 17, 2000 at 23:34:34 +0200, Eric Smith wrote: Is is possible to have mail from mailing lists coloured according to a color index recipe: a la color index brightmagentablack ~l # List mail Yes. (It works. Why didn't you just tried it?) -- Byrial
Re: signature send-hook problem
On Thu, Mar 09, 2000 at 23:52:30 +0200, Mikko Hänninen wrote: And, incidentally, the best (or recommended) way of writing a pattern that matches everything is with a single dot, "." Well, I would say the canonical way to match everything is the ~Ã pattern. In fact "." is internally converted to "~A" to aviod using time parsing it as the regular expression it really is. -- Byrial
Re: [Announce] mutt-1.1.9 is out - RELEASE CANDIDATE!
On Sun, Mar 19, 2000 at 18:13:16 -0500, David T-G wrote: Can the authors or maintainers of the patches let me know if any of them are obsoleted or need to be updated, and where to get them? I'm now updating my patches (those with "bj" in their filenames) to the soon-coming Mutt 1.2. More info and descriptions will follow when I'm ready. -- Byrial
Re: Trouble getting indicator to point to first message
On Mon, Mar 20, 2000 at 17:22:01 -0500, David T-G wrote:
Well, it's noticeable to me; mutt opens up the folder, paints the index,
and then has to re-paint it from message 1. Even with "modern" fast
dialup lines, which don't always apply even for me here in the states,
it's quite noticeable.
It just seems to me that there should be a way to not point to the first
new message if you don't want to.
With the source everything is possible. :-)
One way is to edit curs_main.c, find the function ci_first_message(),
delete all code lines but the last so the function looks like this:
static int ci_first_message (void)
{
return 0;
}
Then recompile and be happy.
--
Byrial
Re: Trouble getting indicator to point to first message
On Mon, Mar 20, 2000 at 22:52:31 +0200, Mikko Hänninen wrote: Why is it a kludge? It works, it's quite simple, and it doesn't seem to add a significant overhead in the folder processing.. Maybe that you need to use "push" is a bit kludgey, since I couldn't figure out a way to invoke the jump function without it (I get "jump: unknown command" and "jump: unknown command"). I would prefer to name the jump function directly instead of relying on the key binding of "1": folder-hook . 'push jump1enter' or just as David DeSimone suggested: folder-hook . 'push first-entry' -- Byrial
Re: Trouble getting indicator to point to first message
On Mon, Mar 20, 2000 at 15:39:20 -0500, David T-G wrote: Do I incorrectly remember a point_new variable that would cause mutt to jump to the first new message, which is what most people want anyway but some don't, which is now obviously not there? Or did I make it up? :-) I'm not sure, but I think that there once was such a variable which was considered superfluous and removed. -- Byrial
Re: change width of index fields
On Fri, Mar 31, 2000 at 21:37:15 +0100, J McKitrick wrote: On Fri, Mar 31, 2000 at 09:25:26PM -0500, Michael Tatge wrote: Hi all! Does anybody know of a way to change the width of the index columns? 102 F Feb 14 To wunderkind@c ( 9) Re: HRK-Mitschnitt Deutschland ^^^ As you can see sometimes the sender/to field does not fit. Thi si sonly a hint, since i'm not exactly sure of the format. Int he format strings, you can use C-style formatting, like %15.15L will show the L field (i forget what it is) with 15 characters, i think. It's dsomething like that. That's right. The first number is the minimal width of the field, and the number after the dot is the maximal width of the field. Both numbers are optional. The dot belongs to the second number. -- Byrial
Re: help, set from=xxx
On Mon, Apr 03, 2000 at 14:51:45 -0400, Michael Tatge wrote: On Sun, Apr 02, 2000 at 10:35:29PM -0700, Neelakanth Nadgir wrote: When ever I send email to anybody in the gnu.org domain, I want my "From" address to be [EMAIL PROTECTED] I have the following set up in my muttrc file mutt complains "set: unknown variable" = send-hook '(~C gnu|~t gnu)' "set signature=~/.sig.gnu \ set [EMAIL PROTECTED] \ my_hdr Reply-To: Neelakanth Nadgir [EMAIL PROTECTED]" == You get the message "set: unknown variable" because you may set several variables in one set command, so mutt thinks that you are trying to set a variable named set. Try this: send-hook '~C gnu' "set signature=~/.sig.gnu \ [EMAIL PROTECTED] ;\ my_hdr Reply-To: Neelakanth Nadgir [EMAIL PROTECTED]" The manual says: Usage: send-hook [!]pattern command ^^^ IMHO this means you have to divide this send-hook into three separate ones. It would be technically more correct if the manual said: Usage: send-hook [!]pattern command-line where command-line is as defined in section 3.1: 3.1. Syntax of Initialization Files An initialization file consists of a series of `commands''. Each line of the file may contain one or more commands. When multiple commands are used, they must be separated by a semicolon (;). set realname='Mutt user' ; ignore x- This means that you may have several commands in hook a command; they just have to be separated with semicolons. -- Byrial
Re: [bug?] Limiting patterns and Boolean algebra
On Wed, Apr 05, 2000 at 21:34:54 +0200, Marius Gedminas wrote: Once I thought about asking for a new command -- reverse-limit. Then I realized that it was not necessary -- one could just write a macro like this: limithome!(end)enter Please find my attempt to make such a macro in the attached file: Save it, source it, and type control-l to reverse the limit pattern. So far so good. However there's a strange bug/feature: foo limits to messages matching pattern foo !(foo)limits to messages not matching pattern foo !(!(foo)) limits to messages not matching pattern foo too! But (!(!(foo))) limits to messages matching pattern foo Might be a bug, I can't say for sure. -- Byrial # Mutt macro "reverse limit" bound to ^l macro index escescl1 \ 'enter-commandmacro index \cl "limit\ .backspacebol!(.backspaceeol)\ .backspaceenter.backspaceesc.backspaceescl2" \ "reverse limit pattern"\ enter' \ "reverse limit help macro 1" macro index escescl2 \ 'enter-commandmacro index \cl "limit\ .backspacebackspace.backspacebol\ .backspacedelete-char.backspacedelete-char\ .backspaceenter.backspaceesc.backspaceescl1" \ "reverse limit"\ enter' \ "reverse limit help macro 2" macro index \cl \ "limitbol!(eol)enterescescl2" \ "reverse limit"
My patches are updated to Mutt 1.2
On Sun, Mar 19, 2000 at 18:13:16 -0500, David T-G wrote: Hi, folks -- Now that I can build because I have a working compiler (sorry for the noise :-) I would like to look into my favorite feature patches. I use patch-0.94.13.bj.current_shortcut.1 patch-0.95.3.bj.ed_mtime.1 patch-0.95.3i.bj.keyattach.1 patch-0.95.4.bj.status-time.1 patch-0.95.bj.hash_destroy.2 patch-0.95.bj.noquote_hdr_term.1 [snip - patches made by other people] Can the authors or maintainers of the patches let me know if any of them are obsoleted or need to be updated, and where to get them? The keyattach patch have been included Mutt in 1.2. Please find updated versions of the other patches at URL: http://home.worldonline.dk/~byrial/mutt/patches/. There you will now find these patches for Mutt: patch-1.2.bj.current_shortcut.1: This patch will make the ^ character a shortcut for the currently open mailbox. patch-1.2.bj.ed_mtime.1: When you leave the editor, mutt will check if the edited file's modification time have changed to decide if the file has been modified. This means that it you are able to modify it in less than one second (e.g. by running a script to generate some text), Mutt may think that it is unmodified. This patch solves this problem by seting the time stamp of a new file to one second ago' before calling the editor. patch-1.2.bj.noquote_hdr_term.1: Don't quote the header terminator when replying with headers. patch-1.2.bj.status-time.1: You can show the current time in your preferred format in the status line with this patch. See the $status_format and $status_update configuration variables in the patched manual for details. patch-1.2.bj.my_hdr_subject.1: Use this patch: - To execute sendhooks before setting subject to make it possible to set the subject in a sendhook. The price is that you miss the possibility to let the sendhook depend upon the subject. - To let "my_hdr Subject" commands be controlled by $hdrs. Now $hdrs only controls all other kinds of my_hdr commands. - To let sendhooks work in batch mode. Thank you to Rob Reid for fixing a bug in a previous version of this patch. patch-1.2.bj.hash_destroy.1 This patch will speed up a little bit closing of mailboxes. Regards, Byrial P.S. I have recently had some trouble sending mail to the Mutt mailing lists. Will you please forward this message to mutt-users if you don't see it there 1 or 2 days after you received it. Thank you.
Re: I want a different sort of macro
On Tue, May 23, 2000 at 14:00:34 +0100, Chris Green wrote: I want to be able to have macros that will expand to such things as domain names which can be used anywhere. For example I send a lot of mail to *different* users at both my work domain (kbss.bt.co.uk) and my home domain (isbd.demon.co.uk). It would be nice if I could set up (two character?) macros that would expand to these domains rather than having to type them in every time. You can. Try for example these macros: macro editor ?w @kbss.bt.co.uk macro editor ?h @isbd.demon.co.uk The existing macro facility doesn't help because the macros are only detected at the beginning of any command. No, editor macros are detected anywhere when you are typing in response to one of Mutt's prompts. -- Byrial http://home.worldonline.dk/~byrial/
Re: f1 mutt help
On Fri, May 26, 2000 at 15:38:43 -0400, Hardy Merrill wrote: In /etc/Muttrc, I only have the "mutt-1.0i" directory - I don't have mutt-1.2. That was something I was wondering about - why didn't the install give me a /usr/doc/mutt-1.2 directory? If you didn't told the configure script to do otherwise, then you will find the manual and other documentation in /usr/local/doc/mutt/, and the system wide configuration script as /usr/local/etc/Muttrc. -- Byrial http://home.worldonline.dk/~byrial/
Re: HTML being filtered?
On Mon, May 29, 2000 at 19:55:23 -0500, Alex Lane wrote: Recently, a gentleman made a post that was so flamed. In reviewing the post, I find no html code in the thing, no message from mutt that I oughta press 'v' to view an html-encoded message, nothing. One clue that makes no sense to me is that the offending post on the list was a multipart post, one part text; the other, html. An examination of the entire (?) message shows no multiple parts. I guess that it was a multipart/alternative post where each of the body parts (in this case of types text/plain and text/html) is an alternative version of the same information. Mutt will only show you one of the parts of a multipart/alternative message (see section 5.5 in the manual about which one), but you can see them all from the attachment menu (press 'v' in the pager to get there). -- Byrial http://home.worldonline.dk/~byrial/
Re: [OT-ish] HTML being filtered?
On Tue, May 30, 2000 at 13:01:46 -0500, Aaron Schrab wrote: At 11:12 -0500 30 May 2000, Ronny Haryanto [EMAIL PROTECTED] wrote: an RFC (about multipart or MIME, I can't remember exactly) suggests that the last text/plain part be shown if all of the parts are of the same type. Please correct me if I'm wrong. Actually, mailers are supposed to prefer the last alternative that they can handle, regardless of type (RFC 2046, section 5.1.4). And so does Mutt, of course. Or more precise: 1) The alternative_order list is searched, and the first item on the list which matches one or more alternative parts is used, and the last part matching the used entry is chosen. 2) If no part is chosen, then the last part which can be autoviewed is chosen. [A part can be autoviewed if: a.1) $implicit_autoview is set, or a.2) the environment variable MM_NOASK is defined to "1" or to a list of MIME types where one matches the type the part, or a.3) it is on the auto_view list. and b) a suitable mailcap command for the type is found.] 3) If no part is chosen, then the last part of type text/enriched is chosen. 4) If no part is chosen, then the last part of type text/plain is chosen. 5) If no part is chosen, then the last part of type text/html is chosen. 6) If no part is chosen, then the last part of a type which Mutt can handle fully or partially is chosen (for example message/rfc822 and multipart/* parts). 7) If still no part is chosen, Mutt gives up and gives an error message. If anybody wants to include this stuff in the manual (section 5.5), please go ahead. -- Byrial http://home.worldonline.dk/~byrial/
Re: From_ line
On Tue, Jun 06, 2000 at 21:11:57 +0300, Baurjan Ismagulov wrote: hi, thanks for the reply. seems that i've been somewhat unclear in stating the problem. my problem is NOT "how to show/hide specific headers", but rather "how to retain the original From_ line". There is no such thing as "the original From_ line". The From_ line does NOT belong to the message, but is a part of the mbox mailbox format where is marks where a new message begin. If you store your messages in a maildir mailbox there is no From_ line at all. -- Byrial http://home.worldonline.dk/~byrial/
Re: quick charset toggle
On Thu, Jun 08, 2000 at 12:15:55 +0300, Baurjan Ismagulov wrote: hi, i have to change my charset frequently. currently, i'm typing ":set cTAB="charset (occasionally, "charset" is the first keyword completed). but after that i have to type "iso-8859-9" and "koi8-r" manually each time, which is quite annoying. how can i speed up this process? You could use macros to change charset. One for each charset: macro index EscTI 'set charset=iso-8859-9' 'Change to iso-8859-9' macro index EscTK 'set charset=koi8-r' 'Change to koi8-r' It is also possible to make a real toggle. This example uses an external script: macro index EscT 'set charset=`charset-toggle`' 'Toggle charset' where "charset-toggle" contains something like: #!/bin/sh # Find the current charset: if test -f charset; then charset=`cat charset` else charset=koi8-r fi # Toggle to the other charset: if test $charset = koi8-r; then charset=iso-8859-9 else charset=koi8-r fi # save and output the new value: echo $charset charset echo $charset btw, i still can't mix two languages in the single message. mime gurus? If you use UTF-8, you can mix any languages. -- Byrial http://home.worldonline.dk/~byrial/
Re: PDF viewing question
On Thu, Jun 08, 2000 at 07:49:04 -0400, Randall Hopper wrote: I want to autoview PDFs, but also be able to kick off acroread. Autoview works, but I can't figure out how to kick off acroread in mutt. In my .mailcap I have: application/pdf; pdf2txt %s; needsterminal; copiousoutput application/pdf; acroread %s The first should be used for autoview. And the second should be used for view-attach, right? However view-attach also uses pdf2txt The first usable mailcap entry is always used. Try to reverse the two lines. -- Byrial http://home.worldonline.dk/~byrial/
Re: PDF viewing question
On Thu, Jun 08, 2000 at 14:59:21 +0200, Roland Rosenfeld wrote: BTW: does it make sense to combine "needsterminal" and "copiousoutput" in one mailcap entry? As far as I understand they are quite contrary, because "needsterminal" needs a terminal with user input while "copiousoutput" pipes the output to some kind of pipe. Right. RFC 1524 which describes the mailcap file format, says: -- The "needsterminal" field indicates that the view-command must be run on an interactive terminal. This is needed to inform window- oriented user agents that an interactive terminal is needed. (The decision is not left exclusively to the view-command because in some circumstances it may not be possible for such programs to tell whether or not they are on interactive terminals.) The needsterminal command should be assumed to apply to the compose and edit commands, too, if they exist. Note that this is NOT a test -- it is a requirement for the environment in which the program will be executed, and should typically cause the creation of a terminal window when not executed on either a real terminal or a terminal window. -- The "copiousoutput" field indicates that the output from the view-command will be an extended stream of output, and is to be interpreted as advice to the UA (User Agent mail-reading program) that the output should be either paged or made scrollable. Note that it is probably a mistake if needsterminal and copiousoutput are both specified. -- Byrial http://home.worldonline.dk/~byrial/
Re: muttrc.el
On Thu, Jun 15, 2000 at 06:19:04 -0600, Charles Curley wrote: On Thu, Jun 15, 2000 at 01:07:21AM +0100, Dave Pearson wrote: On Wed, Jun 14, 2000 at 04:45:52PM -0600, Charles Curley wrote: While scrounging through the new mutt, 1.2, I found evidence of a muttrc mode for Emacs. The evidence was this at the beginning of one of the sample files: # -*-muttrc-*- It isn't necessarily evidence of an Emacs mode. The -*- tags are also used by jed, and a muttrc mode for jed exists. P.S. Please don't use non-standard $indent_string. It prevents editors with mail modes (like jed) from rewrapping long lines in quotes while preserving the quote characters. -- Byrial http://home.worldonline.dk/~byrial/
Re: Adding a header with information taken from the message
On Thu, Jun 15, 2000 at 14:06:49 +0200, Roberto Suarez Soto wrote:
set in_reply_to=\
"%i; from %a on %{!%a, %b %d, %Y at %I:%M:%S%p %Z}\nX-Comment-To: %n"
Can this harm anything? I mean, some rfc stuff or the like :-?
No, I don't think so.
[NB: Mail-Followup-To header ignored. I normally see no reason to
send private copies of list replies, and the wish may even come
from a misconfiguration (use of 'lists' instead of 'subscribe' in
muttrc).]
--
Byrial
http://home.worldonline.dk/~byrial/
Re: mutt 1.0.1us as an imap client
On Thu, Jun 15, 2000 at 13:23:13 -0500, Enrique Vadillo wrote: Hi, I'm trying to use mutt 1.0.1us with courier-imap using maildirs, I would advice you to get Mutt 1.2 which have several enhancements in IMAP support over 1.0. You could also wait a few days and get the soon-coming bugfix release 1.2.1. I would like to know how i can configure my mutt to work with either imap (i've compiled it with --enable-imap) or as a localhost mail reader reading directly from qmail'sMaildirs. BTW do you see any problem/advantage with either implementation? No, Mutt works fine with both maildirs and IMAP. -- Byrial http://home.worldonline.dk/~byrial/
Re: [bug?] pager_index_lines
On Thu, Jun 15, 2000 at 20:13:24 +0200, Marius Gedminas wrote: Today a strange thing occured to me: setting pager_index_lines to 4 or 10 (I have macros for this) gave me just one index line on top. If there only is one message in your mailbox, you will only get one index line. If there is more messages this should not happen. Can you give a recipe to reproduce it? -- Byrial http://home.worldonline.dk/~byrial/
Re: upgrading using diffs
On Thu, Jun 22, 2000 at 22:36:49 +0200, Meinolf Sander wrote: Hello, I tried to upgrade from mutt 1.3.2 to 1.3.4 by applying the diff patches to the 1.3.2 source code. It worked well with diff-1.3.2i-1.3.3i but failed with diff-1.3.3i-1.3.4i: I got many rejects, almost all hunks failed and the sources didn't compile. I have applied all patches from 1.2 - 1.3 - 1.3.1 - 1.3.2 - 1.3.3 - 1.3.4 without any problems with the program code. There have however been some minor problems with the Changelog and some .po files. I used the command "patch -p1 --force diff*. Is there anything wrong with this command or might the latest diff be corrupted? Yes, use -p1 if you are in the catalog with the mutt sources when you apply the command. But don't use --force. If the patch program asks about something or complains without --force, something is wrong, and you should be told rather than force patch to continue. It is impossible to tell why your patching failed without more details, but always: - make sure that you have a clean version before patching to the next version, i.e. - be sure not have any third part feature patches or the like applied when upgrading - apply the patches in the correct order, and each only once, if you upgrade several versions at once. -- Byrial http://home.worldonline.dk/~byrial/
Re: upgrading using diffs
On Fri, Jun 23, 2000 at 03:20:52 +0200, Meinolf Sander wrote: Hello Byrial, Which "patch" options exactly did you use to upgrade? Nothing but -p1. I've taken into account these things and patched without --force, but it still doesn't work. I guess that your starting point when isn't a/the right unchanged version of mutt. I really don't know what's going wrong there - I think it should be okay to patch the 1.3.2 source code first with the 1.3.3 diff, after this with the 1.3.4 diff and then to compile it (but unfortunately it doesn't). Any ideas? Something like this should in principle work (using GNU tar and zcat): $ tar xzf /path/to/mutt-1.2i.tar.gz $ mv mutt-1.2 mutt-1.3.4 $ cd mutt-1.3.4 $ zcat /path/to/diff-1.2i-1.3i.gz | patch -p1 $ zcat /path/to/diff-1.3i-1.3.1i.gz | patch -p1 $ zcat /path/to/diff-1.3.1i-1.3.2i.gz | patch -p1 $ zcat /path/to/diff-1.3.2i-1.3.3i.gz | patch -p1 $ zcat /path/to/diff-1.3.3i-1.3.4i.gz | patch -p1 $ ./configure $ make However, there still will be trouble with some files (Changelog, build-release and some po/*.po files) for the reasons Roland Rosenfeld told about in another message in this thread. You can either ignore the rejects if you don't need the concerned .po files, or look at the .rej files and try to do the patching in your editor. -- Byrial http://home.worldonline.dk/~byrial/
Re: Command line
On Wed, Jul 05, 2000 at 14:11:36 -0700, Marianne Albin wrote: you would just use mail, but there are many command line options to send the mail via mutt, but the editor still will open Mutt will send mail in batch mode if its standard input isn't a terminal: $ echo "a one line message" | mutt -s "subject" [EMAIL PROTECTED] $ mutt mutt -s "subject" [EMAIL PROTECTED] file-with-message-text -- Byrial http://home.worldonline.dk/~byrial/
Re: set variable according to some (other) variable
On Sat, Jul 15, 2000 at 01:16:39 +0100, Tommy Wareing wrote:
I'm trying to work out whether I can create a single macro to toggle
index format between two values.
Currently, I've got two keys bound:
macro index "\Cw" ':set index_format="%4C %Z %{%b %d} %-15.15L (%4l) %s"^M' "View
Lists"
macro index "\Ca" ':set index_format="%4C %Z %{%b %d} %-15.15F (%4l) %s"^M' "View
Sender"
But is it possible to do this in one?
Yes. For instance like this:
macro index "\Cw" \
':set index_format="%4C %Z %{%b %d} %-15.15L (%4l) %s"; \
macro index "\Co" "\Ca" "View Sender"enter' \
"View Lists"
macro index "\Ca" \
':set index_format="%4C %Z %{%b %d} %-15.15F (%4l) %s"; \
macro index "\Co" "\Cw" "Viev Lists"enter' \
"View Sender"
set index_format="%4C %Z %{%b %d} %-15.15F (%4l) %s"
macro index "\Co" "\Cw" "View Lists"
# ^W will change ^O to call ^A, and
# ^A will change ^O to call ^W,
# so ^O will act like a toggle.
--
Byrial
http://home.worldonline.dk/~byrial/
Re: multipart/alternative formatting
On Fri, Jul 14, 2000 at 21:00:21 -0700, Anton Graham wrote: I still think that text/plain should be just that: plain :) It is. The Quoted Printable encoding must not have lines longer than 76 characters, and the encoder have to insert the soft breaks when it encodes longer lines then that. The receiving end must remove these soft breaks to recreate the original long line. See RFC 2045 section 6.7 for a precise description of this. Yes, I understand that, and appreciate it when receiving preformatted data as it shows me that the line is a continuation of the previous without requiring me to scroll right through a 230 character line. In fact there is a proposal for a standard to send plain text in which each paragraph may be rewrapped by the receiving MUA. It uses the context type "text/plain; format=flowed". Mutt doesn't support this, but it may be a good idea to implement it. "The Text/Plain Format Parameter" is described in RFC 2646. Actually, the '=' seems to be hanging at the end without a trailing space on the ones I receive. (And you're right, I don't need the /g, it's there through force of habit :) There should not be trailing space on any line encoded with Quoted Printable, and if the decoder anyhow sees trailing space on a line, it must delete it. Mutt's QP decoder is unfortunately buggy with respect to this. -- Byrial http://home.worldonline.dk/~byrial/
Re: Ispell with different languages
On Tue, Aug 15, 2000 at 19:51:16 +0300, Mikko Hänninen wrote: I don't know if ispell supports getting the text from STDIN, but if it does you can use | to pipe the current text into it instead, I guess. It doesn't as far as I know. But you can with advantage use my program newsbody as a filter between Mutt and ispell. The following examples are taken the programs README file: | Examples: | | Use newsbody to call ispell from the Mutt mailer, but don't | spell check your quotes (they should not be changed) or your | signature. | | Method 1 using Mutt's built-in ispell command: | - Make a shell script with this command: |newsbody -hqs -n $2 -p ispell -- -x %f | - Make Mutt's ispell command call the script by means of this |command in your .muttrc: |set ispell=path/to/script | | Method 2 using a filter: | - Define this Mutt macro in your .muttrc: |macro compose i \ |"filter-entrynewsbody -hqs -n - -p ispell -- -x %fenter" \ |"run ispell on the selected part" You can find newsbody as part as the spellutils package at URL: http://home.worldonline.dk/~byrial/spellutils/. BTW. The Mutt translator teams may find the other program in the package (pospell) useful. -- Byrial http://home.worldonline.dk/~byrial/
Re: Documentation bug regarding `date_format'?
On Thu, Aug 17, 2000 at 09:42:15 +0100, Dave Pearson wrote: According to section 6.3.27 of the mutt manual (I'm running 1.2.5i here) the variable `date_format' "controls the format of the date printed by the ``%d'' sequence in ``index_format''". Further, section 6.3.73 says that the %d and %D sequences display the date and time of a message "in the format specified by ``date_format''". However, it would appear that `date_format' doesn't (quite rightly?) work for all uses of the `index_format' sequences. Would it? Not to me. For example, `date_format' does affect the output of `attribution' (the documentation of which points the reader to the documentation for `index_format'). Yes, "date_format" does affect the output of "attribution" if the "attribution" string contains %d or %D sequences. Is this a documentation bug? I don't see any bug here. -- Byrial http://home.worldonline.dk/~byrial/
Re: Images in the body of an e-mail.
On Thu, Aug 24, 2000 at 20:17:59 +0100, Bruno Postle wrote: I guess the problem is probably that when you attach an image in mutt it uses 'Content-Disposition: attachment' in the mime headers whereas netscape (for example) uses 'Content-Disposition: inline'. You can decide yourself if any attached files are marked as attachment or inline by using the toggle-disposition command in the compose menu; it is by default bound to ^D. [NB. Mail-Followup-To: header ignored - I answer list messages on the list or private - but not both]. -- Byrial http://home.worldonline.dk/~byrial/
Re: Cancel commands
On Thu, Sep 07, 2000 at 20:57:50 +0200, Jens Askengren wrote: Hello Since I often find myself hitting ^C (instead of ^G) to cancel commands that prompts for input like "mail" and "limit", I would like to rebind that function. You cannot[1]. This isn't controlled by mutt, but by the terminal handling library (ncurses or slang). [1] Yes, with the source anything is possible of course. If you use slang you could for instance change the assignment to SLang_Abort_Char in one of first lines of the source file slgetkey.c. It seems like it's imposible to bind ^C at all. Is this correct? You can bind ^C as told in other replies, but then not to the abort function... -- Byrial http://home.worldonline.dk/~byrial/
Re: mutt.vcard.filter
On Sat, Sep 09, 2000 at 00:30:05 -0700, Jason Helfman wrote: mutt.mailcap text/x-vcard; mutt.vcard.filter; cat -v; copiousoutput Stefan Frank already answered the question, but this mailcap entry is wrong. I suppose you mean: text/x-vcard; mutt.vcard.filter | cat -v; copiousoutput -- Byrial http://home.worldonline.dk/~byrial/
Re: mutt.vcard.filter
On Sat, Sep 09, 2000 at 12:37:08 -0700, Jason Helfman wrote: I have this and it works now text/x-vcard; mutt.vcard.filter; cat -v; copiousoutput Sure, but the field "cat -v" has no meaning and is ignored as any field with unknown keyword after the command field is. Semicolons within the command must be quoted with backslashes, but if you intend to send the output from mutt.vcard.filter thru "cat -v" I still | [...] suppose you mean: | | text/x-vcard; mutt.vcard.filter | cat -v; copiousoutput -- Byrial http://home.worldonline.dk/~byrial/
Re: Mutt 1.2.5i SegFault and core dumps
On Sat, Sep 16, 2000 at 19:02:32 +0200, Zak Le Roux wrote: Forgot to add the CORE DUMP file (gzipped) ... sorry ! We cannot use the core file without having exactly the same environment and the executable file as where it was made. You can however help by analyzing the core with the gdb debugger and sending the results. A good start would be the following gdb commands: $ gdb mutt core (gdb) bt (gdb) info locals (gdb) quit $ Please also send the output of "mutt -v" Permissions on Mutt files are as follows:- /usr/local/bin/mutt rootroot-rwxr-xr-x /usr/local/bin/mut_dotlock rootmail-rwxr-xr-x Are these OK ? No. If you have and use mutt_dotlock (with double t) it should be setgid mail (i.e. permissions -rwxr-sr-x). -- Byrial http://home.worldonline.dk/~byrial/
Re: Ummm... PGP signature could NOT be verified.
On Thu, Sep 21, 2000 at 10:22:20 +0100, Dave Ewart wrote: I'm not sure that's the cause of the error message in this case - I noticed the message change from "PGP signature verified OK" (or whatever it says) to "PGP signature could NOT be verified" when verifying THE EXACT SAME MESSAGE after upgrading from Mutt 1.2.x to Mutt 1.3.7 ... nothing in the PGP config had been changed. Guess some bug got introduced in the 1.3.x series? Older versions of Mutt did only check the exit code from the pgp or gpg invocation, and would say that the signature had been succesfully verified if it was zero. Pgp however returns with a zero exit code even when it cannot verify the signature, so this was clearly wrong. Therefore the $pgp_good_sign variable was introduced, and at the same time the "PGP signature could NOT be verified" message. But it seems that there is a bug so this message always will come when an encrypted message is decrypted no matter if it is unsigned or signed with a good or bad signature. I will look at it and try to make a fix. [PS. Mail-Folllowup-To header ignored. You probably have a "lists" command which should be changed a "subscribe" command"]. -- Byrial http://home.worldonline.dk/~byrial/
Re: Is it possible to check multiple pop3 hosts
On Thu, Sep 21, 2000 at 14:46:17 +0100, housebee wrote: I have read the FAQ but could not find any help matching my problem. I hope someone can help me to make it able for me to check more than one pop3 hosts. You could make a macro with something like this (untested): macro index G \ "enter-commandset pop_host=host1 pop_user=login1 pop_pass=pass1enter\ fetch-mail\ enter-commandset pop_host=host2 pop_user=login2 pop_pass=pass2enter\ fetch-mail\ enter-commandset pop_host=host3 pop_user=login3 pop_pass=pass3enter\ fetch-mail" \ "Fetch mail from my 3 pop3 accounts" -- Byrial http://home.worldonline.dk/~byrial/
Re: Lists v. Subscribe?
On Thu, Sep 21, 2000 at 12:05:21 -0500, Ben Beuchler wrote: On Thu, Sep 21, 2000 at 01:21:29PM +0100, Dave Ewart wrote: [PS. Mail-Folllowup-To header ignored. You probably have a "lists" command which should be changed a "subscribe" command"]. Ah - well spotted, Sir. Is that better now? Yes. I still don't understand the difference between "lists" and "subscribe". When should each be used? I've always just added all my lists to both commands... Use "subscribe" to tell Mutt about mailing lists you are subscribed to. When you post to a subscribed list, mutt will generate a Mail-Followup-To header which says that followups only should be sent to the list. Use "lists" to tell Mutt about mailing lists you are not subscribed to. When you post to an unsubscribed list, mutt will generate a Mail-Followup-To header which says that followups should be sent both to you and to the list. Please see the manual for the glory details. Section 3.9 Mailing lists and section 4.8 Handling Mailing Lists. -- Byrial http://home.worldonline.dk/~byrial/
Re: perl script programming problem
On Fri, Sep 22, 2000 at 15:40:04 +0300, Mikko Hänninen wrote: hal King [EMAIL PROTECTED] wrote on Fri, 22 Sep 2000: Yes, I know there is a python script, but I like perl and wanted to hack mutt. Odd thing is, after the script runs input seems to be 'hung'. I after the process has gone back to mutt, I have to hit a key before I get any command to mutt. I've closed STDIN, STDOUT and the alias file. What am I missing? Normally you should never open or close stdin or stdout in a program. All you need to do, is to read stdin until you reach end-of-file. Try changing the value of $wait_key, if you have it set. You should also know that mutt always will wait if the program returns a non-zero exit code regardless of the value of $wait_key. -- Byrial http://home.worldonline.dk/~byrial/
Re: perl script programming problem
On Fri, Sep 22, 2000 at 14:31:40 -0400, hal King wrote: I tried that, and now knowing what to look for tried several others: macro pager T "pipe-message/home/hck/bin/take.plenterenter-commandsource $HOME/.muttrc\n" macro pager T "pipe-message/home/hck/bin/take.pl\nenter-commandsource $HOME/.muttrc\n" macro pager T "| $HOME/bin/take.pl\n:source $HOME/.muttrc\n" These including useing single quotes, But each time when I return to mutt it asks: "create ource/u04/hck/.muttrc? ([y]/n)" $HOME is /u04/hck So mutt is executing 's' (save) ource/u04/hck/.muttrc which does not exist, so it asks. Has anyone seen this before? My guess is that $wait_key is set and/or take.pl returns a non-zero exit code. Then the following "enter-command" token or ":" will be eaten by an invisible "Press any key to continue..." prompt, and the following "s" will be interpreted as you see. -- Byrial http://home.worldonline.dk/~byrial/
Re: catchup command?
On Sat, Sep 23, 2000 at 01:33:36 -0700, Peter Jaques wrote: i'm looking for some command that will mark all messages in a current mailbox as being read, without having to actually read them. sort of like ^R but for an entire mailbox ( not dependent on threading). is there a such? Tag all messages, mark the tagged messages read, and finally untag them. Can be bound to macro if you like, for example: macro index R "T~Aenter;WN;t" "Mark all messages read" -- Byrial http://home.worldonline.dk/~byrial/
Re: Q: Why no replies to my post??
On Tue, Sep 26, 2000 at 09:38:49 +0100, Dave Ewart wrote: I'd appreciate any insights as to why my posting got no response! Well, one of the reasons could be that you post about problems with Mutt 1.3.x here at the mutt-users list. The 1.3.x series are development versions which are not considered ready for common use, and questions about these should be discussed at the mutt-dev list. Another reason could very well be that nobody here have seen this problem or can explain why you have it. I can not either, but I presume that it would be interessting to know (on the mutt-dev list): - the value of the $charset variable - the charset indication of the messages which doesn't show correctly - the current locale - the used libc or libiconv versions -- Byrial http://home.worldonline.dk/~byrial/
Re: Aborted unmodified message.
On Wed, Sep 27, 2000 at 22:57:14 +0300, Mikko Hänninen wrote: I don't know the exact details (haven't looked at the source), but I would guess that the way Mutt starts an external program is with the system() sytem-function-call. Mutt has its own implementaion of system() to have better control on signal handling and redirection. It uses execl() like this to execute a program: execl (EXECSHELL, "sh", "-c", cmd, NULL); EXECSHELL can be set with the configure script, and the compiled-in value can be seen with "mutt -v". I advise to check this as a bad value for EXECSHELL can prevent Mutt from executing any external program. -- Byrial http://home.worldonline.dk/~byrial/
Re: Forcing reply to include HTML messages...
On Wed, Sep 27, 2000 at 19:55:34 -0600, Benjamin Korvemaker wrote: My brother sent me a message that was ONLY html encoded (he won't be doing that again). Replying to it and having it include his message was a bit of a challenge, though. Because it was only html, mutt wasn't including it in my response when I used "r" to reply. If you have a suitable mailcap entry for text/html, for example: text/html; lynx -force_html -dump %s ; copiousoutput and enable auto_view for text/html or set $implicit_autoview (see for example section 5.4 in the manual), then mutt will have no problems with including the answered message. -- Byrial http://home.worldonline.dk/~byrial/
Re: Aborted unmodified message.
On Wed, Sep 27, 2000 at 18:42:38 -0400, David T-G wrote: Yep, that was what I meant. Did you try a simple :set shell=/sbin/sh from within mutt? Did you try :set ?shell to see what mutt thinks $shell is holding? The $shell variable is /only/ used for the shell-escape command (default bound to ! in all menus), so this is not relevant for this case. Check instead that EXECSHELL have an absolute path to a valid shell like this: $ mutt -v | grep EXECSHELL EXECSHELL="/bin/sh" $ EXECSHELL is used for caling all external programs (including the $shell shell when using the shell-escape command). It defaults to /bin/sh, but can be changed when mutt is configured with "./configure --with-exec-shell=EXECSHELL". Se the INSTALL file for reasons to do that. How interesting... With a valid $shell setting you can't even !ls This doesn't require a valid $shell (try to set $shell to some bad value and try it - it still works if it worked before), but it certainly require a valid EXECSHELL. -- Byrial http://home.worldonline.dk/~byrial/
