Processed: bugs #800 #1613 #1200 #1407 #1427 #1747 #1603 #1765 #1334 #1642 #1778

Processing commands for control <at> bugs.guug.de:

> severity 1613 wishlist
bug#1613: mutt-1.4.1i: "q" quit command doesnt quit when selecting a folder
Severity set to `wishlist'.

> merge 800 1613
bug#800: mutt-1.3.22i: ability to quit from all screens
bug#1613: mutt-1.4.1i: "q" quit command doesnt quit when selecting a folder
Merged 800 1613.

> merge 1427 1747
bug#1427: mutt-1.4i: Unable to read any of the psyche-list archives mailboxes
bug#1747: mutt-1.4.1i: Mutt doesn't like some ^From mailbox seperators (esp. with "at")
bug#1200: mutt-1.3.27i: Some mailbox doesn't work at all.
bug#1407: mutt-1.5.1i: strange behavior when email address contains 0xA0 's
Merged 1200 1407 1427 1747.

> severity 1765 wishlist
bug#1765: mutt-1.5.5.1i: i18n of "Re: your mail" string
Severity set to `wishlist'.

> merge 1603 1765
bug#1603: mutt-1.5.4i: whislist: possibility to change "Re: your mail" when replying to mail with empty
Subject: line.
bug#1765: mutt-1.5.5.1i: i18n of "Re: your mail" string
Merged 1603 1765.

> tags 1334 patch
bug#1334: mutt-1.3.27i: A shortcut to use current folder in hooks

[2004-02-01] CVS repository changes

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.

Re: PGP timeout patch

Sounds good to me.  Any thoughts from others?

On 2004-01-19 15:08:31 +1100, Ben Elliston wrote:
> From: Ben Elliston <bje+dated+1074917314.d5e4f1 <at> air.net.au>
> To: mutt-dev <at> mutt.org
> Date: Mon, 19 Jan 2004 15:08:31 +1100
> Subject: PGP timeout patch
> X-Spam-Level: *
> 
> The following (rough) patch refines the PGP passphrase timeout
> mechanism, such that sending a message with a cached passphrase will
> restart the expiry timer.  This has the advantage that:
> 
>   * sending a continuous stream of messages will prevent Mutt
>     from repeatedly asking for the passphrase, irritating the user;
> 
>   * the user can choose a much lower timeout value as a result.
> 
> If the idea of this patch is acceptable, I will tidy it up, make sure
> that the patch applies cleanly to CVS head and test it.
> 
> Cheers, Ben
> 
> --- pgp.c.orig	2002-01-10 02:39:28.000000000 +1100
> +++ pgp.c
>  <at>  <at>  -55,7 +55,7  <at>  <at> 
>  
>  
>  char PgpPass[STRING];
> -static time_t PgpExptime = 0; /* when does the cached passphrase expire? */

Re: PATCH: Bugfix on -F

Thanks, this is in the CVS now.

On 2004-01-18 18:35:04 -0500, Mike Schiraldi wrote:
> From: Mike Schiraldi <1074468571 <at> schiraldi.org>
> To: mutt-dev <at> mutt.org
> Date: Sun, 18 Jan 2004 18:35:04 -0500
> Subject: PATCH: Bugfix on -F
> X-Spam-Level: 
> 
> As you all know, running "mutt -F foo.rc" will have mutt read foo.rc as its
> config file. However, there is a bug -- if you specify a directory (like
> accidentally typing "mutt -F /etc/mutt") mutt will silently ignore the flag
> and leave you wondering why it isn't working.
> 
> Emil Sit posted a patch for this in March of 2002, but it seems to have
> slipped through the cracks. Here's the patch again; please consider it for
> inclusion.

> Index: init.c
> ===================================================================
> RCS file: /home/roessler/cvs/mutt/init.c,v
> retrieving revision 3.17
> diff -u -r3.17 init.c
> --- init.c	4 Jan 2004 11:10:21 -0000	3.17
> +++ init.c	18 Jan 2004 23:26:03 -0000
>  <at>  <at>  -1254,6 +1254,18  <at>  <at> 
>    char *linebuf = NULL;
>    size_t buflen;
>    pid_t pid;
> +  struct stat s;

Re: [patch] config_charset variable (wishlist #1642)

Looks good to me, except for the formatting which doesn't match what
the remaining source code does.  Any comments/thoughts?

On 2004-01-17 21:03:52 +0100, Joël Riou wrote:
> From: Joël Riou <joel.riou <at> normalesup.org>
> To: mutt-dev <at> mutt.org
> Date: Sat, 17 Jan 2004 21:03:52 +0100
> Subject: [patch] config_charset variable (wishlist #1642)
> X-Spam-Level: 
> 
>   Attached is a patch for the wishlist bug #1642. It adds a variable
> config_charset that one may define in a rc file that contains non ascii
> characters (aliases files for instance). Where a rc file is sourced, the
> commands are converted from this encoding, so that it works well if you
> are used to working in UTF8 xterms but sometimes have to use a
> latin-encoded terminal.
> 
> -- 
> Joël Riou
> 

> diff -u mutt/globals.h mutt.new/globals.h
> --- mutt/globals.h	2004-01-17 20:12:25.000000000 +0100
> +++ mutt.new/globals.h	2004-01-17 20:13:17.000000000 +0100
>  <at>  <at>  -37,6 +37,7  <at>  <at> 
>  WHERE char *AttachFormat;
>  WHERE char *Charset;
>  WHERE char *ComposeFormat;
> +WHERE char *ConfigCharset;
>  WHERE char *ContentType;

Re: Bug#222191: patch-1.4.1.tt.compat.1 for mutt fixes this bug

Even though I don't really like the assumed_charset feature, I'm
somewhat tempted to adding it to mutt; I'd welcome comments on that.

Generating RFC2047-encoded MIME parameters with mutt is, however, a
standards violation that is *not* going to make it into the code.
RFC2231 is the standard for this.  Mutt implements that standard.
That's all I have to say about this.
-- 
Thomas Roessler · Personal soap box at <http://log.does-not-exist.org/>.

On 2003-12-26 09:10:29 -0200, Carlos Laviola wrote:
> From: Carlos Laviola <claviola <at> ax.net.br>
> To: Alain Bench <veronatif <at> free.fr>
> Cc: 222191 <at> bugs.debian.org, mutt-dev <at> mutt.org
> Date: Fri, 26 Dec 2003 09:10:29 -0200
> Subject: Re: Bug#222191: patch-1.4.1.tt.compat.1 for mutt fixes this bug
> X-Spam-Level: 
> 
> On Fri, Dec 19, 2003 at 03:30:36PM +0100, Alain Bench wrote:
> > Hi Carlos,
> > 
> >  On Tuesday, December 16, 2003 at 9:00:09 PM -0200, Carlos Laviola wrote:
> > 
> > > This [patch-1.4.1.tt.compat.1-ter] implements some cool features from
> > > the mutt-ja project
> > 
> >     Nice work, thanks for the adaptation to 1.5.5.1/CVS. Can I make 4
> > quick little unsure and untested comments?
> > 
> >  1) You removed all 1.4.1 pgp.c changes. You may want to look at

[Announce] Mutt-1.5.6 is out.

Mutt 1.5.6 is available from ftp.mutt.org.  This is the latest
snapshot from the development branch.  It's also, I hope, the last
version of mutt that's traveling through a 56k analog modem for its
release.

Feature-wise, the most relevant news is that this version has an
"alternates" command instead of the $alternates variable, and that
subscribe and lists take lists of regular expressions.

Regards,
--

-- 
Thomas Roessler · Personal soap box at <http://log.does-not-exist.org/>.

Patch for "tag-prefix and macros" bug

Hi,

I'm trying to send the herewith attached mail to the bug database, but
apparently, the SMTP server for bugs.guug.de is down. So I'm sending
it directly here.

What do you think of it?

-- 
Lionel

From: Lionel Elie Mamane <lionel <at> mamane.lu>
Subject: Patch for "tag-prefix and macros" bug
Date: 2004-02-01 22:20:38 GMT

tags 1385 +patch
thanks

I have at last found the time and energy to correct the bug I reported
ages ago. As bug #1562 (duplicate) says more precisely, the problem is
that the tag-prefix acts only on the first command of a macro, which
in my case was a no-op. The problem comes from the fact that mutt
macros are like C macros: textual replacement. So "<tag-prefix><F2>",
if F2 is bound to ab, expands to "<tag-prefix>ab". The "<tag-prefix>"
applies only to the *next* function, and here you are.

Re: Patch for "tag-prefix and macros" bug

* Lionel Elie Mamane <lionel <at> mamane.lu> [2004-02-01 23:32 +0100]:
> By reading the code, I found out about <tag-prefix-cond> and
> <end-cond>. These don't seem to be documented anywhere (except the
> ChangeLog).

http://www.rachinsky.de/nicolas/mutt.html

> The behaviour wasn't consistent: In
> "<tag-prefix-cond>ab<end-cond>c", if there are messages tagged, only a
> operates on them and b and c operate on the current message, but this
> sequence is equivalent to "c" when there are no messages
> tagged.

That's the intended behaviour. Why is this inconsistent? The
functionality is useful, since without it, you can't do many things.

I 'push' some cleanup commands on entering a folder, without
tag-prefix-cond the commands would move away on the current message
if there are no messages to remove.

Nicolas

Re: Patch for "tag-prefix and macros" bug

On Mon, Feb 02, 2004 at 12:27:14AM +0100, Nicolas Rachinsky wrote:
> * Lionel Elie Mamane <lionel <at> mamane.lu> [2004-02-01 23:32 +0100]:

>> By reading the code, I found out about <tag-prefix-cond> and
>> <end-cond>. These don't seem to be documented anywhere (except the
>> ChangeLog).

> http://www.rachinsky.de/nicolas/mutt.html

I meant "in the mutt tarball", obviously. :) I hadn't noticed that the
code is new code, though: 1.5.5!

>> The behaviour wasn't consistent: In
>> "<tag-prefix-cond>ab<end-cond>c", if there are messages tagged,
>> only a operates on them and b and c operate on the current message,
>> but this sequence is equivalent to "c" when there are no messages
>> tagged.

> That's the intended behaviour. Why is this inconsistent?

Because the part that is skipped (if nothing is tagged) is not equal
to the part that operates on the tagged messages.

> The functionality is useful, since without it, you can't do many
> things.

I didn't say that such a functionality, if correctly working, is not
useful. In fact, I think quite the contrary: My first reaction was
"Wow, mutt will never cease to amaze me; it is even more powerful than
I thought".