<<< Date Index >>>     <<< Thread Index >>>

Re: split display?



On Wed, Jul 15, 2009 at 07:33:51AM +0200, Christian Ebert wrote:
> * lee on Tuesday, July 14, 2009 at 00:31:17 -0600
> > is it possible to somehow create a display that is split up in some
> > way,
> 
> Not that I know of. If I were interested in it I would probably
> use GNU screen, split the screen and invoke 2 intances of mutt.
> (Hardly what you're looking for, I know)

Yeah, running several instances of mutt wouldn't get me close to what
I want.

> > or is there a way to assign mails to categories and fold these
> > categories?
> 
> Have you tried how far you can get with the <limit> command? And
> possibly a few macros with customized patterns?

No --- I looked it up in the documentation, but I couldn't find much
about that. It seems that the display of messages can be limited to
messages matching a pattern. If that is what it does, it's not what
I'm looking for because I wouldn't be assigning messages to categories
by patterns (i. e. regexp or string search).

Catagories would be something I want to create or remove on the fly,
eventually with sub-categories, and I would put messages into them
depending on a particular topic, depending on particular senders,
depending on age, depending on if I need or want to do something with
the message later. And I think I would (want to) end up seeing a list of
my categories on the bottom (or top) of the list of new mail or mail that
hasn't been put into a category yet. When checking my mail, I'd go
through the new mail and move it into the appropriate category.

In a way, it is very much like what could be done by creating maildirs
to use as such categories. The problem is that once a mail has been
moved out of the inbox into another maildir, it is out of sight. I
would also find it awkward having to switch from one maildir to
another all the time or to switch back and force between N maildirs
and the inbox. Besides, I do have a lot of maildirs already, many more
than I would want to have categories.

With categories, I could stay within the inbox and simply move the
marker onto a category, unfold the category, work with the mail in
that category and then proceed to the next one or continue with the
new mail or whatever. After some time, I would be done with the mail
in a category and only then move the mails to another maildir for
final storage or delete them. I would also like to have the mail I'm
sending automatically assigned to the category (or to a subcategory of
it) I'm currently working with: As it is now, all mail I sent is
stored in the sent folder, and I have to go through all that from time
to time and sort it out and move the sent mail into the correct
maildir.

It's all about having a better way to organize the mail and make
handling it much easier. I don't know any MUA that could do that; it's
outright amazing that they can't. And it's not something that could be
done with some pattern matching and limiting the display to mail that
matches a pattern ...

> > What I want to see as overview of my inbox is something like a number
> > of categories and the number of new messages in each category. I would
> > like to have the mails automatically sorted into categories by
> > criteria like "spam score > X" or sender, and I would like to be able
> > to create new categories and assign messages to them without having to
> > edit my ~/.muttrc.
> 
> Not automatically. If I knew the the categories in advance I'd
> probably use the MDA (procmail etc.) for it.

Yeah, I'm doing that already, like for mailing lists. But I don't want
to keep editing the .forward file all the time, and that can basically
only do some pattern matching. That is very useful for a number of
things, but I'm looking for more than that.

> But with <limit> (bound to "l" by default) and mutt's pattern
> matching you can do a lot on the fly, e.g. viewing all messages
> by you is just a matter of typing:
> 
> l~P
> 
> View all messages from configured mailing lists:
> 
> l~L
> 
> etc.

Ok, since I don't really understand yet what <limit> can do, I'll give
you an example: I've recently been gathering information about SATA
controller cards. In the process, I eventually sent mail to
manufacturers and some computer stores around here and eventually got
some answers. It might take a year or longer before I actually buy
such a controller, or I might never buy one. But maybe I'll buy one
next week. Now I could sort the answers I received and the mails I
sent into my "basic storage structure" --- they would end up in
=Com/done somewhere between all the other mails resting there in final
storage. The oldest mail in that particular storage is from Thu, 14
Dec 2000 --- an answer from Matrox to a question about one of their
graphics cards. I also have an answer to a request about something
else from Tue, 27 Jan 2009. It's still in my inbox because I didn't
want to move it into a final storage folder where the information
would become hard to find in a year or two when I might refer to
it. The answers about SATA controllers are also still in my
inbox. There are currently only 132 mails in my inbox --- I've
sometimes had more than 1000 mails in there because I didn't take/have
the time to sort it out. Sorting it out is tedious and time consuming
because there's eventually a lot of irrevelant mails (which I can
delete) mixed up with relevant mails in the inbox (which are there
because they are relevant and thus cannot be moved into final storage
or deleted). Obviously, the more mail is kept in the inbox, the more
time it will take to sort them out. --- As to the "sent" folder, I try
to keep that sorted, and there are currently 4353 mails in there, all
of which are, of course, in the wrong folder.

Now how would you go about organizing such mails with <limit>?

> This discussion about Sup on mutt-dev might be worth a look. No
> split views either though, afaics. I haven't tried it.

Categories would be cool --- I think we can forget about "split
view". It was only what came to mind first; having categories would do
it.

Anyway, what is sup? Another MUA? There's a Debian package: "sup -
Software Upgrade Protocol implementation" ...