mutt/2808: changed / added %-expansion in save-hook

[utcke+mutt]

>Number: 2808
>Notify-List:
>Category:   mutt
>Synopsis:   changed / added %-expansion in save-hook
>Confidential:   no
>Severity:   minor
>Priority:   low
>Responsible:mutt-dev
>State:  open
>Keywords:   
>Class:  sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 01 10:28:13 +0100 2007
>Originator: Sven Utcke
>Release:1.5.13
>Organization:
>Environment:
Linux, Solaris
>Description:
when upgrading from 1.4.1 to 1.5.13 (mostly so that I would get header caching 
with IMAP) I noticed that the following line now triggers an error:

  fcc-save-hook [EMAIL PROTECTED] =karsten.ottenberg

  Error in /home/utcke/.mutt/fcc, line 132: error in pattern at: karsten%phifo@
germany.eu.net

However, the man-page makes no special mention of '%' as an active character in 
patterns, and the above is a valid address according to RFC822.  So either this 
is a software bug, or a duplicate of 2135 (hard to tell without a documentation 
of the intended behaviour).
>How-To-Repeat:
:fcc-save-hook [EMAIL PROTECTED]
>Fix:
If this is the intended behaviour, than it should be documented and an 
escape-character should be specified (neither \% nor %% work).
>Add-To-Audit-Trail:

>Unformatted:

Re: What's needed for mutt 1.6?

[Lars Hecking]

 
> It would also be nice to have mechanisms to simplify composing  
> multipart/alternative e-mail.

 Can you show me one single case where using multipart/alternative is
 justified and actually makes any sense? It's bad enough to receive
 bloated text+html email from clueless Outlook users, I don't want to
 see such mail from mutt users, too.

Re: Updating the manual

[Michael(tm) Smith]

Brendan Cully <[EMAIL PROTECTED]>, 2007-02-28 08:49 -0800:

> On Wednesday, 28 February 2007 at 09:47, Rocco Rutte wrote:
> > Also, I think the current way of creating it is not very optimal since I 
> > (still) consider DocBook a format which is to be generated by machines, 
> > not written by humans (please no flamewar on that one! :)

I'm one of the maintainers of the DocBook XSL stylesheets, so I
wanted to jump in and make a case for the value of continuing to
use those as part of the doc build.

First off, I want to say that the source for the docs does not
necessarily need to be maintained in DocBook XML in order for make
use of the DocBook XSL stylesheets in the doc build. You could
maintain the source in asciidoc and still get the benefits of the
DocBook XSL stylesheets -- the build would just need to include an
intermediate step that converted from that form to DocBook XML. I
think the asciidoc command can do that.

And far as the benefits of using the DocBook XSLT stylesheets, the
one big benefit is that it provides you with a lot of options
about how you want your content rendered -- across a wide variety
of output formats (HTML, PDF, groff/troff man pages). And though
some other tools provide better output for specific formats (LaTeX
provides higher-quality PDF output, native authoring in groff
provides better man-page output), I don't think there is another
tool that provides the same level of high-quality output across
all those formats.

> > Just a very stupid idea: why not play with asciidoc a little? It should 
> > do all what we want, we could finally simplify makedoc a lot and still 
> > get all output we want. Plus: the manual would be much easier to hack 
> > on, much smaller in size, etc. With some XSLT magic I think it could be 
> > more or less easy to create an initial asciidoc-based document.
> 
> I'm for it. About halfway through your email I thought I was going to
> have to write a 'why not asciidoc?' response :)

One reason why not would be to make sure that asciidoc could
actually provide the same level of semantic markup to capture the
semantics of the current manual marked up in DocBook, and to do it
in a way that does not end up making the source document even
harder to read than it is in DocBook form.

There are many elements in DocBook for which asciidoc doesn't have
equivalent markup. And though asciidoc does in fact provide a some
degree of sophistication for marking up your content semantically,
in my experience at least, if you use very much of it, you end up
with source that looks at least as arcane as, say, a groff/troff
source document -- and the only way you or anybody else who looks
at the file is going to remember what the markup means is by
looking at it side-by-side with the asciidoc user guide to try to
decipher it.

But it may well be that the current mutt manual does not contain
the level of inline markup that would require some of the more
arcane stuff from asciidoc.

  --Mike

-- 
Michael(tm) Smith
http://people.w3.org/mike/

mutt/2809: wish: collapse sub-thread

[Michael . Tatge]

>Number: 2809
>Notify-List:
>Category:   mutt
>Synopsis:   wish: collapse sub-thread
>Confidential:   no
>Severity:   minor
>Priority:   low
>Responsible:mutt-dev
>State:  open
>Keywords:   
>Class:  change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 01 12:16:26 +0100 2007
>Originator: Michael Tatge
>Release:
>Organization:
>Environment:
>Description:
There are several sub-thread function. ,
, and so on. But what I'm missing is
 this would be really useful particularly with "monster 
threads" that fill a few pages.
>How-To-Repeat:
>Fix:
Unknown
>Add-To-Audit-Trail:

>Unformatted:

Re: What's needed for mutt 1.6?

[Michael Tatge]

* On Thu, Feb 22, 2007 Brendan Cully ([EMAIL PROTECTED]) muttered:
> I'd like to hear once again which patches everyone would
> like to see in 1.6 (and which patches people object to).

Not patches per se, but I'd like to see
mime_lookup application/octet-stream
and
use_envelope_from=yes
be defaults. This is something most newbies stumble upon and I can think
of a situation where it would hurt.

Michael
-- 
Linux!  Guerrilla UNIX Development Venimus, Vidimus, Dolavimus.
(By [EMAIL PROTECTED], Mark A. Horton KA4YBR)

PGP-Key-ID: 0xDC1A44DD
Jabber: [EMAIL PROTECTED]

Re: mutt_error _("Could not create temporary file!")

[Thomas Roessler]

ok...  We'll need some cygwin-conditional code in the library that
tries to do safer temporary files on Unix.

(And some overall thinking as to whether we're going a step too far
there.)
-- 
Thomas Roessler   <[EMAIL PROTECTED]>






On 2007-03-01 11:54:54 +, Taleb Hakim wrote:
> From: Taleb Hakim <[EMAIL PROTECTED]>
> To: mutt-users@mutt.org
> Date: Thu, 1 Mar 2007 11:54:54 +
> Subject: Re: mutt_error _("Could not create temporary file!")
> X-Spam-Level: 
> 
> *Quoting Thomas Roessler, 12:31, Thu 01 Mar 07:
> > What file system is your home directory on?
> 
> vfat.
> 
> $ uname -a
> CYGWIN_NT-5.1 amex1 1.5.24(0.156/4/2) 2007-01-31 10.57 i686 Cygwin 
> 
> 

Re: What's needed for mutt 1.6? (maildir_indicator)

[Christian Ebert]

* Brendan Cully on Thursday, February 22, 2007 at 09:30:33 -0800:
> I intend to cut 1.5.14 this weekend. I'd like to make 1.5.15 the last
> proper dev release for 1.6 - that is, feature-freeze after
> 1.5.15. So, I'd like to hear once again which patches everyone would
> like to see in 1.6 (and which patches people object to).

The maildir_indicator patch by Olaf Hering overcomes an annoying
shortcoming when reading Maildir folders. I'm using it for quite
some time now, and didn't have any problems with it.

I attach a version against current tip.

c
-- 
_B A U S T E L L E N_ lesen! --->> 
# HG changeset patch
# User Christian Ebert <[EMAIL PROTECTED]>
# Date 1172751178 -3600
# Node ID 819ef6a7be0672ac8461faea6e4a9e940b9c7427
# Parent  42595801073eb5bfca435a65de87162a1c2c0824
Maildir indicator patch by Olaf Hering

Apply patch from Message-Id: <[EMAIL PROTECTED]>
against 1.5.14.
Original patch by: Olaf Hering <[EMAIL PROTECTED]>

diff -r 42595801073e -r 819ef6a7be06 PATCHES
--- a/PATCHES   Thu Mar 01 06:05:39 2007 +
+++ b/PATCHES   Thu Mar 01 13:12:58 2007 +0100
@@ -0,0 +1,1 @@
+patch-1.5.14.oh.maildir_indicator.1
diff -r 42595801073e -r 819ef6a7be06 browser.c
--- a/browser.c Thu Mar 01 06:05:39 2007 +
+++ b/browser.c Thu Mar 01 13:12:58 2007 +0100
@@ -351,6 +351,22 @@ static void init_state (struct browser_s
 menu->data = state->entry;
 }
 
+static unsigned short walk_maildir_new(const char *path)
+{
+  struct dirent *de;
+  DIR *d = opendir(path);
+  unsigned short count = 0;
+  if (d) {
+while ((de = readdir(d))) {
+  if (de->d_name[0] == '.' && (!de->d_name[1] || (de->d_name[1] == '.' && 
!de->d_name[2])))
+   continue;
+  count++;
+}
+closedir(d);
+  }
+  return count;
+}
+
 static int examine_directory (MUTTMENU *menu, struct browser_state *state,
  char *d, const char *prefix)
 {
@@ -358,6 +374,8 @@ static int examine_directory (MUTTMENU *
   DIR *dp;
   struct dirent *de;
   char buffer[_POSIX_PATH_MAX + SHORT_STRING];
+  char md_path[_POSIX_PATH_MAX];
+  unsigned short new;
   BUFFY *tmp;
 
   while (stat (d, &s) == -1)
@@ -404,17 +422,27 @@ static int examine_directory (MUTTMENU *
   continue;
 
 mutt_concat_path (buffer, d, de->d_name, sizeof (buffer));
-if (lstat (buffer, &s) == -1)
-  continue;
-
-if ((! S_ISREG (s.st_mode)) && (! S_ISDIR (s.st_mode)) &&
-   (! S_ISLNK (s.st_mode)))
-  continue;
-
-tmp = Incoming;
-while (tmp && mutt_strcmp (buffer, tmp->path))
-  tmp = tmp->next;
-add_folder (menu, state, de->d_name, &s, (tmp) ? tmp->new : 0);
+   if (mx_is_maildir (buffer)) {
+   snprintf (md_path, sizeof(md_path), "%s/new", buffer);
+   if (lstat (md_path, &s) == -1)
+   continue;
+   s.st_size = new = walk_maildir_new(md_path);
+   } else {
+   if (lstat (buffer, &s) == -1)
+   continue;
+
+   if ((! S_ISREG (s.st_mode)) && (! S_ISDIR (s.st_mode)) &&
+   (! S_ISLNK (s.st_mode)))
+   continue;
+   tmp = Incoming;
+   while (tmp && mutt_strcmp (buffer, tmp->path))
+   tmp = tmp->next;
+   if (tmp)
+   new = tmp->new;
+   else
+   new = 0;
+   }
+add_folder (menu, state, de->d_name, &s, new);
   }
   closedir (dp);  
   browser_sort (state);
@@ -425,6 +453,8 @@ static int examine_mailboxes (MUTTMENU *
 {
   struct stat s;
   char buffer[LONG_STRING];
+  char md_path[_POSIX_PATH_MAX];
+  unsigned short new;
   BUFFY *tmp = Incoming;
 
   if (!Incoming)
@@ -449,17 +479,24 @@ static int examine_mailboxes (MUTTMENU *
   continue;
 }
 #endif
-if (lstat (tmp->path, &s) == -1)
-  continue;
-
-if ((! S_ISREG (s.st_mode)) && (! S_ISDIR (s.st_mode)) &&
-   (! S_ISLNK (s.st_mode)))
-  continue;
-
+if (mx_is_maildir (tmp->path)) {
+   snprintf (md_path, sizeof(md_path), "%s/new", tmp->path);
+   if (lstat (md_path, &s) == -1)
+   continue;
+   s.st_size = new = walk_maildir_new(md_path);
+} else {
+   new = tmp->new;
+   if (lstat (tmp->path, &s) == -1)
+   continue;
+   if ((! S_ISREG (s.st_mode)) && (! S_ISDIR (s.st_mode)) &&
+   (! S_ISLNK (s.st_mode)))
+   continue;
+}
+
 strfcpy (buffer, NONULL(tmp->path), sizeof (buffer));
 mutt_pretty_mailbox (buffer);
 
-add_folder (menu, state, buffer, &s, tmp->new);
+add_folder (menu, state, buffer, &s, new);
   }
   while ((tmp = tmp->next));
   browser_sort (state);
diff -r 42595801073e -r 819ef6a7be06 mailbox.h
--- a/mailbox.h Thu Mar 01 06:05:39 2007 +
+++ b/mailbox.h Thu Mar 01 13:12:58 2007 +0100
@@ -74,6 +74,7 @@ int mx_is_imap (const char *);
 #ifdef USE_POP
 int mx_is_pop (const char *);
 #endif
+int mx_

Re: What's needed for mutt 1.6? (maildir_indicator)

[Rocco Rutte]

Hi,

* Christian Ebert [07-03-01 13:28:09 +0100] wrote:

* Brendan Cully on Thursday, February 22, 2007 at 09:30:33 -0800:

I intend to cut 1.5.14 this weekend. I'd like to make 1.5.15 the last
proper dev release for 1.6 - that is, feature-freeze after
1.5.15. So, I'd like to hear once again which patches everyone would
like to see in 1.6 (and which patches people object to).



The maildir_indicator patch by Olaf Hering overcomes an annoying
shortcoming when reading Maildir folders. I'm using it for quite
some time now, and didn't have any problems with it.



I attach a version against current tip.


It uses unsigned short for counting new mails which isn't too unlikely 
to overflow I think. The short fields come from BUFFY in buffy.h and the 
comments there imply these are used as flags, not as counters.


  bye, Rocco
--
:wq!

Re: What's needed for mutt 1.6?

[Kyle Wheeler]

On Thursday, February 22 at 09:30 AM, quoth Brendan Cully:
I do not intend to visit the great config-var rename topic until 
after 1.6 by the way. I think it would need too much time to deal 
with the fallout.


It would still probably be good to add documentation for the groups 
that Thomas added a few versions ago. Attached is my patch to do that 
for the man page.


~Kyle
--
To believe in God is impossible---to not believe in him is absurd.
  -- Voltaire
diff -u -3 -p -r3.22 muttrc.man.head
--- doc/muttrc.man.head 20 Jul 2006 00:12:52 -  3.22
+++ doc/muttrc.man.head 1 Mar 2007 14:07:57 -
@@ -67,16 +67,36 @@ like sh and bash: Prepend the name of th
 .SH COMMANDS
 .PP
 .nf
-\fBalias\fP \fIkey\fP \fIaddress\fP [\fB,\fP \fIaddress\fP [ ... ]]
+\fBalias\fP [\fB-group\fP \fIname\fP [...]] \fIkey\fP \fIaddress\fP [\fB,\fP 
\fIaddress\fP [ ... ]]
 \fBunalias\fP [\fB * \fP | \fIkey\fP ]
 .fi
 .IP
-\fBalias\fP defines an alias \fIkey\fP for the given addresses.
+\fBalias\fP defines an alias \fIkey\fP for the given addresses. Each
+\fIaddress\fP will be resolved into either an email address ([EMAIL PROTECTED])
+or a named email address (User Name <[EMAIL PROTECTED]>). The address may be 
specified in either format, or in the format \([EMAIL PROTECTED] (User
+Name)\(rq.
 \fBunalias\fP removes the alias corresponding to the given \fIkey\fP or
-all aliases when \(lq\fB*\fP\(rq is used as an argument.
+all aliases when \(lq\fB*\fP\(rq is used as an argument. The optional
+\fB-group\fP argument to \fBalias\fP causes the aliased address(es) to be
+added to the named \fIgroup\fP.
 .PP
 .nf
-\fBalternates\fP \fIregexp\fP [ \fB,\fP \fIregexp\fP [ ... ]]
+\fBgroup\fP [\fB-group\fP \fIname\fP] [\fB-rx\fP \fIEXPR\fP [ \fI...\fP ]] 
[\fB-addr\fP \fIaddress\fP [ \fI...\fP ]]
+\fBungroup\fP [\fB-group\fP \fIname\fP ] [ \fB*\fP | [[\fB-rx\fP \fIEXPR\fP [ 
\fI...\fP ]] [\fB-addr\fP \fIaddress\fP [ \fI...\fP ]]]
+.fi
+.IP
+\fBgroup\fP is used to directly add either addresses or regular expressions to
+the specified group or groups. The different categories of arguments to the
+\fBgroup\fP command can be in any order. The flags \fB-rx\fP and \fB-addr\fP
+specify what the following strings (that cannot begin with a hyphen) should be
+interpreted as: either a regular expression or an email address, respectively.
+\fBungroup\fP is used to remove addresses or regular expressions from the
+specified group or groups. The syntax is similar to the \fBgroup\fP command,
+however the special character \fB*\fP can be used to empty a group of all of
+its contents.
+.PP
+.nf
+\fBalternates\fP [\fB-group\fP \fIname\fP] \fIregexp\fP [ \fB,\fP \fIregexp\fP 
[ ... ]]
 \fBunalternates\fP [\fB * \fP | \fIregexp\fP [ \fB,\fP \fIregexp\fP [ ... ]] ]
 .fi
 .IP
@@ -84,7 +104,8 @@ all aliases when \(lq\fB*\fP\(rq is used
 where you receive mail; you can use regular expressions to specify
 alternate addresses.  This affects mutt's idea about messages
 from you, and messages addressed to you.  \fBunalternates\fP removes
-a regular expression from the list of known alternates.
+a regular expression from the list of known alternates. The \fB-group\fP flag
+causes all of the subsequent regular expressions to be added to the named 
group.
 .PP
 .nf
 \fBalternative_order\fP \fItype\fP[\fB/\fP\fIsubtype\fP] [ ... ]
@@ -226,9 +247,9 @@ The \fBunignore\fP command permits you t
 the above mentioned list of ignored headers.
 .PP
 .nf
-\fBlists\fP \fIregexp\fP [ \fIregexp\fP ... ]
+\fBlists\fP [\fB-group\fP \fIname\fP] \fIregexp\fP [ \fIregexp\fP ... ]
 \fBunlists\fP \fIregexp\fP [ \fIregexp\fP ... ]
-\fBsubscribe\fP \fIregexp\fP [ \fIregexp\fP ... ]
+\fBsubscribe\fP [\fB-group\fP \fIname\fP] \fIregexp\fP [ \fIregexp\fP ... ]
 \fBunsubscribe\fP \fIregexp\fP [ \fIregexp\fP ... ]
 .fi
 .IP
@@ -241,7 +262,8 @@ known mailing lists.  The \fBunlists\fP 
 list from the lists of known and subscribed mailing lists.  The
 \fBsubscribe\fP command adds a mailing list to the lists of known
 and subscribed mailing lists.  The \fBunsubscribe\fP command removes
-it from the list of subscribed mailing lists.
+it from the list of subscribed mailing lists. The \fb-group\fP flag
+adds all of the subsequent regular expressions to the named group.
 .TP
 \fBmbox-hook\fP [\fB!\fP]\fIpattern\fP \fImailbox\fP
 When mutt changes to a mail folder which matches \fIpattern\fP,
@@ -378,7 +400,9 @@ In various places with mutt, including s
 A simple pattern consists of an operator of the form
 \(lq\fB~\fP\fIcharacter\fP\(rq, possibly followed by a parameter
 against which mutt is supposed to match the object specified by
-this operator.  (For a list of operators, see below.)
+this operator.  For some \fIcharacter\fPs, the \fB~\fP may be
+replaced by another character to alter the behavior of the match.
+These are described in the list of operators, below.
 .PP
 With some of these operators, the object to be matched consists of
 severa

Report of rfc3676 patch success

[Mike Hunter]

Hey everybody,

Regarding my email a few days ago:

> I was trying to access it because I wanted to find out about the status
> of "delsp" ala rfc3676.  This is of keen interest to me because of
> certain insufferable mac users who keep emailing me "broken" URLs.  I
> happily add my vote to the "we can do this guys!" squad without, of
> course, offering any patches.

I just wanted to report that I was pointed to this patch:

http://user.cs.tu-berlin.de/~pdmef/mutt/patches/patch-1.5.14cvs.muttng.ff.4.diff

And it applies cleanly and works great.  FTR.

Mike

mutt/2810: mbox folder changes content while in pager, then moving through msgs => out of sync

[regrado]

>Number: 2810
>Notify-List:
>Category:   mutt
>Synopsis:   mbox folder changes content while in pager, then moving 
>through msgs => out of sync
>Confidential:   no
>Severity:   minor
>Priority:   low
>Responsible:mutt-dev
>State:  open
>Keywords:   
>Class:  sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 01 15:55:53 +0100 2007
>Originator: Rado S
>Release:1.5.14cvs
>Organization:
>Environment:
>Description:
When you change the content of an mbox folder externally while in pager,
then moving up/down to other msgs causes wrong seeking, pager is messed up:
headers are not shown, or wrong parts of header/ body.

mutt should notice a changed mbox folder content in the pager as it does in 
index
with same/ similar warning that it has changed and flags may be wrong.
>How-To-Repeat:
>Fix:
>Add-To-Audit-Trail:

>Unformatted:

Re: mutt/2808: changed / added %-expansion in save-hook

[Kyle Wheeler]

The following reply was made to PR mutt/2808; it has been noted by GNATS.

From: Kyle Wheeler <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: 
Subject: Re: mutt/2808: changed / added %-expansion in save-hook
Date: Thu, 1 Mar 2007 07:09:54 -0700

 --WplhKdTI2c8ulnbP
 Content-Type: multipart/mixed; boundary="+pHx0qQiF2pBVqBT"
 Content-Disposition: inline
 
 
 --+pHx0qQiF2pBVqBT
 Content-Type: text/plain; charset=us-ascii; format=flowed
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Thursday, March  1 at 10:28 AM, quoth [EMAIL PROTECTED]
 de:
 >However, the man-page makes no special mention of '%' as an active=20
 >character in patterns, and the above is a valid address according to=20
 >RFC822.  So either this is a software bug, or a duplicate of 2135=20
 >(hard to tell without a documentation of the intended behaviour).
 >>How-To-Repeat:
 >:fcc-save-hook [EMAIL PROTECTED]
 >>Fix:
 >If this is the intended behaviour, than it should be documented and an esc=
 ape-character should be specified (neither \% nor %% work).
 
 Attached is a patch to CVS HEAD that adds better documentation.
 
 ~Kyle
 --=20
 Well, I've wrestled with reality for over thirty five years, doctor,=20
 and I'm happy to state I finally won out over it.
  -- Jimmy Stewart, in "Harvey"
 
 --+pHx0qQiF2pBVqBT
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="mutt.doc.patch"
 Content-Transfer-Encoding: quoted-printable
 
 diff -u -3 -p -r3.22 muttrc.man.head
 --- doc/muttrc.man.head20 Jul 2006 00:12:52 -  3.22
 +++ doc/muttrc.man.head1 Mar 2007 14:07:57 -
 @@ -67,16 +67,36 @@ like sh and bash: Prepend the name of th
  .SH COMMANDS
  .PP
  .nf
 -\fBalias\fP \fIkey\fP \fIaddress\fP [\fB,\fP \fIaddress\fP [ ... ]]
 +\fBalias\fP [\fB-group\fP \fIname\fP [...]] \fIkey\fP \fIaddress\fP [\fB,\=
 fP \fIaddress\fP [ ... ]]
  \fBunalias\fP [\fB * \fP | \fIkey\fP ]
  .fi
  .IP
 -\fBalias\fP defines an alias \fIkey\fP for the given addresses.
 +\fBalias\fP defines an alias \fIkey\fP for the given addresses. Each
 +\fIaddress\fP will be resolved into either an email address ([EMAIL PROTECTED]
 com)
 +or a named email address (User Name <[EMAIL PROTECTED]>). The address may b=
 e specified in either format, or in the format \([EMAIL PROTECTED] (User
 +Name)\(rq.
  \fBunalias\fP removes the alias corresponding to the given \fIkey\fP or
 -all aliases when \(lq\fB*\fP\(rq is used as an argument.
 +all aliases when \(lq\fB*\fP\(rq is used as an argument. The optional
 +\fB-group\fP argument to \fBalias\fP causes the aliased address(es) to be
 +added to the named \fIgroup\fP.
  .PP
  .nf
 -\fBalternates\fP \fIregexp\fP [ \fB,\fP \fIregexp\fP [ ... ]]
 +\fBgroup\fP [\fB-group\fP \fIname\fP] [\fB-rx\fP \fIEXPR\fP [ \fI...\fP ]]=
  [\fB-addr\fP \fIaddress\fP [ \fI...\fP ]]
 +\fBungroup\fP [\fB-group\fP \fIname\fP ] [ \fB*\fP | [[\fB-rx\fP \fIEXPR\f=
 P [ \fI...\fP ]] [\fB-addr\fP \fIaddress\fP [ \fI...\fP ]]]
 +.fi
 +.IP
 +\fBgroup\fP is used to directly add either addresses or regular expression=
 s to
 +the specified group or groups. The different categories of arguments to the
 +\fBgroup\fP command can be in any order. The flags \fB-rx\fP and \fB-addr\=
 fP
 +specify what the following strings (that cannot begin with a hyphen) shoul=
 d be
 +interpreted as: either a regular expression or an email address, respectiv=
 ely.
 +\fBungroup\fP is used to remove addresses or regular expressions from the
 +specified group or groups. The syntax is similar to the \fBgroup\fP comman=
 d,
 +however the special character \fB*\fP can be used to empty a group of all =
 of
 +its contents.
 +.PP
 +.nf
 +\fBalternates\fP [\fB-group\fP \fIname\fP] \fIregexp\fP [ \fB,\fP \fIregex=
 p\fP [ ... ]]
  \fBunalternates\fP [\fB * \fP | \fIregexp\fP [ \fB,\fP \fIregexp\fP [ ... =
 ]] ]
  .fi
  .IP
 @@ -84,7 +104,8 @@ all aliases when \(lq\fB*\fP\(rq is used
  where you receive mail; you can use regular expressions to specify
  alternate addresses.  This affects mutt's idea about messages
  from you, and messages addressed to you.  \fBunalternates\fP removes
 -a regular expression from the list of known alternates.
 +a regular expression from the list of known alternates. The \fB-group\fP f=
 lag
 +causes all of the subsequent regular expressions to be added to the named =
 group.
  .PP
  .nf
  \fBalternative_order\fP \fItype\fP[\fB/\fP\fIsubtype\fP] [ ... ]
 @@ -226,9 +247,9 @@ The \fBunignore\fP command permits you t
  the above mentioned list of ignored headers.
  .PP
  .nf
 -\fBlists\fP \fIregexp\fP [ \fIregexp\fP ... ]
 +\fBlists\fP [\fB-group\fP \fIname\fP] \fIregexp\fP [ \fIregexp\fP ... ]
  \fBunlists\fP \fIregexp\fP [ \fIregexp\fP ... ]
 -\fBsubscribe\fP \fIregexp\fP [ \fIregexp\fP ... ]
 +\fBsubscribe\fP [\fB-group\fP \fIname\fP] \fIregexp\fP [ \fIregexp\fP ... ]
  \fBunsubscribe\fP \fIregexp\fP [ \fIregexp\fP ... ]
  .fi
  .IP
 @@ -241,7 +262,8 @@

Re: [PATCH] runtime configurable buffy size

[Miroslav Lichvar]

On Wed, Feb 28, 2007 at 02:33:17PM +0100, Christoph Berg wrote:
> Re: Miroslav Lichvar 2007-02-28 <[EMAIL PROTECTED]>
> > attached is a patch that makes the buffy size option configurable at
> > runtime. Mutt binary compiled with --enable-buffy-size will
> > have an extra boolean variable that controls if mbox size should be
> > used when checking for new mail.
> 
> > +++ init.h  28 Feb 2007 12:38:11 -
> > +#ifdef BUFFY_SIZE
> > +  { "buffy_size",  DT_BOOL, R_NONE, OPTBUFFYSIZE, 1 },
> 
> I'd remove the ./configure option and let it default to 0.
> 
> This would also be the chance to give the option a less silly name,
> e.g. check_mbox_size.

Ok, here is a patch that removes buffy_size completely and adds the
check_box_size option.

-- 
Miroslav Lichvar
Index: buffy.c
===
RCS file: /home/roessler/cvs/mutt/buffy.c,v
retrieving revision 3.20
diff -u -r3.20 buffy.c
--- buffy.c 19 Nov 2006 05:19:09 -  3.20
+++ buffy.c 1 Mar 2007 14:52:15 -
@@ -45,8 +45,6 @@
 static short BuffyCount = 0;   /* how many boxes with new mail */
 static short BuffyNotify = 0;  /* # of unnotified new boxes */
 
-#ifdef BUFFY_SIZE
-
 /* Find the last message in the file. 
  * upon success return 0. If no message found - return -1 */
 
@@ -142,7 +140,7 @@
   struct stat sb;
   struct stat tmp_sb;
   
-  if (stat (path,&sb) != 0)
+  if (!option(OPTCHECKMBOXSIZE) || stat (path,&sb) != 0)
 return NULL;
 
   for (tmp = Incoming; tmp; tmp = tmp->next)
@@ -167,15 +165,12 @@
 b->size = 0;
   return;
 }
-#endif
 
 int mutt_parse_mailboxes (BUFFER *path, BUFFER *s, unsigned long data, BUFFER 
*err)
 {
   BUFFY **tmp,*tmp1;
   char buf[_POSIX_PATH_MAX];
-#ifdef BUFFY_SIZE
   struct stat sb;
-#endif /* BUFFY_SIZE */
 
   while (MoreArgs (s))
   {
@@ -232,31 +227,28 @@
 (*tmp)->notified = 1;
 (*tmp)->newly_created = 0;
 
-#ifdef BUFFY_SIZE
-/* for buffy_size, it is important that if the folder is new (tested by
+/* for check_mbox_size, it is important that if the folder is new (tested 
by
  * reading it), the size is set to 0 so that later when we check we see
- * that it increased .  without buffy_size we probably don't care.
+ * that it increased .  without check_mbox_size we probably don't care.
  */
-if (stat ((*tmp)->path, &sb) == 0 && !test_new_folder ((*tmp)->path))
+if (option(OPTCHECKMBOXSIZE) &&
+   stat ((*tmp)->path, &sb) == 0 && !test_new_folder ((*tmp)->path))
 {
   /* some systems out there don't have an off_t type */
   (*tmp)->size = (long) sb.st_size;
 }
 else
   (*tmp)->size = 0;
-#endif /* BUFFY_SIZE */
   }
   return 0;
 }
 
-#ifdef BUFFY_SIZE
-/* people use buffy_size on systems where modified time attributes are BADLY
- * broken. Ignore them.
+/* people use check_mbox_size on systems where modified time attributes are 
+ * BADLY broken. Ignore them.
  */
-#define STAT_CHECK (sb.st_size > tmp->size)
-#else
-#define STAT_CHECK (sb.st_mtime > sb.st_atime || (tmp->newly_created && 
sb.st_ctime == sb.st_mtime && sb.st_ctime == sb.st_atime))
-#endif /* BUFFY_SIZE */
+#define STAT_CHECK_SIZE (sb.st_size > tmp->size)
+#define STAT_CHECK_TIME (sb.st_mtime > sb.st_atime || (tmp->newly_created && 
sb.st_ctime == sb.st_mtime && sb.st_ctime == sb.st_atime))
+#define STAT_CHECK (option(OPTCHECKMBOXSIZE) ? STAT_CHECK_SIZE : 
STAT_CHECK_TIME)
 
 int mutt_buffy_check (int force)
 {
@@ -323,9 +315,7 @@
* be ready for when it does. */
   tmp->newly_created = 1;
   tmp->magic = 0;
-#ifdef BUFFY_SIZE
   tmp->size = 0;
-#endif
   continue;
 }
 #ifdef USE_IMAP
@@ -365,13 +355,11 @@
  BuffyCount++;
  tmp->new = 1;
}
-#ifdef BUFFY_SIZE
else
{
  /* some other program has deleted mail from the folder */
  tmp->size = (long) sb.st_size;
}
-#endif
if (tmp->newly_created &&
(sb.st_ctime != sb.st_mtime || sb.st_ctime != sb.st_atime))
  tmp->newly_created = 0;
@@ -407,10 +395,8 @@
break;
   }
 }
-#ifdef BUFFY_SIZE
 else if (Context && Context->path)
   tmp->size = (long) sb.st_size;   /* update the size */
-#endif
 
 if (!tmp->new)
   tmp->notified = 0;
Index: buffy.h
===
RCS file: /home/roessler/cvs/mutt/buffy.h,v
retrieving revision 3.4
diff -u -r3.4 buffy.h
--- buffy.h 17 Sep 2005 20:46:10 -  3.4
+++ buffy.h 1 Mar 2007 14:52:15 -
@@ -23,9 +23,7 @@
 typedef struct buffy_t
 {
   char *path;
-#ifdef BUFFY_SIZE
   long size;
-#endif /* BUFFY_SIZE */
   struct buffy_t *next;
   short new;   /* mailbox has new mail */
   short notified;  /* user has been notified */
@@ -39,7 +37,5 @@
 
 extern time_t BuffyDoneTime;   /* last time we knew for sure how much mail 
there was */
 
-#ifdef BUFFY_SIZE
 BUFFY *mutt_find_mai

Re: What's needed for mutt 1.6?

[David Champion]

* On 2007.03.01, in <[EMAIL PROTECTED]>,
*   "Lars Hecking" <[EMAIL PROTECTED]> wrote:
> 
>  Can you show me one single case where using multipart/alternative is
>  justified and actually makes any sense? It's bad enough to receive
>  bloated text+html email from clueless Outlook users, I don't want to
>  see such mail from mutt users, too.

The principal problems there are "clueless" and "Outlook", not
"multipart/alternative".

I would agree that mutt should not send multipart/alternative by default
when the original material is "flat".  That's useless bloat.  It happens
because of laziness in the presence of automatic content-generating
misfeatures, but benefiting from this patch requires effort and this
patch doesn't provide the misfeature.

But on to your challenge:

I'm in central IT for my institution.  We have a "bulkmail" service
through which staff and administration send out bulletins that they
think segments of the University population need to see.  Often they
think they need to see them in MS Word format.  We usually can talk them
down to HTML or perhaps text/enriched, but this usually looks like hell
in a terminal, too.  Sending multipart/alternative can actually be a
good thing for mutt users, if the text/plain conversion is good.

That's just an example I pulled out my example-pulling facility.  In
fact I don't think it's incumbent upon us to justify giving mutt
common-practice features when the only reason not to do it is that
mutt loses some perceived moral superiority.  This is like the old
descriptive/prescriptive dichotomy in linguistics.  For better or worse,
it's common practice because it's what senders and recipients want, not
because Gates and Ballmer told the Outlook team it would be sell more
units.

I would prefer mutt not to be the contrarian old geezer who smokes a
calabash and tells people it's "I shall, not I will".  As much sympathy
as I have for prescriptive rectitude, it doesn't build acceptance, and
acceptance is what mutt needs.

-- 
 -D.[EMAIL PROTECTED]NSITUniversity of Chicago

Re: mutt/2160: make hostname part of Message-IDs configurable

[Christoph Berg]

Synopsis: make hostname part of Message-IDs configurable

 Comment added by cb on Thu, 01 Mar 2007 20:26:04 +0100 
 update title

mutt/2811: Bug#413014: mutt: Handling of e-mails with multiple Message-IDs

[Christoph Berg]

>Number: 2811
>Category:   mutt
>Synopsis:   Bug#413014: mutt: Handling of e-mails with multiple Message-IDs
>Confidential:   no
>Severity:   normal
>Priority:   medium
>Responsible:mutt-dev
>State:  open
>Keywords:   
>Class:  sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 01 20:35:02 +0100 2007
>Originator: Christoph Berg <[EMAIL PROTECTED]>
>Release:
>Description:

Hi,

the following was submitted as Debian bug #413014:

- Forwarded message from Mark Brown <[EMAIL PROTECTED]> -

Date: Thu, 01 Mar 2007 18:48:20 +
From: Mark Brown <[EMAIL PROTECTED]>
Reply-To: Mark Brown <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: Bug#413014: mutt: Handling of e-mails with multiple Message-IDs

Package: mutt
Version: 1.5.13-1.1
Severity: minor

Some broken mail processing software (I'm thinking particularly of
crm114 here, though other things could do the same) when processing
e-mail that contains a Message-ID header so that it also contains a
Message-Id header.  mutt, presumably in order to improve
interoperability, will accept either spelling of the header name and
appears to accept the last one.  

Unfortunately in the case of crm114 what it's doing is trying to add a
comment to the Message-ID; what it actually ends up doing is creating a
Message-Id field consisting only of a comment.  This means that mutt
winds up thinking there is no Message-ID at all, breaking threading.  It
would help matters if mutt were to ignore empty Message-I[dD] headers
without assuming they were the only instance of that heaeder.

Obviously, the problematic messages broken and the software generating
them needs to be fixed: this is just a suggestion for an
interoperability enhancement.

- End forwarded message -

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/

>Fix:

Unknown
>Add-To-Audit-Trail:

Mutt Mercurial repository reconverted

[Brendan Cully]

Hi all,

I've reconverted the mutt CVS repository to Mercurial, hopefully for
the last time (the previous conversion had a bug where cloning a
single branch other than HEAD left you without any tags).

The URL is: http://dev.mutt.org/hg/cvs

Those of you who already started working off of the old repository can
still access it at http://dev.mutt.org/hg/cvs.old. At some point,
probably very soon, I'll make the new archive official (I just need to
make sure the conversion looks good). You'll probably want to migrate
your local work to it at that point.

There are several options for moving your work over. hg transplant
should do it easily, or you can hg export | hg import, or use mq's
qimport -r feature. Unfortunately, push and pull will not work, since
the repositories are not related.


pgpp3L35UdYPK.pgp
Description: PGP signature

Re: Mutt Mercurial repository reconverted

[Kyle Wheeler]

On Thursday, March  1 at 11:39 AM, quoth Brendan Cully:

Hi all,

I've reconverted the mutt CVS repository to Mercurial, hopefully for
the last time (the previous conversion had a bug where cloning a
single branch other than HEAD left you without any tags).

The URL is: http://dev.mutt.org/hg/cvs


How does one go about pulling down a fresh mutt devel source? Is there 
an `hg checkout http://dev.mutt.org/hg/cvs` command or something?


~Kyle
--
I have great faith in fools; my friends call it self-confidence.
   -- Edgar Allen Poe


pgp9zYMQY37Cv.pgp
Description: PGP signature

Re: Mutt Mercurial repository reconverted

[Brendan Cully]

On Thursday, 01 March 2007 at 13:10, Kyle Wheeler wrote:
> On Thursday, March  1 at 11:39 AM, quoth Brendan Cully:
> >Hi all,
> >
> >I've reconverted the mutt CVS repository to Mercurial, hopefully for
> >the last time (the previous conversion had a bug where cloning a
> >single branch other than HEAD left you without any tags).
> >
> >The URL is: http://dev.mutt.org/hg/cvs
> 
> How does one go about pulling down a fresh mutt devel source? Is there 
> an `hg checkout http://dev.mutt.org/hg/cvs` command or something?

hg clone http://dev.mutt.org/hg/cvs [local directory name]


pgphQopmqh1HC.pgp
Description: PGP signature

Re: Mutt Mercurial repository reconverted

[Charles Cazabon]

Brendan Cully <[EMAIL PROTECTED]> wrote:
> 
> I've reconverted the mutt CVS repository to Mercurial,
[...]
> 
> The URL is: http://dev.mutt.org/hg/cvs

Just a nitpick, but maybe a different name would prevent confusion about
whether it's CVS or Mercurial?

i.e. "repos" or whatever instead of "cvs".

Charles
-- 
---
Charles Cazabon  <[EMAIL PROTECTED]>
---

Mutt 1.5.14 on Freebsd Display Problem

[Ryan Phillips]

Hi All,

I'm a long time mutt user.  I just upgraded my freebsd 6.2 stable box
to the latest 1.5.14 mutt version.

The index view is sorted by thread, and every sub-message has a:
   [EMAIL PROTECTED]@>

This problem didn't happen with 1.5.13.  If it makes a difference I'm
using putty to ssh into the box.

Is there more information I need to provide to solve my problem?

Thanks,
Ryan Phillips

Re: What's needed for mutt 1.6?

[Adeodato Simó]

* Brendan Cully [Thu, 22 Feb 2007 09:30:33 -0800]:

> So, I'd like to hear once again which patches everyone would
> like to see in 1.6 (and which patches people object to).

Personally, I can't live without hr.sensible_browser_position [1]. It
makes mutt remember the position in the browser when visiting folders.
I guess this is a patch that is difficult to get in without an
associated variable.

  [1] 
http://svn.df7cb.de/debian/mutt/trunk/debian/patches/not-applied/patch-1.5.8.hr.sensible_browser_position.3

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
A celebrity is a person who works hard all his life to become well known,
then wears dark glasses to avoid being recognized.
-- Fred Allen

Re: Mutt 1.5.14 on Freebsd Display Problem

[Paul Walker]

On Thu, Mar 01, 2007 at 01:23:28PM -0800, Ryan Phillips wrote:

> This problem didn't happen with 1.5.13.  If it makes a difference I'm
> using putty to ssh into the box.

I seem to remember having that problem when putty and the terminal had
different ideas about what encoding to use. I solved it by setting putty to
using UTF-8. Might be worth you trying the same, just in case...

-- 
Paul


signature.asc
Description: Digital signature

Re: What's needed for mutt 1.6?

[Jeremy Blosser]

On Mar 01, David Champion [EMAIL PROTECTED] wrote:
> In fact I don't think it's incumbent upon us to justify giving mutt
> common-practice features when the only reason not to do it is that mutt
> loses some perceived moral superiority.  This is like the old
> descriptive/prescriptive dichotomy in linguistics.  For better or worse,
> it's common practice because it's what senders and recipients want, not
> because Gates and Ballmer told the Outlook team it would be sell more
> units.
> 
> I would prefer mutt not to be the contrarian old geezer who smokes a
> calabash and tells people it's "I shall, not I will".  As much sympathy
> as I have for prescriptive rectitude, it doesn't build acceptance, and
> acceptance is what mutt needs.

I was mostly nodding along until the last sentence.  But why does mutt need
acceptance?

FWIW, I still prefer adding features because the people writing mutt want
them, not because someone who doesn't use mutt might use it if it had them.
Or do you mean something else by "acceptance"?


pgppKpRHRs3pH.pgp
Description: PGP signature

Re: PKA for Mutt

[Christoph Berg]

Re: Brendan Cully 2007-02-24 <[EMAIL PROTECTED]>
> > i have worked on PKA support for Mutt.  Seems to work so far,
> > would be
> > great if it could be integrated into CVS.  It probably needs some
> > more
> > work (review, testing, etc.), though.
> > 
> Applied (with $use_pka renamed to $crypt_use_pka and minor cosmetic
> tweaks). Thanks!

Hi,

I just tried to make that work here. I have sucessfully added a PKA
record to my nameserver [1] but I cannot figure out what PKA support
in mutt is supposed to do, or where it should show up. sig->pka_trust
seems to be always 0.

Could someone enlighten me?

Christoph

[1] http://www.df7cb.de/blog/2007/03/01#2007-03-01-openpgp-dns
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


pgpXwIaWJ7lbS.pgp
Description: PGP signature

Re: Mutt Mercurial repository reconverted

[Brendan Cully]

On Thursday, 01 March 2007 at 14:31, Charles Cazabon wrote:
> Brendan Cully <[EMAIL PROTECTED]> wrote:
> > 
> > I've reconverted the mutt CVS repository to Mercurial,
> [...]
> > 
> > The URL is: http://dev.mutt.org/hg/cvs
> 
> Just a nitpick, but maybe a different name would prevent confusion about
> whether it's CVS or Mercurial?
> 
> i.e. "repos" or whatever instead of "cvs".

This is reasonable. I'll keep the cvs directory around as the CVS
mirror, but propagate changes from it to:

http://dev.mutt.org/hg/mutt

which will become the official repository after I've finished plumbing
things.


pgpYnd9D6kehW.pgp
Description: PGP signature

Re: What's needed for mutt 1.6? (multipart/alternative)

[Jim Allen]

On Mar 1, 2007, at 4:20 AM, Lars Hecking wrote:



 Can you show me one single case where using multipart/alternative is
 justified and actually makes any sense? It's bad enough to receive
 bloated text+html email from clueless Outlook users, I don't want to
 see such mail from mutt users, too.


The many inadequacies of using something other than plain text for e- 
mail (bloated e-mail, security
vulnerabilites, etc) have been extensively discussed on this and  
other newsgroups. I don't dispute
them and I realize my proposal for multipart/alternative e-mail  
capabilities in mutt, will be unpopular with some.


However inspite of all our attempts to evangelize the world on the  
merits of plain text e-mail, the
fact is that HTML e-mail is ubiqutuous (Outlook, Thunderbird, Lotus  
Notes, Gnome Evolution, Mac OSX
Mail,  etc).  Very often the reality is that technically superior  
solutions lose out to inferior ones
(i.e. Microsoft software) because of other factors (business models,  
politics, fads, etc). In fact I have
many colleagues and customers who insist on not using plain text e- 
mail at all.  They are not swayed
by any of  the numerous arguments for plain text.  Many though have  
been willing to compromise by using

multipart/alternative e-mail instead of pure html e-mail.

Since I have to interact with them and prefer a text-based e-mail  
client,  I've extended mutt with
configurable variables to provide better multipart/alternative e-mail  
handling. I should point out
that none of these multipart/alternative changes are on by default.  
So for those not interested in using

multipart/alternative e-mail, they are not affected.

[2007-03-02] CVS repository changes

[Thomas Roessler]

This message was generated and sent automatically.  It contains a
summary of the CVS commits over the last 48 hours.  These changes
should be propagated to the public repository within at most a day
or two.  Most probably, they have already been propagated.


2007-03-02 01:25:41  Petr Pisar  <[EMAIL PROTECTED]>  (brendan)

* po/cs.po: Updated Czech translation (now in UTF-8).

2007-03-01 06:05:39  Brendan Cully  <[EMAIL PROTECTED]>  (brendan)

* init.h: Remove $file_charset SYN - it never appeared in an
official release.

2007-02-28 17:47:13  Brendan Cully  <[EMAIL PROTECTED]>  (brendan)

* imap/command.c, imap/imap.c, imap/imap_private.h: Add
imap_close_connection to fully reset IMAP state. (closes: #2717)
Thanks to Sergey Svishchev for the original patch.

2007-02-28 16:27:47  Vsevolod Volkov  <[EMAIL PROTECTED]>  (brendan)

* po/ru.po: Updated Russian translation.

2007-02-28 07:36:33  TAKAHASHI Tamotsu  <[EMAIL PROTECTED]>
(brendan)

* po/ja.po: Updated Japanese translation.

Re: imap/2717: mutt may appear to hang while it reconnects to IMAP

[Kyle Wheeler]

On Wednesday, February 28 at 06:50 PM, quoth Brendan Cully:

Thanks for the patch! I think the cleanup should be done at
close, so I've applied a variant of this to CVS. Can you
test whether CVS fixes this (it appears to here)?


This works fantastically for me. Thanks very much!

~Kyle
--
If A equals success, then the formula is A=X+Y+Z. X is work. Y is 
play. Z is keep your mouth shut.

   -- Albert Einstein


pgpG77XYTxrYG.pgp
Description: PGP signature

Re: Mutt 1.5.14 on Freebsd Display Problem

[Ryan Phillips]

Paul Walker <[EMAIL PROTECTED]> said:
> On Thu, Mar 01, 2007 at 01:23:28PM -0800, Ryan Phillips wrote:
> 
> > This problem didn't happen with 1.5.13.  If it makes a difference I'm
> > using putty to ssh into the box.
> 
> I seem to remember having that problem when putty and the terminal had
> different ideas about what encoding to use. I solved it by setting putty to
> using UTF-8. Might be worth you trying the same, just in case...
> 

Hi Paul,

Thanks for the reply.  I have the same problem with iTerm on OSX
connecting to the same Freebsd box.  

I narrowed down the problem with ncurses.  I had WITH_MUTT_NCURSES=yes
set in my /etc/make.conf file.  Removing the line and letting mutt
compile with the default slang library fixed the problem.

-Ryan

Re: mutt/1116: Fails to thread properly without an @ in msg ID

[Cameron Simpson]

The following reply was made to PR mutt/1116; it has been noted by GNATS.

From: Cameron Simpson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: mutt/1116: Fails to thread properly without an @ in msg ID
Date: Fri, 2 Mar 2007 15:18:42 +1100

 On 27Feb2007 21:15, Christoph Berg <[EMAIL PROTECTED]> wrote:
 |  If a message lacks an @ ('at') symbol in the Message-ID field, Mutt
 |  refuses to connect messages to it, even if they correctly specify the
 |  In-Reply-To header.
 |  
 |  Further, connecting a thread manually using the '&' key (link-threads)
 |  lasts only while that mailbox index is open.  Reopening the mailbox
 |  loses the linkage.
 |  
 |  Specifying a Message-ID without a domain is highly unusual, and goes
 |  against a 'RECOMMENDED' clause in RFC 2822, but the only 'MUST' clause
 |  relating to Message-ID is that it be unique.
 
 Hmm. RFC822 says:
 
msg-id  =  "<" addr-spec ">"; Unique message id
addr-spec   =  local-part "@" domain 
 
 RFC2822 says:
 
   msg-id  =   [CFWS] "<" id-left "@" id-right ">" [CFWS]
 
 I don't see, regardless of any other verbiage you may find, how that can
 possibly be read as allowing "@" to be optional.
 
 I imagine you have read this text in RFC2822:
 
   Using a date on the left hand side and a domain name or domain literal on
   the right hand side makes it possible to guarantee uniqueness since no two
   hosts use the same domain name or IP address at the same time.  Though
   other algorithms will work, it is RECOMMENDED that the right hand side
   contain some domain identifier [...]
 
 That DOES NOT say that the "@" is optional. It says that the text on the
 right of the "@" need not be a domain.
 
 If you have other text from the RFC in mind, please quote it.
 
 Thanks,
 -- 
 Cameron Simpson <[EMAIL PROTECTED]> DoD#743
 http://www.cskk.ezoshosting.com/cs/
 
 in rec.moto, jsh wrote:
 > Dan Nitschke wrote:
 > > Ged Martin wrote:
 > > > On Sat, 17 May 1997 16:53:33 +, Dan Nitschke scribbled:
 > > > >(And you stay *out* of my dreams, you deviant little
 > > > >weirdo.)
 > > > Yeah, yeah, that's what you're saying in _public_
 > > Feh. You know nothing of my dreams. I dream entirely in text (New Century
 > > Schoolbook bold oblique 14 point), and never in color. I once dreamed I
 > > was walking down a flowchart of my own code, and a waterfall of semicolons
 > > was chasing me. (I hid behind a global variable until they went by.)
 > You write code in a proportional serif? No wonder you got extra
 > semicolons falling all over the place.
 No, I *dream* about writing code in a proportional serif font.
 It's much more exciting than my real life.
 /* dan: THE Anti-Ged -- Ignorant Yank (tm) #1, none-%er #7 */
 Dan Nitschke  [EMAIL PROTECTED]  [EMAIL PROTECTED]
 

Re: imap/2717: mutt may appear to hang while it reconnects to IMAP

[Kyle Wheeler]

The following reply was made to PR imap/2717; it has been noted by GNATS.

From: Kyle Wheeler <[EMAIL PROTECTED]>
To: Mutt Developers 
Cc: [EMAIL PROTECTED]
Subject: Re: imap/2717: mutt may appear to hang while it reconnects to IMAP
server
Date: Thu, 1 Mar 2007 21:56:44 -0700

 --oXNgvKVxGWJ0RPMJ
 Content-Type: text/plain; charset=us-ascii; format=flowed
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Wednesday, February 28 at 06:50 PM, quoth Brendan Cully:
 >Thanks for the patch! I think the cleanup should be done at
 >close, so I've applied a variant of this to CVS. Can you
 >test whether CVS fixes this (it appears to here)?
 
 This works fantastically for me. Thanks very much!
 
 ~Kyle
 --=20
 If A equals success, then the formula is A=3DX+Y+Z. X is work. Y is=20
 play. Z is keep your mouth shut.
 -- Albert Einstein
 
 --oXNgvKVxGWJ0RPMJ
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -BEGIN PGP SIGNATURE-
 Comment: Thank you for using encryption!
 
 iD8DBQFF566MBkIOoMqOI14RAl4AAKCORMGHcSBy/c4Z1t5NuP67A2nqLACdFL0e
 tftX+tQZHvcoAz/Prp2qFvU=
 =XdTY
 -END PGP SIGNATURE-
 
 --oXNgvKVxGWJ0RPMJ--
 

Re: What's needed for mutt 1.6?

[Christian Ebert]

* Rocco Rutte on Wednesday, February 28, 2007 at 09:39:03 +:
> * Rocco Rutte [07-02-26 17:59:44 +] wrote:
>> It needs some style tweaks and I'm still not fully sure if the 
>> space-stuffing it does it totally right (especially when editing the same 
>> message several times via compose menu), but anyway:
> 
>> 

I played around with this. 2 questions/remarks:

It seems to me that it breaks recognition of correct sig dashes
in the pager (or is it something in my setup?).

While I guess it is more correct rfc-wise I personally prefer the
old-fashioned way of reading the mail wrapped -- and only eg. a
long line like the url above not wrapped (otoh I use a rather
wide terminal so that eg. long urls broken by terminal width).

c
-- 
_B A U S T E L L E N_ lesen! --->>