mutt: 3 new changesets

[Brendan Cully]

3 new changesets in mutt:

http://dev.mutt.org/hg/mutt/rev/c6fe0bb8cf11
changeset:   5917:c6fe0bb8cf11
branch:  HEAD
tag: tip
user:Antonio Radici 
date:Thu Jun 18 15:06:14 2009 +0200
summary: Provide smime_keys(1). Closes #3272.

http://dev.mutt.org/hg/mutt/rev/508bfe4a2e23
changeset:   5916:508bfe4a2e23
branch:  HEAD
user:Rocco Rutte 
date:Thu Jun 18 14:56:54 2009 +0200
summary: Backout experimental patch

http://dev.mutt.org/hg/mutt/rev/aca707871bcf
changeset:   5915:aca707871bcf
branch:  HEAD
user:Rocco Rutte 
date:Thu Jun 18 14:45:55 2009 +0200
summary: UPDATING: add note about -a and --

-- 
Repository URL: http://dev.mutt.org/hg/mutt

Re: [Mutt] #1362: mutt does not change ctime of mbox files after

[Mutt]

#1362: mutt does not change ctime of mbox files after changing message 
attributes
---+
  Reporter:  Debian User   |   Owner:  mutt-dev
  Type:  defect|  Status:  closed  
  Priority:  trivial   |   Milestone:  
 Component:  mutt  | Version:  1.4i
Resolution:  fixed |Keywords:  patch   
---+

Comment(by Rocco Rutte ):

 (In [bd59be56c6b0]) Don't mangle atime/mtime for mbox folders without new
 mail upon sync. Closes #1362, #3271.

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3271: mutt 1.5.20 regression: not updating time fields

[Mutt]

#3271: mutt 1.5.20 regression: not updating time fields on mbox
---+
  Reporter:  anto...@dyne.org  |   Owner:  pdmef 
  Type:  defect|  Status:  closed
  Priority:  minor |   Milestone:  1.6   
 Component:  mutt  | Version:  1.5.20
Resolution:  fixed |Keywords:
---+
Changes (by Rocco Rutte ):

  * status:  accepted => closed
  * resolution:  => fixed


Comment:

 (In [bd59be56c6b0]) Don't mangle atime/mtime for mbox folders without new
 mail upon sync. Closes #1362, #3271.

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3271: mutt 1.5.20 regression: not updating time fields

[Mutt]

#3271: mutt 1.5.20 regression: not updating time fields on mbox
---+
  Reporter:  anto...@dyne.org  |   Owner:  pdmef   
  Type:  defect|  Status:  accepted
  Priority:  minor |   Milestone:  1.6 
 Component:  mutt  | Version:  1.5.20  
Resolution:|Keywords:  
---+

Comment(by pdmef):

 Replying to [comment:6 dylex]:
 > I have the same problem with zsh's MAILCHECK on 1.5.20.  The logic zsh
 uses is: {{{ st.st_size && st.st_atime <= st.st_mtime && st.st_mtime >
 lastmailcheck }}}.  Applying the patch above fixed the problem for me.

 Is there any chance you can try this: open an mbox folder that has no new
 mail, change a mail to being new, sync the folder and exit. Does mutt then
 report new mail? And zsh?

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3271: mutt 1.5.20 regression: not updating time fields

[Mutt]

#3271: mutt 1.5.20 regression: not updating time fields on mbox
---+
  Reporter:  anto...@dyne.org  |   Owner:  pdmef   
  Type:  defect|  Status:  accepted
  Priority:  minor |   Milestone:  1.6 
 Component:  mutt  | Version:  1.5.20  
Resolution:|Keywords:  
---+

Comment(by anto...@dyne.org):

 From the reporter:

 {{{
 Hi Antonio and Rocco,

 Thanks, but I'm still seeing the bug with 1.5.20-1+fix533439.
 Setting the access time to be equal to the modification time
 seems to be an edge case that works for Bash but not XBiff.

 xbiff's algorithm ("reset" means the user clicked on xbiff with
 the mouse):
  Now check for changes.  If reset is set then we want to pretent that
  there is no mail.  If the mailbox is empty then we want to turn off
  the flag.  Otherwise if the mailbox has changed size then we want to
  put the flag up, unless the mailbox has been read since the last
  write.

  The cases are:
 o  forced reset by userDOWN
 o  no mailbox or empty (zero-sized) mailboxDOWN
 o  if read after most recent write DOWN
 o  same size as last time  no change
 o  bigger than last time   UP
 o  smaller than last time but non-zero UP


 Mutt's mbox(5) manpage matches Mutt 1.5.20's system:
  If the modification-time (usually determined via stat(2)) of a
  nonempty mbox file is greater than the access-time the file has
  new mail.

 I'm not sure what to do with this bug now.




 Some test results:

 xbiff only checks for updates every 30 seconds, unless it's
 forced to redraw by being obscured and then exposed (which I'm
 doing at every stage in testing this).

 Similarly I've set bash's MAILCHECK delay to 1 second.

 I'm running "frm" in the middle (package mailutils, lists the
 headers of all mails), but omitting that step doesn't change the
 results of the other steps.

 During the test below, there is other mail in the mailbox, but
 none of it has the "old" or "new" flags set.

 New mail received
 xbiff: new mail
 bash: you have new mail (or sometimes just "you have mail")

File: `/var/mail/steve'
Size: 731600 Blocks: 1440   IO Block: 4096   regular file
  Device: 807h/2055d Inode: 570084  Links: 1
  Access: (0660/-rw-rw)  Uid: ( 1010/   steve)   Gid: ( 1010/   steve)
  Access: 2009-06-19 10:48:28.0 +0100
  Modify: 2009-06-19 10:50:35.0 +0100
  Change: 2009-06-19 10:50:35.0 +0100

 Run "frm"
 xbiff: clear
 bash: (no prompt)

File: `/var/mail/steve'
Size: 731600 Blocks: 1440   IO Block: 4096   regular file
  Device: 807h/2055d Inode: 570084  Links: 1
  Access: (0660/-rw-rw)  Uid: ( 1010/   steve)   Gid: ( 1010/   steve)
  Access: 2009-06-19 10:51:25.0 +0100
  Modify: 2009-06-19 10:50:35.0 +0100
  Change: 2009-06-19 10:50:35.0 +0100

 Run mutt, read the mail, leave it in the mailbox and exit
 xbiff: new mail
 bash: (no prompt)

File: `/var/mail/steve'
Size: 731638 Blocks: 1440   IO Block: 4096   regular file
  Device: 807h/2055d Inode: 570084  Links: 1
  Access: (0660/-rw-rw)  Uid: ( 1010/   steve)   Gid: ( 1010/   steve)
  Access: 2009-06-19 10:50:35.0 +0100
  Modify: 2009-06-19 10:50:35.0 +0100
  Change: 2009-06-19 10:52:02.0 +0100

 Run mutt a second time and exit immediately
 xbiff: clear
 bash: (no prompt)

File: `/var/mail/steve'
Size: 731638 Blocks: 1440   IO Block: 4096   regular file
  Device: 807h/2055d Inode: 570084  Links: 1
  Access: (0660/-rw-rw)  Uid: ( 1010/   steve)   Gid: ( 1010/   steve)
  Access: 2009-06-19 10:52:40.0 +0100
  Modify: 2009-06-19 10:50:35.0 +0100
  Change: 2009-06-19 10:52:40.0 +0100

 Cheers,
 Steve
 }}}

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3135: cannot stop header wrap/folding;

[Mutt]

#3135: cannot stop header wrap/folding; wrapping ignores user $wrap setting
--+-
  Reporter:  idallen  |   Owner:  pdmef  
  Type:  defect   |  Status:  started
  Priority:  minor|   Milestone:  1.6
 Component:  mutt | Version:  1.5.18 
Resolution:   |Keywords:  wrap header fold folding terminal width
--+-

Comment(by pdmef):

 Replying to [comment:12 idallen]:

 > Wrapping *anything* against the user's will is not reasonable, even
 headers.

 Well, I thought quite some time about this sentence. Regardless of what
 any standard says, this makes lots of sense. So here we go, I attached a
 fix to it that allows specifying $wrap_headers between 50 and 998 chars.
 50 is just some arbitrary number so it doesn't get too short. Maybe we
 should even raise that to the recommended 78.

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3271: mutt 1.5.20 regression: not updating time fields

[Mutt]

#3271: mutt 1.5.20 regression: not updating time fields on mbox
---+
  Reporter:  anto...@dyne.org  |   Owner:  pdmef   
  Type:  defect|  Status:  accepted
  Priority:  minor |   Milestone:  1.6 
 Component:  mutt  | Version:  1.5.20  
Resolution:|Keywords:  
---+

Comment(by pdmef):

 I've updated the patch to really not mangle atime by resetting it back to
 where it was before the changing the file. This is what the old working
 code did. The atime is modified if and only if the mailbox has at least
 one new mail and atime is newer than mtime. The last version errorneously
 also set atime=mtime if no new message was found.

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3264: Erroneous "invalid IMAP path" stops mutt cold

[Mutt]

#3264: Erroneous "invalid IMAP path" stops mutt cold
-+--
  Reporter:  rdump   |   Owner:  mutt-dev
  Type:  defect  |  Status:  closed  
  Priority:  major   |   Milestone:  
 Component:  mutt| Version:  1.5.20  
Resolution:  fixed   |Keywords:  
-+--
Changes (by sthen):

 * cc: sthen (added)


-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3264: Erroneous "invalid IMAP path" stops mutt cold

[Mutt]

#3264: Erroneous "invalid IMAP path" stops mutt cold
-+--
  Reporter:  rdump   |   Owner:  mutt-dev
  Type:  defect  |  Status:  new 
  Priority:  major   |   Milestone:  
 Component:  mutt| Version:  1.5.20  
Resolution:  |Keywords:  
-+--
Changes (by dhill):

  * status:  closed => new
  * resolution:  fixed =>


Comment:

 The new patch breaks my mutt when sending an email.

 folder-hook work set smtp_url=smtp://davidh:mypassw...@mail.server.net:587

 Removing ':587' from the line fixes it.


 Uploading message... 0K/0.3K (0%)
 Program received signal SIGSEGV, Segmentation fault.
 url_pct_decode (s=0x24b ) at url.c:56
 56  url.c: No such file or directory.
 in url.c
 (gdb) bt
 #0  url_pct_decode (s=0x24b ) at url.c:56
 #1  0x1c063327 in ciss_parse_userhost (ciss=0xcfbcb120, src=0x8567d407
 "davidh") at url.c:154
 #2  0x1c0633c0 in url_parse_ciss (ciss=0xcfbcb120, src=0x8567d400
 "smtp://davidh") at url.c:169
 #3  0x1c0717d4 in smtp_fill_account (account=0xcfbcb560) at smtp.c:336
 #4  0x1c071566 in mutt_smtp_send (from=0x24b, to=0x7cbff080, cc=0x0,
 bcc=0x0,
 msgfile=0xcfbcb710 "/tmp/mutt-wind-1000-16619-4", eightbit=0) at
 smtp.c:262
 #5  0x1c053118 in send_message (msg=0x7cddc700) at send.c:1030
 #6  0x1c053b46 in ci_send_message (flags=0, msg=0x7cddc700, tempfile=0x0,
 ctx=0x877a6180, cur=0x0)
 at send.c:1685
 #7  0x1c019c60 in mutt_index_menu () at curs_main.c:1943
 #8  0x1c030bc2 in main (argc=1, argv=0xcfbcd024) at main.c:1020

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3264: Erroneous "invalid IMAP path" stops mutt cold

[Mutt]

#3264: Erroneous "invalid IMAP path" stops mutt cold
-+--
  Reporter:  rdump   |   Owner:  pdmef   
  Type:  defect  |  Status:  accepted
  Priority:  major   |   Milestone:  1.6 
 Component:  mutt| Version:  1.5.20  
Resolution:  |Keywords:  
-+--
Changes (by pdmef):

  * owner:  mutt-dev => pdmef
  * status:  new => accepted
  * milestone:  => 1.6


Comment:

 Replying to [comment:3 dhill]:
 > The new patch breaks my mutt when sending an email.
 >
 > folder-hook work set
 smtp_url=smtp://davidh:mypassw...@mail.server.net:587
 >
 > Removing ':587' from the line fixes it.

 I guess you have proper quotes for the folder-hook? Does adding a slash
 help? The parser had a bug when no trailing slash for the path was
 present, but that is fixed and your example works fine in my unit tests.
 For the current parser I get:

 {{{
 url=[smtp://davidh:mypassw...@mail.server.net:587]
 rc=0 scheme=5 user=[davidh] pass=[mypassword] host=[mail.server.net]
 port=587 path=[]
 }}}

 which is correct. What version do you use?

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

changeset 5920 / manual.xml.head

[Vincent Lefevre]

A paragraph added in r5920 in doc/manual.xml.head:

  Whenever a user-defined variable is used in an assignment for a built-in
  variable or vice versa, Mutt string representations to do the
  assignment. As a result, a user-defined variable can be assigned to any
  other variable under the restriction that its content is valid. See the
  following section for examples.

I don't understand the first sentence.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: [Mutt] #3264: Erroneous "invalid IMAP path" stops mutt cold

[Mutt]

#3264: Erroneous "invalid IMAP path" stops mutt cold
-+--
  Reporter:  rdump   |   Owner:  pdmef 
  Type:  defect  |  Status:  closed
  Priority:  major   |   Milestone:  1.6   
 Component:  mutt| Version:  1.5.20
Resolution:  fixed   |Keywords:
-+--
Changes (by dhill):

  * status:  accepted => closed
  * resolution:  => fixed


Comment:

 I was using revision 5899.  5901 works fine.  Thanks.

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #2827: deleting attachment on imap and sync removes

[Mutt]

#2827: deleting attachment on imap and sync removes message from index
---+
  Reporter:  Christoph Berg   |   Owner:  mutt-dev
  Type:  defect|  Status:  closed  
  Priority:  minor |   Milestone:  
 Component:  IMAP  | Version:  
Resolution:  worksforme|Keywords:  
---+
Changes (by anto...@dyne.org):

  * status:  new => closed
  * resolution:  => worksforme


Comment:

 not reproducible on 1.5.20-1, I suppose it was fixed in the meantime

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #1385: Macros with "" don't work on

[Mutt]

#1385: Macros with "" don't work on tagged messages
---+
  Reporter:  lio...@mamane.lu  |   Owner:  mutt-dev
  Type:  defect|  Status:  new 
  Priority:  trivial   |   Milestone:  
 Component:  mutt  | Version:  1.5.20  
Resolution:|Keywords:  patch   
---+
Changes (by anto...@dyne.org):

  * version:  1.4i => 1.5.20


-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #1611: mutt erroneously omits information in parenthesis

[Mutt]

#1611: mutt erroneously omits information in parenthesis after addresses in Cc
headers
-+--
  Reporter:  Marco d'Itri   |   Owner:  mutt-dev
  Type:  defect  |  Status:  new 
  Priority:  minor   |   Milestone:  
 Component:  mutt| Version:  1.5.20  
Resolution:  |Keywords:  
-+--
Changes (by anto...@dyne.org):

  * version:  => 1.5.20


Comment:

 this bug is still there

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: changeset 5920 / manual.xml.head

[Rocco Rutte]

Hi,

* Vincent Lefevre wrote:

>   Whenever a user-defined variable is used in an assignment for a built-in
>   variable or vice versa, Mutt string representations to do the
>   assignment. As a result, a user-defined variable can be assigned to any
>   other variable under the restriction that its content is valid. See the
>   following section for examples.

> I don't understand the first sentence.

When you assign a new value to a variable, you may use a my_ variables
using $my_ syntax regardless of what type the target variable is. This
is because mutt uses string representations of both and parses it for
the to-be-assigned var.

For example pager_index_lines is a number, and when you do:

set my_foo=$pager_index_lines

my_foo still is a string because pager_index_lines was converted to
string before the assignment was made. And the same vice versa:

set pager_index_lines=$my_foo

parses the string in $my_foo to an integer number.

Any suggestions for a better wording (besides a missing "uses")?

Rocco

Re: [Mutt] #1771: Screen left in strange mode when piping mail with

[Mutt]

#1771: Screen left in strange mode when piping mail with unknown mime-types
---+
  Reporter:  Artur R.Czechowski   |   Owner:  mutt-dev
  Type:  defect|  Status:  new 
  Priority:  minor |   Milestone:  
 Component:  display   | Version:  1.5.20  
Resolution:|Keywords:  
---+
Changes (by anto...@dyne.org):

  * version:  => 1.5.20


Comment:

 Hi,
 I've just tested it and this is still reproducible against 1.5.20

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #1362: mutt does not change ctime of mbox files after

[Mutt]

#1362: mutt does not change ctime of mbox files after changing message 
attributes
---+
  Reporter:  Debian User   |   Owner:  mutt-dev
  Type:  defect|  Status:  closed  
  Priority:  trivial   |   Milestone:  
 Component:  mutt  | Version:  1.4i
Resolution:  fixed |Keywords:  patch   
---+

Comment(by Rocco Rutte ):

 (In [9ae13dedb5ed]) Fixup atime for mbox/mmdf also when mailbox is
 unchanged but has new mail. See #1362.

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #1611: mutt erroneously omits information in parenthesis

[Mutt]

#1611: mutt erroneously omits information in parenthesis after addresses in Cc
headers
-+--
  Reporter:  Marco d'Itri   |   Owner:  mutt-dev
  Type:  defect  |  Status:  new 
  Priority:  minor   |   Milestone:  
 Component:  mutt| Version:  1.5.20  
Resolution:  |Keywords:  
-+--

Comment(by agriffis):

 Those don't look like legal address specs to me.  See
 http://tools.ietf.org/html/rfc5322#section-3.4

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #1611: mutt erroneously omits information in parenthesis

[Mutt]

#1611: mutt erroneously omits information in parenthesis after addresses in Cc
headers
-+--
  Reporter:  Marco d'Itri   |   Owner:  mutt-dev
  Type:  defect  |  Status:  new 
  Priority:  minor   |   Milestone:  
 Component:  mutt| Version:  1.5.20  
Resolution:  |Keywords:  
-+--

Comment(by agriffis):

 Even as far back as RFC 822 it wasn't legal to put stuff after the
 .  See http://tools.ietf.org/html/rfc822#section-6

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

[PATCH] remove bogus FREE

[Aron Griffis]

# HG changeset patch
# User Aron Griffis 
# Date 1245455779 14400
# Branch HEAD
# Node ID ee3d174297bb38fd461253f5f8d340c31a7db4c8
# Parent  9ae13dedb5ede4d0bfbbd65e21a200bae23b4e3b
remove bogus FREE

It's impossible for cur->personal to be non-NULL at this point,
since cur was calloc'd just a couple lines prior.

Signed-off-by: Aron Griffis 

diff --git a/rfc822.c b/rfc822.c
--- a/rfc822.c
+++ b/rfc822.c
@@ -451,8 +451,6 @@
   cur = rfc822_new_address ();
   if (phraselen)
   {
-	if (cur->personal)
-	  FREE (&cur->personal);
 	/* if we get something like "Michael R. Elkins" remove the quotes */
 	rfc822_dequote_comment (phrase);
 	cur->personal = safe_strdup (phrase);

Re: [Mutt] #1611: mutt erroneously omits information in parenthesis

[Mutt]

#1611: mutt erroneously omits information in parenthesis after addresses in Cc
headers
-+--
  Reporter:  Marco d'Itri   |   Owner:  mutt-dev
  Type:  defect  |  Status:  new 
  Priority:  minor   |   Milestone:  
 Component:  mutt| Version:  1.5.20  
Resolution:  |Keywords:  
-+--
Changes (by agriffis):

 * cc: agrif...@n01se.net (added)


-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #3271: mutt 1.5.20 regression: not updating time fields

[Mutt]

#3271: mutt 1.5.20 regression: not updating time fields on mbox
---+
  Reporter:  anto...@dyne.org  |   Owner:  pdmef 
  Type:  defect|  Status:  closed
  Priority:  minor |   Milestone:  1.6   
 Component:  mutt  | Version:  1.5.20
Resolution:  fixed |Keywords:
---+
Changes (by roger_):

 * cc: wen...@gmail.com (added)


Comment:

 Replying to [comment:9 pdmef]:

 The patch's working for me on dpkg-source extracted source.

-- 
Ticket URL: 
Mutt 
The Mutt mail user agent

Re: [Mutt] #1611: mutt erroneously omits information in parenthesis

[Derek Martin]

On Fri, Jun 19, 2009 at 10:15:25PM -0500, Derek Martin wrote:
> On Fri, Jun 19, 2009 at 11:43:02PM -, Mutt wrote:
> > #1611: mutt erroneously omits information in parenthesis after addresses in 
> > Cc
> > headers
> > -+--
> >   Reporter:  Marco d'Itri   |   Owner:  mutt-dev
> >   Type:  defect  |  Status:  new 
> >   Priority:  minor   |   Milestone:  
> >  Component:  mutt| Version:  1.5.20  
> > Resolution:  |Keywords:  
> > -+--
> > 
> > Comment(by agriffis):
> > 
> >  Those don't look like legal address specs to me.  See
> >  http://tools.ietf.org/html/rfc5322#section-3.4
> 
> Keep reading.  See section 4.

Actually I read the spec much too quickly, and got it totally wrong.
It's explicitly allowed in RFC 5322, in section 3.4 that you point to.

  3.4. Address Specification


 Addresses occur in several message header fields to indicate
 senders and recipients of messages.  An address may either be an
 individual mailbox, or a group of mailboxes.

 address =   mailbox / group

 mailbox =   name-addr / addr-spec

 name-addr   =   [display-name] angle-addr

 angle-addr  =   [CFWS] "<" addr-spec ">" [CFWS] /
 obs-angle-addr

See section 3.2.2 for an explanation of [CFWS].  

It is likewise explicitly allowed in RFCs 2822, and 822, and 733.

Note that 822 and 733 are standards; the more recent ones are not (not
that it matters in this case).



pgp0gmOoiDAUE.pgp
Description: PGP signature