emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: about working on rmail-inbox


From: Alex
Subject: Fwd: about working on rmail-inbox
Date: Sun, 9 Mar 2008 11:01:07 +0100

Hi all

Regarding the RMAIL mbox branch I've had a conversation with Richard and Venkatesh recently which I'm appending below. I've also added Venkatesh to the CC.

The MIME code we had did not share anything with Gnus, unfortunately.

Cheers
Alex


On Sun, Mar 9, 2008 at 3:44 AM, Stefan Monnier <address@hidden> wrote:
> Sadly I haven't eard from Enrik and Alex for ages. I know there
> is an embryon of a working mbox branch 8but* it is far from
> complete.

> What is not quite clear to me is what do people expect from this
> "rewrite effort" exactly ?

To me the first goal should be just to change the underlying format from
BABYL to standard mbox so that it can interact with other programs.

> I guess the primary goal is to switch to a more "popular" file
> storage but Alex and Enrik have also worked on the MIME part to,
> at last, have a decent MIME support (even basic) for us, Rmail users.

MIME additions would be good.  Ideally, this should share a lot of code
with the Gnus MIME code (some of which is also used by MH-E IIUC).



Forwarded conversation
Subject: about working on rmail-inbox
------------------------

From: Venkatesh Pitta <address@hidden>
Date: Wed, Jan 2, 2008 at 7:36 PM
To: address@hidden


Dear Alex,

My name is Venkatesh.  I found your contact on throu /whois on
freenode.  I usually remain silent in #emacs for most of the time.  I
saw your message that RMS is looking for people to work on
rmail-inbox.  I was not able to respond to you before you went offline
because I was not at the desk that time.

I like to know what skills would it take to work on rmail-inbox.  I
know knowledge of elisp is instrumental.  I have very little knowledge
of elisp.  Would it be possible to learn while working?  I have been
using GNU Emacs for over a year now on and off.  I use most of its
facilities such as dired and erc with relative ease.  If it is
possible to learn while working, I'd work on rmail-inbox.

About me:  25 old male from India.  I was working as a programmer
until December - 2006.  I'll be joining University of Sydney from
March - 2008.

--
yours,
Venkatesh
----------
From: Alex <address@hidden>
Date: Thu, Jan 3, 2008 at 12:20 AM
To: Venkatesh Pitta <address@hidden>
Cc: "Richard M. Stallman" <address@hidden>


Hi Venkatesh

I learnt Elisp while trying to write a better SQL mode, so learning on the job seems to be how we all do it. :)

I'm sure it will take you quite some time to read through the rmail code and understanding how it all works. As you know I'm usually available on IRC and willing to help, so you would not on your own.

As for the problem itself: Rmail is the Emacs' simplest mail reader. Unfortunately it doesn't use the mbox format for its mail files. It uses its own very similar but slightly incompatible BABYL format. The Rmail mbox branch is supposed to fix that. At the same time, all developers that were interested in the issue realized that Rmail comes without MIME support out of the box, and all existing MIME support extensions to Rmail depend on the BABYL format. Thus, switching to mbox requires the implementation of decent MIME handling: Messages need to be decoded for searches and for reading. This is tricky because the original Rmail mode worked by narrowing: It just opened the entire mailbox file and limited display to the mail body and selected headers. With MIME encoding this is difficult because if you decode the buffer content you're modifying the original file, which is something you don't want to do. Some of the existing extensions decoded mails and saved those decoded mails instead of the original in the mailbox file.

The rmail mbox branch contains a number of changes to the Rmail files (documented in the ChangeLog file of that branch). The way I implemented it, Rmail uses a temporary buffer for display of the current message. This requires that a lot of keybindings be moved to that new mode used for this buffer, and it requires some fiddling to get summary, mailbox file, and message display to by in sync.

Mail encoding and sending is not part of Rmail, so you don't need to worry about that. This is handled by Mail or Message Mode.

As far as I'm concerned, all MIME parts that are not plain text can just be saved to disk. Emacs doesn't really have to know how to handle them. As long as we have a mechanism by which to extend it later, then we can postpone image handling and so on.

I guess the first thing you should do is get yourself a mail account for testing, and use Rmail as-is with it. Get used to reading some mail using Rmail. Switching to the next and the previous mail, assign keywords (tags), switch to views showing only a particular tag, moving to the next and previous mail within this list, etc. Understand how the code works. Then check out the rmail mbox branch, look at the ChangeLog file and skim it to see whether this starts to make sense in light of what I wrote above. And then debug it, or finish it, or do whatever is necessary to get it to work. Or junk it and start with a totally different implementation. RMS mentioned that he thinks using an external tool like metamail is the way to go and he mailed me one of the existing extensions called rmailmime.el by Masanobu UMEDA. At the time I thought that this solution was no good, but I cannot remember the exact reasons. Perhaps I was already using a mix of Windows, OSX, and GNU/Linux, and not all systems had the required metamail utiltity available. Or I felt that the overhead for searches was too big. Anyway, once you decide to start working on it, the decision is up to you.

If you're still interested, let me (and RMS) know!

Thanks for your interest in contributing to Free Software. :)

Cheers
Alex
----------
From: Venkatesh Pitta <address@hidden>
Date: Fri, Jan 4, 2008 at 4:03 AM
To: Alex <address@hidden>
Cc: "Richard M. Stallman" <address@hidden>


Dear Alex,

I'm following the first steps that you have pointed out.  I'm using
rmail to read mails on the my account. Hopefully, soon, I'd be staring
at the code and begin making sense of it.

I'll work on rmail.
--
yours,
Venkatesh
----------
From: Richard Stallman <address@hidden>
Date: Fri, Jan 4, 2008 at 6:29 AM
To: Alex <address@hidden>
Cc: address@hidden


Venkatesh, are you interested in finishing up the rmail-mbox code?
I would appreciate that a lot.
I don't think the version I worked on does that.
Is this something that you subsequently changed?
Or are you talking about a previous version?

Using a temporary buffer has the big disadvantage that you cannot edit
the message "in place" any more.  Does it have an advantage to
outweigh that disadvantage?
That seems like a nonsequitur to me.  I do not see why switching formats
_requires_ an _increase_ in the level of MIME support.

It would be nice to do more to support MIME, but that's a separate issue.
My version of the mbox-based Rmail works on narrowing too.
Why don't we want to do this?  It works in Babyl-based Rmail, so why
shouldn't rmail-mbox do it this way too.
We can still do it that way.  Why not?
----------
From: Alex <address@hidden>
Date: Fri, Jan 4, 2008 at 8:49 AM
To: address@hidden
Cc: address@hidden


You asked whether using a separate buffer to display a message was
code I had written myself or not, and we talked about the use of
narrowing to display a message.

I just checked out the rmail-mbox-branch and I'm referring to the
following code in rmail rmail-show-message:

     (let ((beg (rmail-desc-get-start n))
           (end (rmail-desc-get-end n)))
       (rmail-header-show-headers)
       (widen)
       (narrow-to-region beg end)
       (goto-char (point-min))

Displaying messages therefore still works by narrowing, allows editing
in place, and so on.

The code also has the following:

       (if (eq rmail-enable-mime t)
           (funcall rmail-show-mime-function)
         (setq rmail-view-buffer rmail-buffer))

If I remember correctly what you had to do is set rmail-enable-mime to
t and rmail-show-mime-function to rmail-mime and load rmailmm.el. Then
the message you're viewing gets copied to a separate buffer and a MIME
handler is called to display it. At the time a separate modifiable
buffer seemed like the only sane way of MIME handling.

It seems possible to finish the Rmail code without having to work on
the MIME stuff with the current setup. That's good news.

You said that switching formats does not require an increase in MIME
support. That is technically true. At the time I wanted to use RMAIL
for my regular mail, however. One did not require the other, but both
were required by the kind of mail I was getting. (And not being able
to read my mail with Rmail has caused me to switch to other mail
programs, and that in turn has drained my dedication to work on
Rmail.)

You also asked why modifying the original file was something we don't
want to do. Some modification is ok: If the message is an encoded
plain text message, recoding it and changing the MIME headers to
reflect that is no problem because the mail file is still usable by
other mail readers. That's the only limitation on modifications as far
as I know. One MIME handling extension would take HTML attachments,
transform them into plain text, and replace the attachment with the
plain text. This kind of modification would not be ok, I think.
----------
From: Venkatesh Pitta <address@hidden>
Date: Fri, Jan 4, 2008 at 12:31 PM
To: address@hidden
Cc: Alex <address@hidden>


Yes, Richard.  I am interested in finishing the rmail-mbox work.



--
yours,
Venkatesh


reply via email to

[Prev in Thread] Current Thread [Next in Thread]