From: wmorgan-sup@masanjin.net (William Morgan)
Subject: [sup-talk] Sup annoyances
Date: Mon, 08 Jun 2009 16:46:39 -0700 [thread overview]
Message-ID: <1244503985-sup-8587@entry> (raw)
In-Reply-To: <1244502545-sup-9840@javelin>
Reformatted excerpts from Edward Z. Yang's message of 2009-06-08:
> * How do I tell if a message is shown on the screen or not?
If m is the message, @layout[m].state will be :open, :detailed or
:closed. If it's not :closed, it is visible.
> * The implementation you describe still downloads the messages
> sequentially, which are usually not the messages we want to download
> first.
Only if you add them to the Queue sequentially. You could instead add
the ones with :unread or :starred labels first. And ideally if you
expand a collapsed unloaded message, that should be pushed to the head
of the Queue.
> I don't mind sup blocking on downloading a message, as long
> as it's one or two, which means I don't strictly need threads: I
> just need some API for, when a new message is opened, downloading it
> and then rendering it. What do you think of this?
So you would only preload the new/starred ones, and load the others only
when they're expanded? I think that simply removing that call in
thread-index-mode.rb would accomplish this.
I'd rather have the threaded version, since loading a thread of 100 new
messages sucks, but either way would be an improvement.
> > The auto-completion is awesome. Adding a recipient to the contacts
> > list is a good idea.
>
> Does contacts.rb apply to people.txt or contacts.txt?
contacts.txt. people.txt is deprecated. In fact I'm surprised you have
one.
> > 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.
>
> Can you backport it easily to Sup 1.0?
No, it's completely different. It would be easier to rewrite from
scratch for the existing Sup.
> The explicit prompt makes me think about who I want to send the
> message to. I frequently forget to move the little knob with Sup's
> behavior.
When do you want it to prompt you? Is this a yes/no prompt?
--
William <wmorgan-sup at masanjin.net>
next prev parent reply other threads:[~2009-06-08 23:46 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
2009-06-08 23:14 ` Edward Z. Yang
2009-06-08 23:46 ` William Morgan [this message]
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=1244503985-sup-8587@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