[Edbrowse-dev] Imap Editor

[Edbrowse-dev] Imap Editor

[Karl Dahlke]

I'm thinking about imap and how best to access it -
I'm seeking an interface that works whether you have 5 folders
and 5 messages in each, or 20 folders and 10,000 messages in each.

First, some separation, and I already wrote to Chris about this in pm.
Use curl to build a representation of all the emails in all their folders,
a mirror, or snapshot, of what is going on in the imap world.
Then we can decide how to render it later, and if we change our mind,
we can still retain the software that builds the snapshot.
This is a bit like parsing the html into a dom tree,
then rendering the dom tree as a text buffer - two stages.
I'm pretty sure this is a good approach for imap too.

Now, thinking about rendering, I keep coming back to the
almost inescapable conclusion that we need the power of the editor,
the edbrowse editor, that everybody knows and likes,
to manage messages if there are a lot of them.
Imagine this.
Here is the layout for gmail imap.

 -> INBOX
All -> [Gmail]/All Mail
Drafts -> [Gmail]/Drafts
Important -> [Gmail]/Important
Sent -> [Gmail]/Sent Mail
Junk -> [Gmail]/Spam
Flagged -> [Gmail]/Starred
Trash -> [Gmail]/Trash

Imagine an edbrowse session for each folder.
e1 is Inbox
Type e2 and it takes you to All, e3 is Drafts, and so on.
Within each session, one line per email message,
containing the subject of that email and the sender and perhaps the time stamp.
subject | from | date time
If you want to delete an email, guess what, you type d.
This is familiar overlap with directory mode, type d to remove a file,
and sql mode, type d to delete a row in the table.
To read or review an email, or save it to your computer,
or save its attachments, type g, to go,
and you are in the same review / save screen as pop3,
using the very same software.
This is again familiar, like g in directory mode to go to a file.
And imagine the power of the editor.
Perl regular expressions to look for certain emails.
That works even if you have 10,000.
In contrast, menus of emails and index numbers do not work!
Read through 10,000 emails and type 2893 to access message 2893.
It can't be like the dropdown lists in html, that is too awkward.
We need more power than that.

If you want to get rid of all the mail from fred@whatever, how about this?
g/fred@whatever/ d
Or if you decide those emails are actually important, then move them all.
g/fred@whatever/ m:Important
In your spam folder, a quick glance through confirms
they are all truly spam, so delete them all by
,d
Now delete actually moves them to trash in the imap server,
and it would have to do the same in our world.
Move to the Trash session,
and then empty the trash via
,d
Hundreds of emails can move or go away at a swipe,
just as you can rename or remove hundreds of files in a directory with one command.

This works even if folders have folders beneath.
One of the edbrowse sessions might be important/child, that's ok.

Could we create all this power with a new suite of interactive commands?
I don't think so, not easily.
And we'd probably be reinventing pieces of edbrowse anyways.
Of course it's not trivial to have the editor run in imap mode,
with the attendant side effects, but hey, it already runs
in directory mode and in sql mode, with those side effects,
so there is a model to follow here.

Now at this point some of you may raise your hand and say that
I am once again trying to get edbrowse to be all and do all.
Well that's a fair objection that a reasonable person would make.
I can only reply that I like the edbrowse interface, I like it better
than any other interface I've ever used or heard about or even imagined,
so naturally I want to use it for almost everything.
That's why my file manager and my sql manager all run off the editor,
and that's why I might want imap to do the same.
It's just my bias I guess.

Some might say, ok, that's fine, but could you disentangle
them into separate processes?
Maybe, but does that really help if they share 80% the same software,
the same editor commands and so on, just with some different side effects?
Even the browsing has to be there, because most emails are in html,
and such are browsed as they are presented to the user.
So you have almost all of edbrowse anyways, may as well just let it run in imap mode,
as it might run in sql mode etc.

Then some would say, ok, I like edbrowse for this, but don't
make me use it for that.
Fair enough.
Of course you can browse with it, and never use it for database access,
or files, or pop3, or imap.
The only hard coded connection is to sendmail.
Click on an html form that sends email, or allows you to contact
the company via email, and it uses edbrowse internal smtp.
A way around this would be to allow for a sendmail program in .ebrc.
sendmail = /usr/bin/sendmail
That would cause edbrowse to use some other mail client to send out its email.
That would be fine, and would make sense I think.
Then you wouldn't need any mail { } blocks in your .ebrc.
So that's something to think about.

Returning to my imap thoughts:
does it make sense to build a tree of messages first,
and render them second?
Does it make sense to render them as edbrowse sessions using the commands we already know?
Is there a better interface that still gives us the power we need,
and is not hard to implement, even for large numbers of messages?

Karl Dahlke