[2003-12-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.

bug#1722: mutt-: .

Package: mutt
Version: 
Severity: wishlist

-- Please type your report below this line

-- Build environment information

(Note: This is the build environment installed on the system
muttbug is run on.  Information may or may not match the environment
used to build mutt.)

- gcc version information
gcc
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

- CFLAGS
-Wall -pedantic -g -O2

-- Mutt Version Information

--- Begin /usr/local/mutt/etc/Muttrc
ignore "from " received content- mime-version status x-status message-id
ignore sender references return-path lines
macro index \eb '/~b ' 'search in message bodies'
macro index \cb |urlview\n 'call urlview to extract URLs out of a message'
macro pager \cb |urlview\n 'call urlview to extract URLs out of a message'
macro generic <f1> "!less /usr/local/mutt/doc/mutt/manual.txt\n" "Show Mutt documentation"
macro index   <f1> "!less /usr/local/mutt/doc/mutt/manual.txt\n" "Show Mutt documentation"

bug#1722: marked as done (mutt-: .)

Your message dated Mon, 1 Dec 2003 14:42:20 -0500
with message-id <20031201194220.GR73325 <at> zk3.dec.com>
and subject line bug#1722: mutt-: .
has caused the attached bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Herr der Kaefer
(administrator, GUUG bugs database)

--------------------------------------
Received: (at submit) by bugs.guug.de; 1 Dec 2003 14:52:29 +0000
From root <at> evilspirits.sarang.net Mon Dec 01 15:52:28 2003
Received: from [155.230.17.154] (helo=evilspirits.sarang.net ident=root)
	by trithemius.gnupg.org with esmtp (Exim 3.35 #1 (Debian))
	id 1AQpPX-0005Le-00
	for <submit <at> bugs.guug.de>; Mon, 01 Dec 2003 15:52:27 +0100
Received: (from root <at> localhost)
	by evilspirits.sarang.net (8.10.1/8.10.1) id hB1Eh0F16883;
	Mon, 1 Dec 2003 23:43:00 +0900
Date: Mon, 1 Dec 2003 23:43:00 +0900
From: root <root <at> evilspirits.sarang.net>
Message-Id: <200312011443.hB1Eh0F16883 <at> evilspirits.sarang.net>
Subject: mutt-: .

[1.4i PATCH] current mailbox as default outbox

Hi,

one of my needs is to follow my own mails in a thread.
Using many mboxes, I have to save the outgoing message in the mbox where
I answered a mail.

 patch-1.3.23.bj.current_shortcut.1 couldn't work for me  (?)
(using ^ as current mbox shortcut in a fcc-hook)

So I wrote the following one activating the feature with a muttrc
variable: save_current

BTW,

    - I used diff -pruN,
      is there a better way ?

    - what is a patch level number ?

any suggestion welcome.

thx

--

-- 
richard hitier

diff -pruN mutt-1.4.orig/PATCHES mutt-1.4/PATCHES
--- mutt-1.4.orig/PATCHES	Mon Dec  1 22:05:14 2003
+++ mutt-1.4/PATCHES	Mon Dec  1 22:55:25 2003

[2003-12-02] 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.

blank line at top of Compose menu

I recently turned off the help-bar at the top of mutt, by way of the
"help" configuration option.  As a result, I've found that I'm mildly
irritated by the blank line left in its place in the Compose menu.
(as far as I know, this is the only menu so affected.. Mailboxes and
the message index use the top line, as I expect and want them to.)

So, I decided to dive into the source code, to see if I could make all
the envelope header lines move one line upward.  Looks like the code
that draws them is relatively simple and easy to find (compose.c), but
it also looks like the fix would not be as trivial as I had hoped.

Since the vertical positions of the envelope headers are specified by
an enumeration (HDR_FROM, HDR_TO, and so on) I can't just make a
change to a single function.  My first attempt was to use a temporary
variable, and then change 'draw_envelope_addr (HDR_FROM, ...)'  to
'draw_envelope_addr (HDR_FROM - minus, ...)'.  Unfortunately, this
throws off the prompt indexing of draw_envelope_header, and also
leaves out the crypto and/or mixmaster lines, if present.  (It may
throw off the attachment line as well, I didn't check.)

So I was wondering if anyone had some good advice on how best to fix
this.  One idea I had was to write all the envelope lines to a buffer,
then iterate over that buffer, putting them in the next available
space.  This would use up some extra heap space, though.  Another
option would be some sort of loop.. or at least a 'row' variable which
would be incremented with each new displayed header.  Would it make
sense to use non-absolute movement when drawing these lines?

Anyway, I've babbled on quite a bit about such a tiny fix.  If I knew
the right way to do it, I probably could have done it in this time.

$resolve not followed after tagging a message?

Using mutt 1.5.5.1 (or 1.4), if I tag a message, and there's a deleted
message underneath, the bar advances to the deleted message, and not to
the next undeleted message.

Is this a bug or a feature?

--

-- 
"Since when is skepticism un-American?
Dissent's not treason but they talk like it's the same..."
(Sleater-Kinney - "Combat Rock")

bug#1723: mutt-1.5.4i: [PATCH] New tag ~M for message filename

Package: mutt
Version: 1.5.4i
Severity: wishlist

-- Please type your report below this line
I use MH folders so that I can have full-text indexing on certain "hot"
folders.

I moved to MH folders because with MBOX folders, all you get is the line
number of matching messages, which is useless. With MH folders, you get the
filename of the actual message, which is great!

.. except that mutt doesn't expose the underlying message filename. Even in
unordered mode, h->msgno is just some monotonically increasing integer. There
is no way to query or limit messages based on their filenames, so I'm forced
to do my search, open the message with an editor, read the Subject, then
search on that. This is obviously no good.

The attached patch (against mutt-1.5.5.1i) adds a new tag ~M for the message's
path. It solves my problem by letting me cut out the middle step: given a
filename, I can jump to that message immediately by searching for it.

Feel free to use this patch in whatever way you see fit. I hereby put this
patch into the public domain, etc, etc.

Notes:

 * this version uses eat_regexp, which means you can't do a range of messages
   cleanly. (That's too bad for MH-style folders.)

bug#1724: mutt-1.5.1i-ja.1: cannot use ~h pattern match with reply-hook

Package: mutt
Version: 1.5.1i-ja.1
Severity: normal

-- Please type your report below this line

I tried this line in .muttrc, in an attempt to match the From: header
with the language, but at start-up Mutt complains that it cannot be used
in this mode:

   '~h "(iso-2022-jp|euc-jp)"' my_hdr 'From: \"MyJaName\" <netb <at> my.add>'

-- Build environment information

(Note: This is the build environment installed on the system
muttbug is run on.  Information may or may not match the environment
used to build mutt.)

- gcc version information
gcc
Using builtin specs.
gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)

- CFLAGS
-Wall -pedantic -g -O2

-- Mutt Version Information

Mutt 1.5.1i-ja.1 (2002-05-02)
Copyright (C) 1996-2001 Michael R. Elkins and others.

bug#1716: mutt-1.5.5.1i: reply flag is not set when reply-mail was postponed

 On Friday, November 28, 2003 at 11:18:33 PM +0100, Sascha Wilde wrote:

> I hope following this step by step will reproduce the bug for you...

    Yes, thanks. Also 1.4 and even 1.2.5 had the bug. Triggering it can
be done with two steps only:

 - 1) To be in the pager.
 - 2) Recall the reply thru <mail> and "Recall postponed message?" yes.

    This suffices for the original mail not being /answered/ after
sending reply. Any PGP status, any message displayed in pager. Step 2
done in index works OK, <recall-message> from pager (or index) works OK.

    The attached little patch fixes the bug, but needs more testing
against side effects (I had one unexplained and unreproducible failure
while experimenting: Hopefully just a false move...).

    [flagging in another mailbox]
> Anyway another (stupid?) idea: when sending an reply and the
> referenced MID can't be found in the aktive mailbox, write the MID
> into an special file. Later, when opening an other mailbox, that file
> could be used (maybe via the folder-hook) to look in the mailbox for
> the unresolved original messages and flag it, when found.

    Not stupid, thanks for the idea.

Bye!	Alain.
--

-- 
set honor_followup_to=yes in muttrc is the default value, and makes your