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

Re: Back to Gnus?



At Tue, 05 Apr 2011 20:34:50 -0400,
Vitaly Mayatskikh wrote:
> 
> At Tue, 05 Apr 2011 19:35:49 -0400, Dave Abrahams wrote:
> 
> > > (setq mime-view-buttons-visible nil)
> > 
> > And how does that help when I need to see MIME parts?
> 
> Ok, I got your point. That can be worked out too.

Sure, I can fix anything if I'm willing to troll through the sources
for long enough, but I'm running out of time.

> > Right, almost works perfectly (still leaves the background color on
> > the end of the line I'm editing) ... provided I can afford to
> > re-highlight the entire buffer after every keypress.  If this is what
> > you're expected to do to make it work, why isn't that built in?
> 
> Because I don't like to re-highlight buffer after every key press and
> I'm too lazy to fix it in a real way.

An inefficient fix in the official WL is better than no fix.  You can
always optimize later if you find it to be a problem.

> > > That can be solved easily, if somebody really wants to solve it.
> > 
> > You're saying all of those related problems can be solved easily?
> 
> Easy enough, if you want to fix them. WL is very hackable piece of
> software.

As I have mentioned, hackability is in the eye of the hacker and
several things severely limit WL's hackability for me.

> > > You can't solve the fact that Gnus is only good for NNTP :) So, its
> > > IMAP sucks, 
> > 
> > My understanding is that in Emacs24 its IMAP is pretty darned good.
> > I'm going to try it and see.
> 
> Good to know.

Or at least, fast.

> > > offline support sucks, 
> > 
> > I didn't find offline support to suck any worse than it does for WL.
> > What's the problem?
> 
> It simply didn't work 2.5 years ago, not at all.

OK

> > As for hackability, WL uses a non-standard undocumented OOP system
> 
> This is elisp, it does not have any standard OO-system. 

There are two answers to that:

1. EIEIO ships with emacs; you can't get any more "standard elisp"
   than that!

2. If it were true that there was no standard OO system for elisp,
   that would only make it more important that the one being used is
   *documented*.

> > and has almost no internal comments and no docstrings.  Working on
> > WL has been no picnic for me.  As for functionality, WL is painfully
> > slow for very large groups, of which I have quite a few (both mail
> > and NNTP).
> 
> I personally found WL is capable to handle large folders on slow (bad
> gprs) link better than other clients. Those days I was subscribed to
> linux kernel mailing list and that gave me ~800 mails a day, which I
> was lazy to read or even to expunge, so my folder size was of 150k
> mails :)

That's not large.  That doesn't begin to approach the size of the
groups I need to read, e.g. gmane.comp.lib.boost.devel or even my own
mail archive, which is a lot smaller.

> > That's exactly how I felt after arriving at WL from Gnus.  But
> > combined with rumored nnimap improvements and the problem of hanging
> > on dropped connections, the other inconveniences are starting to tip
> > the scales back for me.  This is a somewhat desperate plea to help me
> > avoid investing in Gnus.
> 
> I was reluctant to switch from Gnus either, and invested far more
> efforts to bring IMAP support in Gnus at better scale. The reaction of
> crowd at gnus ml was: "Yes, it good to have working IMAP, but it's
> hard to improve it and not to break tons of legacy code". 

You rewrote NNIMAP and they rejected it because it might have broken
some legacy tweaks people wrote?  Oh, that's just criminal. :-(

> May be people have found another, less bloody way to fix their IMAP,
> or they invested even more time to fix every bit.

I don't know.  I'll look into it.

Hmm, the diffs are enormous.  Maybe you were just ahead of your time.

> And I still think the reader in Gnus is better than what WL provides,
> but I want mail client to support IMAP, what Gnus was obviously
> missing in past.

I'll let you know how Gnus works out for me.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com