Alan Wehmann writes: > This leads me to ask the speculative question of why wasn't the design > decision made to have the Presentation buffer show the header > information for a large message--without fetching the body, and then > letting the user decide whether or not to fetch the body, based upon > the header contents?
The original motivation for "external messages" mechanism (also called "headers-only messages" during their inception) was to allow VM folders to be small. Some people get megabytes to gigabytes of email on a monthly basis, and keeping all of it in an Emacs buffer is impractical. Some people also use gmail with practically infinite mail folders and downloading all of it into an Emacs buffer is also impractical. Reducing the *initial* download-time was also a motivation, because Emacs is basically locked up while it is downloading messages. (Note that Thunderbird doesn't have the second problem, because it is written in a language with concurrent threads. We will have to wait for Emacs Lisp to develop concurrent threads to implement something similar for VM.) I knew that Rob F had this on his To-Do list, and it now appears that Kyle Jones had it on his To-Do list too. Neither of them got around to doing it. It was a major task to implement them, because it required a careful re-engineering of almost all of VM. Avoiding the downloading of *individual messages* wasn't particularly on my mind. The wait-time there is not significant, at least in my experience, and I also think it is quite rare for people to want to delete a message without even looking at it. But it is on the To-Do list and I might spend some time on it depending on how important it turns out to be. (Note that Thunderbird doesn't have such a feature. It downloads a message as soon as you want to view it.) It could be more important to avoid downloading attachments. That way, you can download the basic text of the message and decide to delete it. This is also on the To-Do list, but it requires significant amount of new coding to query and parse the MIME structure of messages from the IMAP server. So, it will only get done when I get a large block of free time. > Any decision the user wishes to make about > deleting the message--based upon the header contents--could be made at > this point also, rather than the interactive question that asks him > about deleting the message even if he hasn't seen the header > information (with IMAP folders, it is not clear to me the > circumstances under which he would be asked the interactive questions > about downloading a large message and if he wishes to delete it--as I > experienced when using the IMAP inbox folder as a spool file). There are no interactive questions with IMAP folders. It is possible to delete the message without viewing it, but it requires some planning on the part of the user. In typical usage, the users will tend to view the message before deleting it, and that requires downloading the message. (The same answer as to the previous question.) > it. Does the design choice that was made have something to do with > whether or not the server has the capability to provide only the > headers of the message? No, the server capability is not an issue. All IMAP and POP servers have the capability to provide the headers if we ask for them. The issue is more of how to organize the internals of VM so that it can deal with a message without the body in the first instance, then download the body, and recalculate everything. (There are some dark corners in VM here in terms of how VM interacts with the Emacs display engine. I don't fully understand how it works and doing it wrong can cause "jumping cursor" problems. Rob F's 8.1.x branch had many such problems, and I applied some "vodoo" here and there to make them go away without really understanding why they were happening. See revisions 565, 544.1.22, 544.1.31, 647, 969.1.2 in the trunk. So, some things which appear to be simple on the surface actually turn out to be hard.) Cheers, Uday
