Archive of RubyForge sup-talk mailing list
 help / color / mirror / Atom feed
From: wmorgan-sup@masanjin.net (William Morgan)
Subject: [sup-talk] Sup annoyances
Date: Mon, 08 Jun 2009 11:00:23 -0700	[thread overview]
Message-ID: <1244481844-sup-9094@entry> (raw)
In-Reply-To: <1244270435-sup-9288@javelin>

Hi Edward,

I think these are by and large legitimate gripes and I'd be delighted to
have someone motivated to fix them!

Reformatted excerpts from Edward Z. Yang's message of 2009-06-05:
> 1. Threads should be lazy-loaded (possibly in the background), with
>    visible messages first.

FWIW, this is particularly egregious in a direct IMAP connection, and
those of us who have switched to Maildir or who use mbox aren't
punished. But it would be very cool to have this.

> If a conversation got a new message, Sup should only take its time to
> load that message, and not the frickin' 24 other messages that were
> also incidentally there.  I suspect this will require some pretty
> major refactoring.

It might not be too bad. Turn off the call to m.load_from_source! on
line 106 of thread-index-mode.rb, add a Queue to ThreadViewMode
containing messages to call #load_from_source! on, don't call m.chunks
in ThreadViewMode#regen_text unless the message has been loaded, start a
thread that pops messages from the queue, calls #load_from_source!  on
them, and then calls regen_text when an open message has been loaded...
and you're 90% of the way there.

> 2. Auto-completion sucks and should be improved.  I should be able
> to press "c", type two letters, and then mash tab. If auto-completion
> actually works, then I'll blame it on dismal contacts.txt support

The auto-completion is awesome. Adding a recipient to the contacts list is
a good idea.

> 3. Polling and loading of threads should started, asynchronously, at
>    the same time.

> Loading of threads should not hose my CPU.

Agreed. Please fix.

> Loading of threads should do smart things, instead of doing an O(n)
> time warp.

It's definitely worse than O(n). Loading threads could be sped up
dramatically by storing the thread structure somewhere (either cached or
just for every thread), since Sup does a lot of extra work rethreading
everything every time you start it up. FWIW I'm doing this the right way
in Sup 2.0.

> 4. Sup should prompt me whether or not I want to Reply All or Reply on
>    appropriate cases, like pine.

There have been a couple similar requests like this recently, though
it's not clear if everyone has known about the ability to change the
reply mode and about the reply-to hook.  Since hitting 'r' defaults to
replying to the sender alone (except for mailing list messages), I'd be
ok with adding a Mutt-style reply-to-all key that starts up reply-mode
with the 'reply to all' mode active.
-- 
William <wmorgan-sup at masanjin.net>


  parent reply	other threads:[~2009-06-08 18:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-06  6:54 Edward Z. Yang
2009-06-06  6:56 ` Edward Z. Yang
     [not found]   ` <1244308338-sup-4735@cabinet>
2009-06-06 18:17     ` Edward Z. Yang
2009-06-08 18:00 ` William Morgan [this message]
2009-06-08 23:14   ` Edward Z. Yang
2009-06-08 23:46     ` William Morgan
2009-06-09  2:13       ` Edward Z. Yang
2009-06-09  2:23         ` Edward Z. Yang
2009-06-09  2:35           ` Edward Z. Yang
2009-06-09 17:40             ` William Morgan
2009-06-11  3:18               ` Edward Z. Yang
2009-06-09 17:48           ` William Morgan
2009-06-11  3:19             ` Edward Z. Yang
2009-06-09 17:32         ` William Morgan
2009-06-09  2:38   ` Edward Z. Yang
2009-06-09 17:45     ` William Morgan
2009-06-09  3:00   ` Edward Z. Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1244481844-sup-9094@entry \
    --to=wmorgan-sup@masanjin.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox