Re: What's needed for mutt 1.6?

A useful feature would be providing the equivalent of the  
mime_forward configuration variable but which applies to replies
(i.e.mime_reply which allows reply with attachments).  This allows  
one to preserve the original note and its formatting.

It would also be nice to have mechanisms to simplify composing  
multipart/alternative e-mail. There has been a patch
that provides the basics for this for sometime (with group- 
alternatives and move-up, move-down). Here's one version
of that patch:

http://comments.gmane.org/gmane.mail.mutt.devel/2748?set_lines=100000

I've made changes on top this to address some of its limitations  
(i.e. moving the first attachment, postponing, attaching after
the current selected attachment instead of at the end of the  
attachment list, ungrouping,  etc)

Jim

[2007-03-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.

2007-02-28 17:47:13  Brendan Cully  <brendan <at> kublai.com>  (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  <vvv <at> mutt.org.ua>  (brendan)

	* po/ru.po: Updated Russian translation.

2007-02-28 07:36:33  TAKAHASHI Tamotsu	<ttakah <at> lapis.plala.or.jp>
(brendan)

	* po/ja.po: Updated Japanese translation.

2007-02-27 20:53:13  Brendan Cully  <brendan <at> kublai.com>  (brendan)

	* hcache.c: Bump hcache version after $assumed_charset BODY
	change.

	* init.h: Fix init.h preprocessing when USE_SMTP is not set.

2007-02-27 17:44:09  TAKIZAWA Takashi  <taki <at> luna.email.ne.jp>	(brendan)

	* mutt.h, parse.c, rfc2047.c, rfc2047.h, rfc2231.c, sendlib.c,

Re: What's needed for mutt 1.6?

* On 2007.02.28, in <EC154266-C141-4992-AC21-B5D961665F5B <at> austin.rr.com>,
*	"Jim Allen" <jpallen <at> austin.rr.com> wrote:
> 
> It would also be nice to have mechanisms to simplify composing  
> multipart/alternative e-mail. There has been a patch
> that provides the basics for this for sometime (with group- 
> alternatives and move-up, move-down). Here's one version
> of that patch:
> 
> http://comments.gmane.org/gmane.mail.mutt.devel/2748?set_lines=100000
> 
> I've made changes on top this to address some of its limitations  
> (i.e. moving the first attachment, postponing, attaching after
> the current selected attachment instead of at the end of the  
> attachment list, ungrouping,  etc)

Your version sounds more complete, but FWIW I last updated mine for
1.5.11:

http://home.uchicago.edu/~dgc/sw/mutt/patch-1.5.11.dgc.groupalts.2

If there's anything there that you'd like to add to yours and shepherd
toward committal, you're welcome to it.  (The documentation was updated
to docbook, for example, as well as fixes for a couple of bugs that you
mentioned.)

--

-- 
 -D.    dgc <at> uchicago.edu        NSIT    University of Chicago

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

>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 karsten%phifo <at> germany.eu.net =karsten.ottenberg

  Error in /home/utcke/.mutt/fcc, line 132: error in pattern at: karsten%phifo <at> 
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).

Re: What's needed for mutt 1.6?

> 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

Brendan Cully <brendan <at> kublai.com>, 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 

mutt/2809: wish: collapse sub-thread

>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. <delete-subthread>,
<read-subthread>, and so on. But what I'm missing is
<collapse-subthread> 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?

* On Thu, Feb 22, 2007 Brendan Cully (brendan <at> kublai.com) 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 mah <at> ka4ybr.com, Mark A. Horton KA4YBR)

PGP-Key-ID: 0xDC1A44DD
Jabber:     init[0] <at> amessage.de

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

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   <roessler <at> does-not-exist.org>

On 2007-03-01 11:54:54 +0000, Taleb Hakim wrote:
> From: Taleb Hakim <taleb <at> daps.finances.gov.ma>
> To: mutt-users <at> mutt.org
> Date: Thu, 1 Mar 2007 11:54:54 +0000
> 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)

* 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! --->> <http://www.blacktrash.org/baustellen.html>

# HG changeset patch
# User Christian Ebert <blacktrash <at> gmx.net>
# Date 1172751178 -3600
# Node ID 819ef6a7be0672ac8461faea6e4a9e940b9c7427
# Parent  42595801073eb5bfca435a65de87162a1c2c0824
Maildir indicator patch by Olaf Hering

Apply patch from Message-Id: <E1GmK4L-0006yI-Kz <at> trithemius.gnupg.org>
against 1.5.14.
Original patch by: Olaf Hering <olaf <at> aepfle.de>

diff -r 42595801073e -r 819ef6a7be06 PATCHES
--- a/PATCHES	Thu Mar 01 06:05:39 2007 +0000