headers
Mutt | 1 Jul 23:55

[Mutt] #2928: Read mail while downloading it

#2928: Read mail while downloading it

 Reason :-
 I use lot of emails forwarded to one mail account. So my mail gets clogged
 up.

 RFE description :-
 To be more efficient mutt user, it would be great if mutt could read the
 mail whilst the next one is being downloaded (I use POP3 service) so that
 I can read the mail that's downloaded immediately without waiting (IMHO
 mutt is blocking somwhere down the code, one possible way would be to have
 a seperate thread handle the display whilst the main code are working on
 the fetching part [just a thought. :)])

 Mutt version :-
 I am using Mutt 1.5.16 (2007-06-09) on Ubuntu feisty and Debian etch
 machine.

 Cheers

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/2928>
Permalink | Reply | 1 comment |
headers
Cameron Simpson | 3 Jul 13:06
Picon
Picon
Gravatar

Re: folder browser: use file time + size rather than symlink's

On 26Jun2007 20:43, Rado S <list-rado <at> gmx.de> wrote:
| All you need to know about a link is that it is a link,
| while anything else is more interesting from the destination.

Generally speaking, when do you even care it's a link?
Why not just use stat() instead of lstat() throughout, and avoid
un"co0nst"ing stat objects, etc?
--

-- 
Cameron Simpson <cs <at> zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Saw, n: A trite popular saying, or proverb. So called because it makes its
way into a wooden head.
Ambrose Bierce (1842-1914), U.S. author. The Devil's Dictionary (1881-1906).
Permalink | Reply | 1 comment |
headers
Rado S | 3 Jul 20:07
Picon
Picon

Re: folder browser: use file time + size rather than symlink's

=- Cameron Simpson wrote on Tue  3.Jul'07 at 21:06:18 +1000 -=

> On 26Jun2007 20:43, Rado S <list-rado <at> gmx.de> wrote:
> | All you need to know about a link is that it is a link,
> | while anything else is more interesting from the destination.
> 
> Generally speaking, when do you even care it's a link?
> Why not just use stat() instead of lstat() throughout, and avoid
> un"co0nst"ing stat objects, etc?

Because with "save_empty=no" I don't want to lose links pointing to
empty/ non-existing folders (which may be created by procmail when new
mail arrives), so I wouldn't delete the last msg in a linked folder,
but would in a direct one.

--

-- 
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.
Permalink | Reply | 0 comments |
headers
Christian Ebert | 4 Jul 09:57
X-Face
Picon
Gravatar

Re: mutt freezes when fed high character in header

[ Cc'ing mutt-dev ]

* Breen Mullins on Tuesday, July 03, 2007 at 11:59:16 -0700:
> I had mutt freeze (again) while opening an mbox today. It gets to
> the point where it prints 'sorting mailbox' and hangs.

I know what you're talking about :(

<http://dev.mutt.org/trac/ticket/2560>

> I finally tracked it down to a message containing a From: header in
> which an 8-bit character wasn't properly encoded:
> 
> X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char E6 hex): From:     
>    "Danny Kj\346r..."
> 
> (Nice of amavis to point that out.)
> 
> Remove the message from the mbox and it opens just fine. 
> Here's my mutt -v:
> 
> 
> Mutt 1.5.16 (2007-06-09)
> 
> System: Darwin 7.9.0 (Power Macintosh)
> ncurses: ncurses 5.2.20020209 (compiled with 5.2)
> libiconv: 1.9

A more recent version of iconv might help:
(Continue reading)

Permalink | Reply | 16 comments |
headers
Derek Martin | 4 Jul 14:36
Gravatar

Re: mutt freezes when fed high character in header

On Wed, Jul 04, 2007 at 09:57:42AM +0200, Christian Ebert wrote:
> But I still believe that Mutt should not just *freeze* in case of
> an iconv failure, but give the user some means to isolate the
> message (including removing it from the mailbox) ... 

If it is a bug in the iconv library (which Mutt uses), and  mutt is
freezing up in the iconv code rather than its own, that is
unfortunately technically impossible.

If Mutt were calling iconv as an external program, it would be
technically possible, but it would be a really ugly hack that would
not be worth doing.

--

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.
Permalink | Reply | 14 comments |
headers
Christian Ebert | 4 Jul 15:46
X-Face
Picon
Gravatar

Re: mutt freezes when fed high character in header

* Derek Martin on Wednesday, July 04, 2007 at 08:36:01 -0400:
> On Wed, Jul 04, 2007 at 09:57:42AM +0200, Christian Ebert wrote:
>> But I still believe that Mutt should not just *freeze* in case of
>> an iconv failure, but give the user some means to isolate the
>> message (including removing it from the mailbox) ... 
> 
> If it is a bug in the iconv library (which Mutt uses), and  mutt is
> freezing up in the iconv code rather than its own, that is
> unfortunately technically impossible.

Ok.

I don't know what changed from iconv 9 -> 11, but it might worth
looking into what exactly iconv does in the old version, because
when I ran iconv 9 from the command line on the message in
question, it gives exactly the same output to stderr as iconv 11:

iconv: conversion to iso-8859-i unsupported
iconv: try 'iconv -l' to get the list of supported encodings

So, iconv 9, the program, somehow /can/ handle this w/o freeze.

> If Mutt were calling iconv as an external program, it would be
> technically possible, but it would be a really ugly hack that would
> not be worth doing.

I understand, and -- layman's speak here -- the change in iconv
might've been in the /library/ not the program, but perhaps there
is some way to catch what the library says from Mutt like old
iconv, the program, does.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Derek Martin | 4 Jul 16:21
Gravatar

Re: mutt freezes when fed high character in header

On Wed, Jul 04, 2007 at 03:46:37PM +0200, Christian Ebert wrote:
> I understand, and -- layman's speak here -- the change in iconv
> might've been in the /library/ not the program, but perhaps there
> is some way to catch what the library says from Mutt like old
> iconv, the program, does.

There isn't.  The library becomes part of the program by dynamically
linking the code from the library into Mutt's executable program, but
mutt has no control over what it does...  If the library decides to go
into an endless loop, mutt has no way to determine that, and no way to
do anything about it, because it isn't Mutt's code that's running at
that point -- it's the library's code that is executing.  As I said,
what you're asking is impossible.

An alternative would be to re-code Mutt to run iconv as an external
program, and write some very silly and complex code to see if it's
taking too long to do what it's supposed to do, but this doesn't
really solve the fundamental program: iconv is broken.  You need a new
one.

The problem here isn't Mutt's fault in any way, and the solution is to
update your libiconv to one that's not broken.  That's a solution
that's much easier -- and much smarter -- than trying to write a
framework to monitor system libraries to make sure they behave
reasonably.

--

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
(Continue reading)

Permalink | Reply | 10 comments |
headers
Christian Ebert | 4 Jul 18:00
X-Face
Picon
Gravatar

Re: mutt freezes when fed high character in header

* Derek Martin on Wednesday, July 04, 2007 at 10:21:08 -0400:
> On Wed, Jul 04, 2007 at 03:46:37PM +0200, Christian Ebert wrote:
>> I understand, and -- layman's speak here -- the change in iconv
>> might've been in the /library/ not the program, but perhaps there
>> is some way to catch what the library says from Mutt like old
>> iconv, the program, does.
> 
> There isn't.  The library becomes part of the program by dynamically
> linking the code from the library into Mutt's executable program, but
> mutt has no control over what it does...  If the library decides to go
> into an endless loop,

But iconv, the program, uses the same broken library and doesn't
go into a loop, or detects the loop in the lib, and error-exits
immediately.

> mutt has no way to determine that, and no way to
> do anything about it, because it isn't Mutt's code that's running at
> that point -- it's the library's code that is executing.  As I said,
> what you're asking is impossible.

Because iconv, the program, has access to some return codes from
the broken lib that Mutt does not have access to?

> An alternative would be to re-code Mutt to run iconv as an external
> program, and write some very silly and complex code to see if it's
> taking too long to do what it's supposed to do, but this doesn't
> really solve the fundamental program: iconv is broken.  You need a new
> one.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Breen Mullins | 4 Jul 19:03
Picon

Re: mutt freezes when fed high character in header

* Christian Ebert <blacktrash <at> gmx.net> [2007-07-04 18:00 +0200]:

>
>Unfortunately there's nothing that tells an unexperienced user
>that it is iconv's fault. See the message that started this
>thread. amavis told him about an undeclared header. And some
>people don't run amavis, or are not as obsessed as I am about
>Mutt, and will just say: oh, Mutt freezes, without telling me
>anything, I'll just use that other mailer which doesn't freeze.

I agree - you have to be determined in a case like this one. 
It took a bit of work to isolate the message that was causing the hang.
Not something you can expect most users to bother with. 

Thanks for the hints on charset-hooks - I tried them but it didn't help.
For now, since I'm only seeing this problem with a single user on a
single mailing list, I've written a sed one-liner to correct the From:
line in his messages, and I'll drop it into cron until I have the chance
to try a new libiconv.

Breen
--

-- 
Breen Mullins
Menlo Park, California
Permalink | Reply | 2 comments |
headers
Derek Martin | 4 Jul 21:08
Gravatar

Re: mutt freezes when fed high character in header

On Wed, Jul 04, 2007 at 06:00:14PM +0200, Christian Ebert wrote:
> * Derek Martin on Wednesday, July 04, 2007 at 10:21:08 -0400:
> > On Wed, Jul 04, 2007 at 03:46:37PM +0200, Christian Ebert wrote:
> >> I understand, and -- layman's speak here -- the change in iconv
> >> might've been in the /library/ not the program, but perhaps there
> >> is some way to catch what the library says from Mutt like old
> >> iconv, the program, does.
> > 
> > There isn't.  The library becomes part of the program by dynamically
> > linking the code from the library into Mutt's executable program, but
> > mutt has no control over what it does...  If the library decides to go
> > into an endless loop,
> 
> But iconv, the program, uses the same broken library and doesn't
> go into a loop, or detects the loop in the lib, and error-exits
> immediately.

But this is meaningless.  The iconv program exists for one purpose
only: to convert data between two different encodings.  Mutt is a much
more complicated program, and it may be that the iconv library is
broken in such a way that when mutt calls its functions, it overwrites
other variables in mutt that cause it to return from a function call
to an address that has unknown code in it, which just happens to be an
endless loop, or who knows what...  There are numerous possibilities.
It is very possible that the way the iconv program's data structures
are arranged, being generally fewer and more simplistic,  do not
overwrite any return addresses on the stack, or whatever.  It doesn't
mean there's no bug; it just means the programmer got lucky.  Sort of.

If you've ever taken a computer science class at a school where there
(Continue reading)

Permalink | Reply | 2 comments |

Gmane