mutt: 2 new changesets

2 new changesets in mutt:

http://dev.mutt.org/hg/mutt/rev/cb251bde7fc1
changeset:   5581:cb251bde7fc1
branch:      HEAD
tag:         tip
user:        Rocco Rutte <pdmef <at> gmx.net>
date:        Sun Nov 30 20:28:53 2008 +0100
summary:     Manage last search pattern outside of menu lifecycle

http://dev.mutt.org/hg/mutt/rev/927a1d30a44e
changeset:   5580:927a1d30a44e
branch:      HEAD
user:        Rocco Rutte <pdmef <at> gmx.net>
date:        Sun Nov 30 20:23:41 2008 +0100
summary:     Start numbering query results with 1 instead of 0

--

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

mutt: new changeset

New changeset in mutt:

http://dev.mutt.org/hg/mutt/rev/1e8252a9e92f
changeset:   5582:1e8252a9e92f
branch:      HEAD
tag:         tip
user:        Rocco Rutte <pdmef <at> gmx.net>
date:        Mon Dec 01 21:27:44 2008 +0100
summary:     Fix some typos to silence compiler warnings

--

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

implicit declaration of function 'mutt_menu_init'

I get the following warning:

init.c: In function 'mutt_init':
init.c:2887: warning: implicit declaration of function 'mutt_menu_init'

This function is declared in "mutt_menu.h". So, init.c should include
this header file.

--

-- 
Vincent Lefèvre <vincent <at> vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: implicit declaration of function 'mutt_menu_init'

Hi,

* Vincent Lefevre wrote:
>I get the following warning:
>
>init.c: In function 'mutt_init':
>init.c:2887: warning: implicit declaration of function 'mutt_menu_init'
>
>This function is declared in "mutt_menu.h". So, init.c should include
>this header file.

Sorry, my fault. The patch was only tested against a patched tree
providing it with some indirection (init.c -> pager.h -> attach.h ->
mutt_menu.h). Fixed, thanks for reporting.

Rocco

mutt: new changeset

New changeset in mutt:

http://dev.mutt.org/hg/mutt/rev/3a8e5756613c
changeset:   5583:3a8e5756613c
branch:      HEAD
tag:         tip
user:        Rocco Rutte <pdmef <at> gmx.net>
date:        Tue Dec 02 16:10:20 2008 +0100
summary:     Include mutt_menu.h in init.c for mutt_menu_init() prototype

--

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

mutt compose error?

I recently updated to the latest mutt source, and the behavior has 
changed in an annoying way. When I compose messages now, mutt *always* 
thinks that my editor has returned a non-zero exit code (specifically: 
1). I use vim, and as far as I can tell, it always exits with a 0 exit 
code.

I ended up patching mutt_edit_file() to ignore what happens when 
mutt_system() returns positive exit codes, just for my own sanity. 
But... did something change recently that would affect this? I don't 
see anything obvious in the code, but...

~Kyle
--

-- 
The greatest dangers to liberty lurk in insidious encroachment by men 
of zeal, well-meaning but without understanding.
                                                            -- Brandeis

Re: mutt compose error?

> I recently updated to the latest mutt source, and the behavior has  
> changed in an annoying way. When I compose messages now, mutt *always*  
> thinks that my editor has returned a non-zero exit code (specifically:  
> 1). I use vim, and as far as I can tell, it always exits with a 0 exit  
> code.

FWIW, I often get this using /usr/bin/vi on opensolaris.  It's not
always (it didn't happen with this message, for example) but it does
happen quite often.  I've been ignoring it, but it is somewhat annoying.

--

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

Re: mutt compose error?

On Wed, Dec 03, 2008 at 10:53:35AM -0600, David Champion wrote:
> > I recently updated to the latest mutt source, and the behavior has  
> > changed in an annoying way. When I compose messages now, mutt *always*  
> > thinks that my editor has returned a non-zero exit code (specifically:  
> > 1). I use vim, and as far as I can tell, it always exits with a 0 exit  
> > code.
> 
> FWIW, I often get this using /usr/bin/vi on opensolaris.  It's not
> always (it didn't happen with this message, for example) but it does
> happen quite often.  I've been ignoring it, but it is somewhat annoying.

I remember reading a thread somewhere at some unremembered past time,
discussing that some versions of vi exit with a non-zero exit code any
time some error occured during the editing session; e.g. if you tried
to write to a file that you didn't have permissions to write to, etc.
As is increasingly the case these days, my memory of the specifics is
rather foggy...  I think the thread suggested that such things as
mundane as searching for a particular pattern, and failing to find it,
would also result in a non-zero exit code.  Very lame, Milhouse.

Whether or not that is the issue here, one suggestion would be to
write a wrapper script, called say, myvim, like so:

  #!/bin/sh
  vim "$@"
  exit 0

Then set mutt to use that as your editor.

--

-- 

Re: [Mutt] #2711: Will not tag/delete duplicates (~=) when emails

#2711: Will not tag/delete duplicates (~=) when emails are not sorted by thread.
--------------------------------------+-------------------------------------
  Reporter:  schmmd <at> u.washington.edu  |       Owner:  mutt-dev
      Type:  defect                   |      Status:  reopened
  Priority:  minor                    |   Milestone:          
 Component:  mutt                     |     Version:          
Resolution:                           |    Keywords:          
--------------------------------------+-------------------------------------
Changes (by fabrivelas):

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

Comment:

 Replying to [comment:2 rado]:
 > {{{
 > Upgrade to latest 1.5.x version.
 > }}}

 This does not fix the problem for mutt version 1.5.18 (2008-05-17).

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/2711#comment:3>
Mutt <http://www.mutt.org/>
The Mutt mail user agent

[patch] fix a few little buglets in mutt HEAD

I have access to a static analysis tool. And I happen to
be a long time user of mutt. I would like to continue to be a user.
So I ran the tool over HEAD to see what it found. It found a lot. But
here are a few things that I am pretty sure could be fixed with little
impact.

E

-- 
Erik Hovland
erik <at> hovland.org
http://hovland.org/

1. len should be a signed type.

   len stores the return value of functions that return signed values.
   So it should be signed. Changing to ssize_t.

2. i will never be -1

   Because of the organization of the parens at line 1985, i will be
   assigned the evaulation of stat() == -1. Which is either 0 or 1.
   Later on i is checked for -1. So that means that the caller likely
   intended i to be assigned the return value of stat() instead.

3. ap_retry might never be ended if the condition is never executed.

   At least on x86 va_end is a no-op. But on platforms like PowerPC it
   is a requirement that if any va_list is started, it needs to be