headers
Thomas Roessler | 1 Apr 2005 05:00

[2005-04-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.

2005-03-31 04:55:09  Thomas Glanzmann  <sithglan <at> stud.uni-erlangen.de>
(brendan)

	* mh.c: Another hcache cygwin portability fix.
Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 2 Apr 2005 04:33
Picon
Favicon

Re: IMAP status flags lost when refiling

On Wed, Mar 30, 2005 at 03:28:20PM +0100, Dave Ewart wrote:
> On Tuesday, 29.03.2005 at 15:21 -0500, Kyle Wheeler wrote:
> 
> > I've looked through the archives, and I'm not sure if this bug has been 
> > brought up since the bug database was lost... Debian 163616 
> > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=163616) - basically, 
> > when messages are moved from one IMAP folder to another IMAP folder (on 
> > the same server), the flags that have not been saved to the server are 
> > lost.
> 
> Oh, yes please, a fix to that would be very useful.  Particularly,
> having messages which have been read in one folder appear as 'New' when
> saved to another folder is very annoying.

Amen.  I've been running into this for a while now.

--

-- 
Daniel Jacobowitz
CodeSourcery, LLC
Permalink | Reply | 7 comments |
headers
Tamotsu Takahashi | 2 Apr 2005 06:20
Picon

Re: IMAP status flags lost when refiling

On Fri, Apr 01, 2005 at 09:33:51PM -0500, Daniel Jacobowitz wrote:
> On Wed, Mar 30, 2005 at 03:28:20PM +0100, Dave Ewart wrote:
> > On Tuesday, 29.03.2005 at 15:21 -0500, Kyle Wheeler wrote:
> > 
> > > I've looked through the archives, and I'm not sure if this bug has been 
> > > brought up since the bug database was lost... Debian 163616 
> > > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=163616) - basically, 
> > > when messages are moved from one IMAP folder to another IMAP folder (on 
> > > the same server), the flags that have not been saved to the server are 
> > > lost.
> > 
> > Oh, yes please, a fix to that would be very useful.  Particularly,
> > having messages which have been read in one folder appear as 'New' when
> > saved to another folder is very annoying.
> 
> Amen.  I've been running into this for a while now.

I guess that the problem (not a bug at all) is caused by
server-side copying. Maybe you can safely remove these lines
from commands.c (not imap/command.c):

#ifdef USE_IMAP
  if (Context->magic == M_IMAP && 
      !(decode || decrypt) && mx_is_imap (buf))
  {
    switch (imap_copy_messages (Context, h, buf, delete))
    {
      /* success */
      case 0: mutt_clear_error (); return 0;
      /* non-fatal error: fall through to fetch/append */
(Continue reading)

Permalink | Reply | 6 comments |
headers
Brendan Cully | 2 Apr 2005 06:24
Gravatar

Re: IMAP status flags lost when refiling

On Saturday, 02 April 2005 at 13:20, Tamotsu Takahashi wrote:
> On Fri, Apr 01, 2005 at 09:33:51PM -0500, Daniel Jacobowitz wrote:
> > On Wed, Mar 30, 2005 at 03:28:20PM +0100, Dave Ewart wrote:
> > > On Tuesday, 29.03.2005 at 15:21 -0500, Kyle Wheeler wrote:
> > > 
> > > > I've looked through the archives, and I'm not sure if this bug has been 
> > > > brought up since the bug database was lost... Debian 163616 
> > > > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=163616) - basically, 
> > > > when messages are moved from one IMAP folder to another IMAP folder (on 
> > > > the same server), the flags that have not been saved to the server are 
> > > > lost.
> > > 
> > > Oh, yes please, a fix to that would be very useful.  Particularly,
> > > having messages which have been read in one folder appear as 'New' when
> > > saved to another folder is very annoying.
> > 
> > Amen.  I've been running into this for a while now.
> 
> I guess that the problem (not a bug at all) is caused by
> server-side copying. Maybe you can safely remove these lines
> from commands.c (not imap/command.c):

I think a nicer solution is to create an option to set flags on the
server as soon as they've been changed in mutt. It might be slightly
slower, but probably not noticeable unless flags are set en masse
with a tagged command. I believe Pine goes this route.

I don't have time to write that patch myself right now due to the
end-of-term crunch.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Kyle Wheeler | 2 Apr 2005 09:06

Re: IMAP status flags lost when refiling

On Friday, April  1 at 08:24 PM, quoth Brendan Cully:
> On Saturday, 02 April 2005 at 13:20, Tamotsu Takahashi wrote:
> > On Fri, Apr 01, 2005 at 09:33:51PM -0500, Daniel Jacobowitz wrote:
> > > On Wed, Mar 30, 2005 at 03:28:20PM +0100, Dave Ewart wrote:
> > > > On Tuesday, 29.03.2005 at 15:21 -0500, Kyle Wheeler wrote:
> > > > 
> > > > > I've looked through the archives, and I'm not sure if this bug has been 
> > > > > brought up since the bug database was lost... Debian 163616 
> > > > > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=163616) - basically, 
> > > > > when messages are moved from one IMAP folder to another IMAP folder (on 
> > > > > the same server), the flags that have not been saved to the server are 
> > > > > lost.
> > > > 
> > > > Oh, yes please, a fix to that would be very useful.  Particularly,
> > > > having messages which have been read in one folder appear as 'New' when
> > > > saved to another folder is very annoying.
> > > 
> > > Amen.  I've been running into this for a while now.
> > 
> > I guess that the problem (not a bug at all) is caused by
> > server-side copying. Maybe you can safely remove these lines
> > from commands.c (not imap/command.c):
> 
> I think a nicer solution is to create an option to set flags on the
> server as soon as they've been changed in mutt. It might be slightly
> slower, but probably not noticeable unless flags are set en masse
> with a tagged command. I believe Pine goes this route.

Might it instead be possible to set the flags on the message after it is 
copied? That way all the current optimizations are left in place, the
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alain Bench | 2 Apr 2005 10:32
Picon
Favicon

Re: For 1.5.10: status of commands (Re: For 1.5.10: variable dump

 On Tuesday, March 29, 2005 at 11:44:11 AM +0900, Tamotsu Takahashi wrote:

> New version:
> http://www.momonga-linux.org/~tamo/patch-1.5.9.tamo.comval.5
> Fixed.
> I won't implement
> improved.
> Fixed.
> Reverted.

    Good work: Much thanks Tamo-san! It seems good to me, is of great
value for the user, and was on the wishlist for ages. Go.

Bye!	Alain.
--

-- 
When you want to reply to a mailing list, please avoid doing so with
Infomaniak Webmail. This lacks necessary references and breaks threads.
Permalink | Reply | 0 comments |
headers
Alain Bench | 2 Apr 2005 14:13
Picon
Favicon

Re: For 1.5.9: soft fill [patch-1.5.8.dgc.softfill.3]

Hi Dave!

 On Sunday, March 6, 2005 at 7:11:35 PM -0600, David Champion wrote:

> The softfill patch provides a "%*X" expando, similar to the existing
> "%>X" and %|X". Like "%>X", it inserts padding to push a line of text
> all the way to the right. Unlike "%>X", it gives fill precedence to
> the right-hand side, not to the left.

    Clear, simple, and usefull. Thanks! I'm happy to have retriggered
interest about it! About usefullness, see on mutt-users msgids
<20050222162513.GA25614 <at> oreka.com> and especially
<20050302220609.GA14092 <at> oreka.com> (note they talk about old v2 %=XY
syntax).

> Now the entire LHS is held in reserve. It's debatable whether this is
> better, but it's definitely simpler.

    I agree, but let's pose the debate: Old v2 %=XY gives right-hand
priority over *one* given Y left field, while new v3 %*X gives right
priority over everything at left. Important left-hand infos may be
hidden on narrow screen, which imposes carefull choice of fields and
safe right width limitations. Compared v2 and v3 behaviours have each
pros and cons. Ok: Simpler v3 wins.

> the patch also modifies the basic expando modifier code

    BTW how can you truncate beginning of a fixed width field? Like a
long /home/a/alain/long/path/filename.ext, displayed on 20 chars as
"ng/path/filename.ext"?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alain Bench | 2 Apr 2005 14:54
Picon
Favicon

Re: [PATCH] indexcolor patch, next iteration

Hello Christian,

 On Sunday, March 6, 2005 at 4:43:01 PM +0100, Christian Aichinger wrote:

> another version of my indexcolor patch

    Version v3 breaks aligment of "%>X" expandos. Fields on the right
are not stuck to the right border, but randomly before. With
index_format="%4C %Z %[%_d %b %y %_H:%M] %?M?=%-4M&%5c? %s%>-[%-17.17F]"
on a 94 columns terminal I get only max 74 used columns, with some
misaligned names:

|  162  s   7 jui 98 13:33  1,2K send-hook question--[Ralf Hildebrandt ]
|  163      9 jui 98  1:14  0,7K `->---------------------[Michael R. Elkins]
|  164  s   9 jui 98 12:36  1,4K   `->-------------------[Ralf Hildebrandt ]
|  165  s   9 jui 98 15:05  1,0K     `->-----------------[Stefan `Sec` Zehl]
|  166      9 jui 98 15:42  0,6K       `->---------------[Michael D. Ivey  ]

Bye!	Alain.
--

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Permalink | Reply | 1 comment |
headers
Alain Bench | 2 Apr 2005 15:04
Picon
Favicon

Re: For 1.5.9: menu_move_off (was: Change in behavior <current-middle>)

 On Thursday, March 31, 2005 at 1:40:21 PM +0900, Tamotsu Takahashi wrote:

> On Wed, Mar 30, 2005 at 02:56:39PM +0200, Alain Bench wrote:
>> 4-37 cursor on *27*, then <previous-page>: You see 1-34 cursor on 27.
> Older mutt didn't?

    Don't you like: (A) The final page jump also puts cursor on 1, and
further <previous-page> errors "You are on the first page."?

    Against: (B) The final page jump pushes cursor as usual on 27,
another <previous-page> doesn't jump anymore but sets cursor on 1, and
further <previous-page> errors "You are on the first page."?

    Version (A) seems to me so natural that I considered (B) faulty, and
forgot to verify, but you're right: Older stock Mutts did (B). Stock
1.5.9 seems to hesitate between (A) and (B) depending on settings and
exact conditions (bad). I vote (A).

 On Thursday, March 31, 2005 at 11:43:24 PM +0900, Tamotsu Takahashi wrote:

    [cursor altitude]
> And I have misread you. Sorry. Please test v5 instead of v4.

    You didn't misread me at all, and even guessed the request hidden
between the lines! :-) You made v4 a perfect example of "fixed", and v5
of "pushed". We can now really compare and choose! I vote v5.

> Surprisingly, v5 decreases the amount of the code.

    I vote v5 a second time.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alain Bench | 2 Apr 2005 10:14
Picon
Favicon

Re: problems compiling mutt-cvs on cygwin

Hello Olaf,

 On Wednesday, March 30, 2005 at 2:37:57 PM +0100, Olaf Föllinger wrote:

> I'm on cygwin

    BTW don't you need --enable-locales-fix and --without-wc-funcs on
Cygwin anymore? There was no working locale last time I checked Cygwin.

Bye!	Alain.
--

-- 
Microsoft Outlook Express users concerned about readability: For much
better viewing quotes in your messages, check the little freeware
program OE-QuoteFix by Dominik Jain on <URL:http://flash.to/oblivion/>.
It'll change your life. :-) Now exists also for Outlook.
Permalink | Reply | 0 comments |

Gmane