I don't quite agree with what you proposed, but you gave me some good
food for thought. Here goes...
On Wed, Sep 01, 1999 at 10:48:49PM -0400, Brendan Cully wrote:
> On Wednesday, 01 September 1999 at 14:18, David Thorburn-Gundlach wrote:
> > I like the idea of having two different actions (view-directory and
> > open-item) for the same "object" (a folder). Since there's no context
> > (so far) for selecting a special character before a folder (like the
> > '+' in an Explorer or Eudora tree listing), what about something like
> > the new screen idea ("#3") that presents a screen something like
>
> I've been thinking some more about this. I don't really want two keys to
> operate on folders, one for selecting and one for descending. Most users
> have folders that contain *either* subfolders *or* messages, but not
> both. Making them two keys for folders that really only have one action
> available to them is counterintuitive.
I *really* don't buy your argument, particularly the last sentence.
It is possible to have mailboxes which contain no messages, and
directories which contain no mailboxes. But mutt allows opening empty
mailboxes, and allows browsing of empty directories. So as I see
things your definition of "available" runs contrary to the way mutt
already works. Opening an empty mailbox or browsing an empty folder
may not be productive, but it is always an available option the way
things currently stand.
Also, what standard of intuition are we applying? Since Cyrus has
already thrown out just about every conventional model for browsing
directories and reading mail, why not just embrace their paradigm
rather than hamstringing it with our own preconceptions?
Put another way, what is so complicated about having separate commands
for open and traverse? Perhaps in our shells we should shorten "cat"
and "cd" both to "c". cat isn't valid on directories, and cd isn't
valid on files, so what's the problem? Having the two commands which
essentially perform "select" is just extra complexity. ;)
> > +-------------------------------------------------------+
> > | 1 Folder-0 |
> > | 2 -> `-> SubFolder-1 |
> > | 3 `-> VerySubFolder-3 |
> > | 4 `-> SubFolder-2 |
> > +-------------------------------------------------------+
> > | 1 File-1 |
> > | 2 File-2 |
> > | 3 File-3 |
> > | 4 File-4 |
> > | 5 File-5 |
> > | 6 File-6 |
> > | |
> > +-------------------------------------------------------+
>
> I didn't realise until you drew it that a two-pane view isn't necessary.
> In your bottom pane, what you have called File-? would actually be
> messages (that's what folders contain). Let's skip this display until a
> folder is selected. Instead let's just use the top pane, with the
> tree-view. We can mark folders with a '+' if they have subfolders, and
> use the standard Mutt expand/collapse-thread ops for viewing subfolders.
> Whatever your cursor is on when you press enter is selected.
You've lost me here with your "those are messages, not files"
statement. (Perhaps I'm the one stuck in the wrong paradigm?) Well,
maybe I see what you are saying...
> To save bandwidth, we'd defer getting the subfolder list until
> 'expand-thread' was run on a particular folder (imagine the problem of
> folders containing several levels of nested folders - eg an IMAP
> interface to usenet).
So how do you invoke "expand-thread" as opposed to "enter mailbox"?
Sounds like you still need two keys. I also don't see how this is
more intuitive. Thinking of it as "expand-thread" may be drawing on
an existing mutt function name, but since you are applying it in a
different context I don't see any benefits to reusing the name.
(As an aside, it looks like you also see the news possibilities if
support for Cyrus IMAP servers is done right. But that is another
discussion for another time... :)
> We could also mark folders that didn't contain messages, and beep when a
> user attempts to select them. Hypothetical display:
>
> +------------------------------------------------------+
> | <Esc>v expand/collapse folders <Ret> select folder |
> +------------------------------------------------------+
> | 1 Folder1 |
> | 2 Folder2 |
> | 3 + Folder3 |
> | 4 * - Folder4 |
> | 5 + +->Folder4.1 |
> | 6 * - `->Folder4.2 |
> | 7 | `->Folder4.2.1 |
> | 8 `->Folder4.3 |
> +------------------------------------------------------+
> | * not selectable + contains subfolders - expanded |
> +------------------------------------------------------+
>
> I like this idea the best so far. What do you think?
So really what you are proposing is that we enhance the folder browser
to draw a tree hierarchy? That sounds like you would be adding a lot
of complexity to something that probably should stay as simple as
possible. And I think that "not selectable" is not quite what we are
looking for either. How about this:
I propose that we (ok, well, you :) enhance the existing directory
browsing interface to offer two size parameters for each object. One
would be "number of messages" and the other would be "number of
subfolders". This would be in addition to the existing "new mail"
indicator, or maybe there could also be a count for number of new
messages, whatever. The communications overhead for these parameters
shouldn't be any different than for the other scheme, because it is
essentially the same information, just displayed in a different way.
To integrate it with the current mechanism nicely these numbers should
be %x parameters in folder_format. That has the benefit of making
these new features optional. So if someone doesn't want the extra
overhead, they just choose not to include that particular value in
their listing. I particularly like this part of this idea. Choice is
the mutt way. ;)
In case you need a little context, let me show you part of my
inspiration for this idea. Here are three lines from inside mutt (I
use maildirs btw), with a bit of whitespace removed so they don't run
all the way to the margin and wrap:
20 Jul 20 12:16 Linux/ drwx------ brianw brianw 1024
21 N May 08 10:25 Mutt/ drwx------ brianw brianw 1024
22 May 08 10:25 Other/ drwx------ brianw brianw 1024
Most of that stuff is pretty meaningless, I just leave it in because I
don't need the room for anything else. I know this isn't the default
format, but I'm pretty sure that the elements are about the same, just
in a different order. About all I really get out of this is the name
and the 'N' flag. It would be nice if the size and date parameters
were also useful. They are all directories though, so the size is
always 1024. And don't even get me started on the dates...
So what should that listing be telling me? Well, Mutt/ is a folder
currently containing about 2k messages, Other/ is a folder containing
about 50 messages, and Linux/ is a directory containing sixteen
folders. For those of you not using maildirs, yes, there is no
indication from mutt whether a directory is a folder or actually a
directory until you select it. (Btw, the dates thing is just a
nitpick, and not a serious feature request at this point. If I've got
new mail I should read it, if not it is "old mail", so the date isn't
really important.) Here is what I might like to see:
20 16 0 Linux/
21 N 0 2068 Mutt/
22 0 50 Other/
Anyway, I think the key thing here is that not being able to tell
underlying structure from the folder listing is not a new problem.
The new problem is that mutt has two possible courses of action on a
Cyrus server where even with mixed maildirs and subdirectories mutt
"select" is sufficient for mutt to figure out what to do.
I also think this example shows pretty clearly that either your tree
scheme or my proposed scheme has potential benefits beyond just Cyrus
IMAP servers, if done properly. I think this is A Good Thing.
So, comments? If this discussion is going to continue, should we
maybe move it over to mutt-dev?
Brian
