understanding code.c(_mutt_copy_message) ->v?size calculation

Moinsen,

while searching for a solution to make %l and %L in status_format
match for IMAP folders when you use '..' to limit to 'ALL' entries
(they differ for IMAP unlike for local mbox folders), I noticed
these occurances for "->vsize":

------ QUOTE BEGIN ------
copy.c:
	Context->size	-= body->length - new_length;
	Context->vsize	-= body->length - new_length;
curs_main.c:
	ctx->vsize	+=THIS_BODY->length	+ THIS_BODY->offset	- THIS_BODY->hdr_offset;
mx.c:
	ctx->vsize	+=this_body->length	+ this_body->offset	- this_body->hdr_offset;
pattern.c:
	Context->vsize	+=THIS_BODY->length	+ THIS_BODY->offset	- THIS_BODY->hdr_offset;
thread.c:
	ctx->vsize	+=cur->content->length	+ cur->content->offset	- cur->content->hdr_offset;
------- QUOTE END -------

My original solution was to drop in imap/message.c the subtraction
of the fetched headers' size by this:

------ QUOTE BEGIN ------
	h->content_length -= bytes;
------- QUOTE END -------

This means: count only the body, without the fetched headers
("bytes"). This is plain wrong, since as you can see above, %L

Re: [Mutt] #2844: mutt 1.4.2.2 doesn't link under Solaris 8/Sparc

#2844: mutt 1.4.2.2 doesn't link under Solaris 8/Sparc

Changes (by brendan):

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

Comment:

 Rado reports 1.5.15 builds on Solaris.

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/2844#comment:5>

Re: [Mutt] #2515: Sorting by from or to in index is sometimes

#2515: Sorting by from or to in index is sometimes incorrect

Changes (by ptaff):

  * version:  1.5.12 => 1.5.15

Comment:

 Bug confirmed, I've been experiencing for quite a while now.

 Misfeature still present in 1.5.15; patch however does work for me.

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/2515#comment:1>

mutt: new changeset

New changeset in mutt:

http://dev.mutt.org/hg/mutt/rev/1ed1cbc7bad4
changeset:   5146:1ed1cbc7bad4
branch:      HEAD
tag:         tip
user:        Brendan Cully <brendan <at> kublai.com>
date:        Tue May 01 10:41:50 2007 -0700
summary:     Make IDN depend on iconv support

--

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

Re: ChangeLog file

On Monday, 30 April 2007 at 16:15, Vincent Lefevre wrote:
> On 2007-03-06 11:46:12 -0800, Brendan Cully wrote:
> > On Tuesday, 06 March 2007 at 20:42, Vincent Lefevre wrote:
> > > The ChangeLog file is not updated in the hg repository.
> > > Is there a reason?
> > 
> > I wrote a quick hack to update the changelog with the commit, but
> > realised it was subtly broken. I haven't had time to work on a proper
> > fix yet. It's easy to make a separate changelog commit, but I don't
> > much like them. It's also pretty easy to make a cron job for changelog
> > updates, which I might do. But I'm hoping for something a little
> > smarter.
> 
> Any news? It's still out-of-date.

hg-commit is usually at least a commit behind. It can be more if I
import the patches instead of committing them myself.

> In fact, the main problem is that the date doesn't correspond to
> the latest change date. When building Mutt, if a .hg directory is
> available, couldn't the date be taken from it?

It could, yes.

Re: change_folder_next patch

> Again, all comments gratefully received.

I've pushed this to main, thanks.

mutt: new changeset

New changeset in mutt:

http://dev.mutt.org/hg/mutt/rev/f6861b85f22b
changeset:   5147:f6861b85f22b
branch:      HEAD
tag:         tip
user:        N.J. Mann <njm <at> njm.f2s.com>
date:        Wed May 02 10:50:07 2007 -0700
summary:     Add next-folder command

--

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

Re: ChangeLog file

On 2007-05-02 10:39:10 -0700, Brendan Cully wrote:
> > In fact, the main problem is that the date doesn't correspond to
> > the latest change date. When building Mutt, if a .hg directory is
> > available, couldn't the date be taken from it?
> 
> It could, yes.

How about something like that (see attached patch)? Not sure if this
is the correct way, but reldate.h needs to be rebuilt every time as
mtime-based dependencies are not sufficient.

--

-- 
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)

diff -r f6861b85f22b Makefile.am
--- a/Makefile.am	Wed May 02 10:50:07 2007 -0700
+++ b/Makefile.am	Thu May 03 14:11:04 2007 +0200
 <at>  <at>  -121,8 +121,10  <at>  <at>  keymap_defs.h: $(OPS) $(srcdir)/gen_defs
 		$(srcdir)/OPS.MIX $(srcdir)/OPS.CRYPT $(srcdir)/OPS.SMIME \
 			> $(srcdir)/keymap_alldefs.h

-reldate.h: $(srcdir)/ChangeLog
-	echo 'const char *ReleaseDate = "'`head -n 1 $(srcdir)/ChangeLog | LC_ALL=C cut -d ' ' -f 1`'";' >
reldate.h.tmp; \
+reldate.h: reldate
+
+reldate:

Re: change_folder_next patch

Hello Nick,

 On Monday, April 30, 2007 at 15:57:20 +0100, N.J. Mann wrote:

> I've left it bound to ',' for now, but...

    There is another argument against binding comma: Since ages, by
default comma is not bound. This fact is well known by users, and they
frequently use the comma for their custom binds. Either comma alone, or
as prefix of multi-keys macros. As examples the ", <at> r13on" and ", <at> r13off"
of the ROT13 decoder macro set adviced on the Mutt wiki. And many more
such. This would not cooperate smoothly with a default bound comma.

    In my humble, <next-folder> is a "risky" function (deleted mails may
get purged): It should not be bound by default to any single key, but to
a key combination less prone to false moves. Humm... <Esc>m perhaps (can
be typed <Alt>m on some terminals), with "m" as mailbox.

    BTW, in Mutt's speak this function doesn't jump to the next
_folder_, but to the next _mailbox_ (a folder declared in "mailboxes"
list) with new mail. Nuance. Shouldn't it better read: <next-mailbox>
"open next mailbox with new mail"?

Bye!	Alain.
--

-- 
PuTTY 0.60 is released.

Re: change_folder_next patch

On Thursday,  3 May, 2007 at 12:16:39 +0200, Alain Bench wrote:
>  On Monday, April 30, 2007 at 15:57:20 +0100, N.J. Mann wrote:
> 
> > I've left it bound to ',' for now, but...
> 
>     There is another argument against binding comma: Since ages, by
> default comma is not bound. This fact is well known by users, and they
> frequently use the comma for their custom binds.

I have no problem with it being unbound by default and have said such in
this thread.  For me having it bound to a single key-sequence is a must
have and comma was unbound.

>     In my humble, <next-folder> is a "risky" function (deleted mails may
> get purged):

But you get the purge prompt just like you do with <change-folder>.  If
you have set 'delete' to 'yes' then all bets are off.

> It should not be bound by default to any single key, but to
> a key combination less prone to false moves. Humm... <Esc>m perhaps (can
> be typed <Alt>m on some terminals), with "m" as mailbox.
> 
> 
>     BTW, in Mutt's speak this function doesn't jump to the next
> _folder_, but to the next _mailbox_ (a folder declared in "mailboxes"
> list) with new mail. Nuance. Shouldn't it better read: <next-mailbox>
> "open next mailbox with new mail"?

But, <change-folder> is called change-FOLDER and <next-folder> is a