headers
Brendan Cully | 1 Dec 2007 09:00
Gravatar

mutt: 2 new changesets

2 new changesets in mutt:

http://dev.mutt.org/hg/mutt/rev/5c635c9b5982
changeset:   5323:5c635c9b5982
branch:      HEAD
tag:         tip
user:        Rocco Rutte <pdmef <at> gmx.net>
date:        Fri Nov 30 10:29:49 2007 +0100
summary:     Add version numbers for bdb 4.6

http://dev.mutt.org/hg/mutt/rev/a32a208f7e4b
changeset:   5322:a32a208f7e4b
branch:      HEAD
user:        Rocco Rutte <pdmef <at> gmx.net>
date:        Fri Nov 30 09:29:37 2007 +0100
summary:     RfC2047 decode/encode X-Label: header (Closes #2970).

--

-- 
Repository URL: http://dev.mutt.org/hg/mutt
Permalink | Reply | 0 comments |
headers
Brian Salter-Duke | 3 Dec 2007 03:05
Picon

Mixmaster

A long time ago, around the end of 2000 according to my notebooks, I 
was involved in using mixmaster and making some code and documentation 
changes which I believe Thomas included. I have not used it since then 
and have no intention of doing so. I now see no need for it. However, 
out of curiosity, I have had a look at the situation briefly.

Back in 2000 there seemed to be very few people using mixmaster with
mutt. It worked with version 2.04 which was stagnant and did not work
with version 2.9 which was in slow development. I see nothing from the
ChangeLog to suggest that has changed.

The manual refers to 2.04beta45 as the latest. There seems to be a 
2.04b46 from 2002. The manual says the latest 2.9 is 2.9b23. There 
seemes to have been quite a bit of development here, with more 2.9 betas 
and three 3.0 betas. The latest appears to be 3.0rc1. 3.0 may be
released "soon". OK, so that is something for the manual. 

The links are http://sourceforge.net/projects/mixmaster/ and
http://mixmaster.sourceforge.net/

Is anyone using mixmaster with mutt? If not, perhaps it should be
removed from the code. If it is not to be removed, the code should
certainly be changed to work with version 3.0.

I hope this is of some use to someone.

Brian.
--

-- 
"First they ignore you, then they laugh at you, then they fight you,
then you win."
(Continue reading)

Permalink | Reply | 3 comments |
headers
Thomas Roessler | 3 Dec 2007 08:45

Re: Mixmaster

On 2007-12-03 13:05:19 +1100, Brian Salter-Duke wrote:

> A long time ago, around the end of 2000 according to my
> notebooks, I was involved in using mixmaster and making some code
> and documentation changes which I believe Thomas included. I have
> not used it since then and have no intention of doing so. I now
> see no need for it. However, out of curiosity, I have had a look
> at the situation briefly.

I haven't used mixmaster since, either, and have no intention of
using it any time soon, either.

> Is anyone using mixmaster with mutt? If not, perhaps it should be
> removed from the code. If it is not to be removed, the code
> should certainly be changed to work with version 3.0.

+1
--

-- 
Thomas Roessler   <roessler <at> does-not-exist.org>
Permalink | Reply | 1 comment |
headers
Mutt | 3 Dec 2007 22:26

[Mutt] #2996: ignore_list_reply_to docs don't mention "subscribe" setting

#2996: ignore_list_reply_to docs don't mention "subscribe" setting

 ignore_list_reply_to does not work as described in the manual/manpage
 unless you have the mailing list set with the "subscribe" command. Perhaps
 the docs could read:

 Affects the behaviour of the reply function when replying to messages from
 mailing lists (as defined by the "subscribe" and "lists" settings.) When
 set, if the "Reply-To:" field is set to the same value as the "To:" field,
 Mutt assumes that the "Reply-To:" field was set by the mailing list to
 automate responses to the list, and will ignore this field. To direct a
 response to the mailing list when this option is set, use the list-reply
 function; group-reply will reply to both the sender and the list.

 (I just added the parens and their contents.)

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/2996>
Permalink | Reply | 1 comment |
headers
Roger Cornelius | 3 Dec 2007 23:36
Favicon

Re: 1.5.17 batch mode does not append .signature

On 11/27/2007 13:38, Aron Griffis wrote:
> Roger Cornelius wrote:  [Tue Nov 27 2007, 11:50:07AM EST]
> > Whether by error or design, mutt 1.5.17 and earlier does not append
> > the .signature file when sending in batch mode.
> 
> Pretty sure it's by design.  Batch mode assumes the complete email on
> stdin and that it shouldn't be modified.

The brief blurb pertaining to batch mode in the manual doesn't mention
this.  Viz:

   Mutt also supports a ``batch'' mode to send prepared messages. Simply
   redirect input from the file you wish to send. For example,

   mutt -s "data set for run #2" professor <at> bigschool.edu < ~/run2.dat

   This command will send a message to ``professor <at> bigschool.edu'' with a
   subject of ``data set for run #2''. In the body of the message will be
   the contents of the file ``~/run2.dat''.

Maybe a line from your email could be added as a caveat:

   Mutt also supports a ``batch'' mode to send prepared messages.  Batch
   mode assumes the complete email on stdin and that it shouldn't be
   modified.  Simply redirect input from the file you wish to send.
   For example,

   ...

The manual's description of the $signature variable also makes no
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mutt | 4 Dec 2007 00:26

[Mutt] #2997: Missparsed/decoded headers in index view on IMAP server

#2997: Missparsed/decoded headers in index view on IMAP server

 Using Gmail's IMAP: messages where the sender has accented characters in
 his realname in From: shows up as a mess =?ISO-8859-1?Q?J=E9r=E9mie?= in
 the "index" view alone. When I look at the raw message, I see that the
 From is indeed quoted. When I reply to a message with this problem, mutt
 suggests "To: =?ISO-8859-1?Q?J=E9r=E9mie?= <myemail <at> email.com>, ?= <at> laptop"
 (where laptop is the name of the computer I am working on).

 HOWEVER, the From: is then displayed correctly when viewing the message,
 either by pressing [ENTER] in the index view on the message, or by
 pressing 'h' (to view everything).

 ALSO, if I moved the message form the IMAP mailbox to a local mailbox,
 when I browse this local mailbox the messages that are copied there (that
 had a problem when they were being viewed in the IMAP mailbox) no longer
 show any signs of this bug. When I copy a message back from the local
 mailbox to the IMAP mailbox, the message is again displayed incorrectly in
 "index" view.

 FINALLY, the messages appear to be displayed correctly in Gmail's web
 client, in Thunderbird and in Alpine (using the same IMAP parameters for
 the last two clients).

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/2997>
Permalink | Reply | 12 comments |
headers
Mutt | 4 Dec 2007 19:30

Re: [Mutt] #2997: Missparsed/decoded headers in index view on IMAP

#2997: Missparsed/decoded headers in index view on IMAP server

Comment (by PaulFertser):

 Here you can see example raw socket data when this problem occurs (sorry
 for formatting, i'm not familiar with trac):

 5< * 3 FETCH (UID 3 RFC822.SIZE 1667 INTERNALDATE "14-Oct-2007 18:15:46
 +0000" FLAGS (\Seen) BODY[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-
 ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO REPLY-TO LINES
 LIST-POST X-LABEL)] {508}

 Handling FETCH

 FETCH response ignored for this message

 imap_read_literal: reading 508 bytes

 From:
 =?KOI8-R?Q?=E5=D7=C7=C5=CE=C9=CA__=E6=C5=D2=C3=C5=D2_<someone <at> mail.ru>?=

 To: Pavel Fertser <me <at> gmail.com>

 Subject: =?KOI8-R?B?7sHa18HOycUgIMbJzNjNwQ==?=

 Date: Sun, 14 Oct 2007 22:15:01 +0400

 References: <20070913185726.GB1690 <at> home.pavel.comp>

 In-Reply-To: <20070913185726.GB1690 <at> home.pavel.comp>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mutt | 4 Dec 2007 19:40

Re: [Mutt] #2953: A source "command|" in /etc/Muttrc prevents

#2953: A source "command|" in /etc/Muttrc prevents screen's altscreen from working

Comment (by Adeodato Simó):

 {{{
 * Mutt [Fri, 30 Nov 2007 08:35:26 -0000]:

 > #2953: A source "command|" in /etc/Muttrc prevents screen's altscreen
 from working

 > Comment (by pdmef):

 >  Umm, this works here. A 'source|' from the system config by no means
 >  different then ser config, except that it gets parsed earlier. Also,
 when
 >  do clear the screen, what do expect to see if you clear the screen
 before
 >  running mutt?

 The difference is that, outside screen, or in a screen without "source |"
 in Muttrc, if you run and quit mutt right after invoking "clear", you see:

   hostname% mutt
   Mailbox is unchanged.
   hostname%

 OTOH, inside screen in a 24-line terminal I'm seeing:

   hostname% mutt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brendan Cully | 4 Dec 2007 19:48
Gravatar

Re: [PATCH] hcache reorganization

On Thursday, 29 November 2007 at 12:43, Rocco Rutte wrote:
> Hi,
>
> since people on mutt-users <at>  reported that hcache db files always kept  
> growing, I looked into it. I can confirm this here for qdbm.
>
> My guess is that the db libraries don't do the costly optimization of  
> really removing dead entries but mark them as dead only. With the  
> attached patch, my cache file sizes went down immedtiately.
>
> However, reorganization is a) only supported by qbdm and gdbm as it  
> seems, and b) may take quite some time (up to 1.2 seconds for a 300k  
> folder with a ~74 MB qdbm-compressed hcache db).
>
> I think once mutt provides caching features and asks the user leave them  
> mostly alone, mutt shouldn't let them grow forever. Hence the attached  
> patch only tries to use the reorg facilities only upon syncing the  
> mailbox every 20th time. The counter is stored within the cache file  
> itself.
>
> Right now this is hardcoded, but I think we might want to increase 20  
> since the disk space gains are measurable but quite low. I don't think  
> this should be user-configurable. A compile-time option might do it, too.
>
> Comments and opinions?

I agree that 20 is too low. I'd like to see this unified with
$message_cache_clean ($cache_clean perhaps?) and default to off. The
disadvantage of that setting is that you have to visit each folder you
want cleaned up while the setting is active. But the advantage is that
(Continue reading)

Permalink | Reply | 1 comment |
headers
Aron Griffis | 5 Dec 2007 00:44
Favicon
Gravatar

sendbox patch, again

Hi all,

This is a repost of my sendbox patch, trivially merged to current
mercurial.  I have posted this before and it hasn't been committed,
I think mostly because it's not a feature for the masses.  Nonetheless
it's a worthwhile feature, has been tested in my own heavy-use
environment for at least a year, so I'm hoping it will be
reconsidered.  Frankly I'm sick of maintaining my own mutt packages on
all the machines where I work, and this patch isn't very big...

The purpose of this patch is to make it possible to send mail using
Courier IMAP's Outbox feature.  I avoided calling this "outbox",
though, because that term is already used in the mutt sources.
Besides, I think sendbox is more explicit.

The Outbox feature works like this: To send mail, it's possible to
nominate a mailbox that will send mails which are saved to it.  This
mailbox acts like any other mailbox otherwise, including storing the
mails that are saved there.

This is desirable for numerous reasons, but here are the most
significant:

- on a slow connection, this allows the mail to be fcc'd and sent with
  the same transmission, rather than hitting the wire twice.

- sending mail from one's mailhost is nice because the mail originates
  from a good server, so your From address is valid and unquestioned

- single channel of mail transferral, easier network configuration and
(Continue reading)

Permalink | Reply | 0 comments |

Gmane