help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Moving from Thunderbird to Emacs for mail and calendar


From: Richard Riley
Subject: Re: Moving from Thunderbird to Emacs for mail and calendar
Date: Tue, 13 Oct 2009 15:58:39 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Jeff Clough <jeff@chaosphere.com> writes:

> From: Andreas Politz <politza@fh-trier.de>
> Date: Mon, 12 Oct 2009 19:12:36 +0200
>
>> Francis Moreau <francis.moro@gmail.com> writes:
>> 
>>> On Oct 12, 2:56 pm, Richard Riley <rileyrg...@gmail.com> wrote:
>>>> I think it is worth it because of the benefits of it being cradled by
>>>> mother Emacs : having all my normal text tools for translation,
>>>> spelling, searching etc in my gnus buffers is just too cool. It all
>>>> works together too well. I do remember being frustrated earlier because
>>>> of the incomprehensible manual and the raft of options (and being newish
>>>> to emacs). But it was worth it.
>>>
>>> But you probably get the same benefits with Mew...
>
> Every Emacs feature I've wanted and tried to use works very well with
> Mew, or at least no worse than to be expected under Windows.
>
>> So what is your experience with Mew concerning ease of setup, huge mail
>> boxes, message threading and general performance ?
>
> Setting up Mew was several orders of magnitude easier than setting up
> Gnus, which I was never able to successfully do.  A good part of this

What part were you unable to do? Did you have it reading mail at all?

> is that the Mew folks know something about documentation.  Another
> part of this is that they seem to have spent less time creating a
> one-size-fits-all "messaging" solution and concentrated on making a
> good MUA.  There's news stuff in Mew, from what I've read, but it
> doesn't seem to have affected how *mail* is treated.

It would be good to see something about how you expect mail handling to
work which is not supported by Gnus.

>
> I'll skip down to message threading because that's the easy one: I
> don't use message threading in email and never have in any MUA.

You don't have to in gnus either.

>
> Mew handles huge mailboxes both incredibly well and hideously.  If you

I have large mailboxes in Gnus. It handles them fine.

> use the default configuration, a mailbox is nothing more than a
> directory on the disk with each message sitting in it's own text file
> (this appears to be your standard ASCII affair with anything else
> MIME'd up, but I don't receive messages in multi-byte formats so I
> don't know for sure how those would be handled).

Well, that is nice but how do you relate it to Gnus which supports
multiple backends?

>
> When you visit a folder, Mew creates a summary file in the appropriate
> directory and displays a list of the messages in that folder to the
> user.  If the summary file for the folder is current, visiting that
> folder, even for the first time that Emacs session, takes no
> observable time for a folder with about 1,000 messages in it.  I
> assume the "right" answer here is that it takes as long as is required
> for Mew to open the summary file and dump it to the screen.  The
> summary file is text, with one line per message, although these lines
> do need to be parsed to display the information to the user the way
> the user has Mew configured.
>
> Where Mew fails hard is in when it choses to generate those summary
> files.  If you are merrily filing messages into a folder from your
> Inbox or some other location, they don't ever show up in that summary
> file until you visit that folder in Mew.  Then Mew sees the summary
> data is out of date, throws it away and rebuilds the entire file
> again.  Even for 1,000 messages this means that it will take a while.

Ah, so it does pause!

>
> Now granted, Mew's one saving grace here is that it isn't catatonic
> while this happens.  You can still use Mew, Emacs as a whole *and* any
> messages that have been summarized in that folder already.  The issue
> is that you don't have access to all of the messages until the summary
> file has been rebuilt.  And in the default configuration, with one
> message per file, that's a *lot* of expensive disk I/O.

Well, yes if you access all your messages. I have about 20 news groups
subscribed to and about 12 different email folders handling mail for 4
email addresses using fancy splitting. It really is pretty
instant. Admittedly I have my own dovecot server too which uses
getmail to fetch from imap servers on the net periodically.

>
> It's on my perpetual to-do list to fiddle around with idle timers and
> see if I can't make Mew do this re-summarizing lazily in the
> background so I can dodge this issue, but I'm not holding my breath
> that I'll ever get around to it.
>
> As for overall performance, I'm very happy with it.  It's leaps and
> bounds faster than Thunderbird and I can work much more efficiently
> having access to the rest of Emacs in the same environment.
>
> It's certainly not a perfect piece of software, but that I could get
> it to work *at all* is a pretty good feature and makes it immediately
> better than Gnus for me.
>
> Jeff

It's a shame you could not get Gnus to work. There must be something
subtle you missed. But since you could not get it to work, it's wrong to
suggest Mews handling is better in any way. I couldn't really see
anything in what you said that suggests, in any shape or form, that Mews
is a better emacs MUA than Gnus. But if Mews works for you thats great.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]