Re: Features like Sup
On 06Jul2009 08:33, Noah Slater <nslater@xxxxxxxxxxxx> wrote:
| On Mon, Jul 06, 2009 at 05:05:34PM +1000, Cameron Simpson wrote:
| > | but Sup interests me for two reasons:
| > | * Thread centred message listing,
| >
| > How different from mutt's threads?
|
| It's probably best to just check out the Sup documentation:
|
| http://sup.rubyforge.org/
|
| Those screenshots that might help illustrate some of the differences.
They feel like mutt or pine to me.
I can do the index view with collapsed mutt threads already.
My thread setup looks like this:
set duplicate_threads=yes
set collapse_unread=yes
set uncollapse_jump=yes
set digest_collapse=no
folder-hook . set sort=reverse-threads
folder-hook . 'push ":set collapse_unread=no<enter><collapse-all>:set
collapse_unread=yes<enter>"'
folder-hook . 'macro index \CD
"<untag-pattern>.<enter><tag-thread><tag-prefix><copy-message>+ham<enter><tag-prefix><save-message><enter><collapse-thread><next-undeleted>"
"archive thread"
macro index \CR "<read-thread><collapse-thread><next-unread>" "mark the
current thread as read"
macro pager \CD "<exit>\CD<display-message>" "archive thread"
macro index '{' "<collapse-thread>"
macro index,pager L "<limit>~(" "limit threads"
I use automatic X-Label tags (applied by procmail at delivery time)
to get your "+ruby-talk" marker equivalent.
Example, from my "sh" folder (high value unix/shell related lists):
07Jul2009 02:42 gudermez N ┌─>Re: Simple replacement SedUsers 1.2K
07Jul2009 01:40 gudermez N │ ┌─> SedUsers 1.7K
06Jul2009 21:55 Duke Normandin N ┴─>Re: Simple replacement SedUsers 1.5K
06Jul2009 22:01 mahesh shivhare N Filter syslog messages. RHYahoo 1.1K
06Jul2009 15:15 lsenters41102 N Re: new user. RHYahoo 1.4K
04Jul2009 00:06 Jins Thomas - (5) Regarding read in shell script UNIXShe
01Jul2009 12:45 Jack Coates - (2) Re: Perl multi-line regex ShellScripti
01Jul2009 18:11 Todd A. Jacobs - (2) Using /dev/stderr vs. >&2 ShellScripti
28Jun2009 21:35 Persson - (6) Re: Error SED in Shell Script SedUsers
11Jun2009 13:05 Piers Rowan - (4) LDAP inetOrgPerson LinuxSA 1.0K
So:
- recent mail at the top; I read threads backwards to avoid putting my
foot in my mouth with a redundant reply.
- Threads with unread content are uncollapsed (because I like it that
way); there's one at the top there. Read threads are collapsed,
getting your "one line per subject" view. The ^R macro listed
earlier lets me mark a whole boring thread as read, collapsing it.
^D deletes (archives) a whole thread for irrelevant threads.
- There are colour cues too.
Threads with a flagged message are yellow. (Uncollapsed, just the
flagged message is yellow.)
Threads with posts from me (== I'm involved in) are white. Again,
uncollapsed just the post itself is white.
Unread is cyan, read is green. (I work in green-on-black
terminals.)
Full colour settings:
color attachment white default
# color body yellow default regexp
color bold yellow default
color error red yellow
color header white default "^(from|subject):"
color header magenta default "^(x-spam-status):"
color hdrdefault green default
color index cyan default "~N !~D"
color index white default "(~P !~D) | (~v ~(~P !~D))"
color index yellow default "(~F !~D) | (~v ~(~F !~D))"
color indicator white blue
color markers yellow default
color message green default
color normal green default
color quoted cyan default
color search yellow default
color signature green default
color status magenta default
color tilde white default
color tree green default
color underline cyan default
- I could pull out the first line of message text (probably by cheating and
stuffing it into the X-Label header) if I wanted; I long thought that a
neat feature of one of the Emacs mail readers though I don't value it
much for exactly the reason the screenshots show: next to nothing is
learnt from that snippet.
| > Search results as a folder? Mairix is the usually mutt approach for this
| > one, at least for me. I have a wrapper script to do a mairix search,
| > open the results folder in mutt, discard later. It's be easy to add a
| > mutt macro to initialiate the invocation of that, or to cache such
| > invocations for ready reuse (thus getting views).
|
| Yeah, I've been doing the same.
|
| Seems like Sup makes it a first class feature, and more advanced that Mairix.
Maybe so. But provided I tell mairix to extract whole threads of
matching messages I do ok. Often.
| > | and tagging
| >
| > I "tag" (crudely) by saving the same message to multiple folders, so
| > certain folders are tags (like labels are folders for GMail, sort of).
|
| I have one inbox and one archive mailbox, much like Gmail. This is the primary
| use case that Sup is designed for. This means that there is no real way for me
| to tag messages in mutt like I would in Gmail.
I think (with work) the X-Label stuff may do this. But it may not be
easy or convenient.
| > | * Bulit-in, and advanced, search features
| >
| > While mutt's in-folder search is fairly flexible, isn't it better to
| > use an external program for advanced search? That lets you choose the
| > advanced tool of your choice, an doesn't force people to use mutt were it
| > the "advanced search". Returning to my own setup, mairix is my advanced
| > search (which I underutilise).
|
| Mairix bothers me for a number of reasons.
Can you elucidate some of these. As Kyle remarked, it's not good for
remote mailboxen. But mine are local to my home server. I transparently
ssh home to read my mail when remote (yea, even from my laptop when at
home:-).
| It would be cool if Sup separated the search component, and if mutt then
| provided properly integrated hooks for this. From the documentation, it looks
| like search is made a first class feature of Sup.
Wouldn't making a macro:
macro index / ':!run-a-mairix-seach.sh ...'
make it look first class? I concede it would end up firing off a new
mutt as a subprocess.
| > | It's a shame Sup's author didn't work with mutt to get these features
working.
| > | Is the mutt development team interested in developing something similar?
| >
| > Can you flesh out a little more detail? Many needs are already met by
| > external tools to a greater or lesser degree and personally, I prefer
| > "easy to invoke" over "integrated", since the latter tends to result in
| > difficuties using the other tools outside the main app.
|
| Sure.
|
| The four things that strike me as desirable would be:
|
| * A unified view for message threads.
|
| Have you ever used Gmail?
Yes. I've even worked in an environment where that was the dominant mail
reader, and used it myself while there.
| It's pretty hard to describe without you having
| seen or used it. Basically, a whole thread is treated as a message type
| thing, occupies a single line in list views, and is navigable as a single
| thing when viewing. You can still reply to individual messages.
Sounds like collapsed threads and threads in general in mutt to me.
Indeed, GMail's weak thread support was a major shortcoming. I think it
is still weak in this regard; it tends to watch subject lines rather
than track parent-child message-id/in-reply-to state I believe.
| * The ability to tag messages, using some custom header.
|
| This would necessarily include options for viewing in both message view
and
| list view modes. I would also want to be able to automatically tag
messages
| based on content. Even if it decided that the automatic tagging of
messages
| should be done by procmail, mutt should provide a utility script.
Easy enough by editing the X-Label header, though mutt won't see the
edit until you re-enter the mailbox.
| * The ability to include message snippets in list view.
| http://sup.rubyforge.org/ss1.png
Covered earlier I think.
| * Integration with an external search program made a first class feature.
Can you outline how such integration would differ from convenient
invocation of an external search through a macro?
--
Cameron Simpson <cs@xxxxxxxxxx> DoD#743
http://www.cskk.ezoshosting.com/cs/
Usenet is essentially a HUGE group of people passing notes in class. --R. Kadel