Re: storing tagged state?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thursday, July 16 at 11:52 PM, quoth lee:
is it possible to store which messages are currently tagged, to do
something and then to restore the previous tags?
Sure, it's possible. Not *easy*, but possible. The way I'd suggest is
to have your macro pipe all tagged messages to a script that saves
their message-id headers... this is a trivial example that I haven't
tested, but you get the idea:
awk '/^Message-ID: /{print push \tag-pattern~i,$2,enter\}' \
/tmp/mutttags
That'll save off all the message ID's. Then you can clear the tags and
do your macro work. Next, you need to restore the tags... all you need
to do is source the temporary file you created.
~Kyle
- --
You can gain reconciliation from your enemies, but you can only gain
peace from yourself.
-- Rubin The Hurricane Carter
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!
iQIcBAEBCAAGBQJKYB/eAAoJECuveozR/AWeZFkP/3xYhSsjxWsg11seGYUFNnR4
KgnWOkSlfy4VcvE+jbIDYfSKab+KpGqW41EmCaXQY6mvdWnwgAzoWycQCDPzJM0W
ts+xl9P0uWuskoTvGHSq8GbDPd3GodceIKR80zItiJUH7MHcaN4sdauOgcklVfwM
W5PxIi27F9QxF9c/gMYmf8Xd7pnLyItrYTeEXS7e3aCxBaVRLwZD1g6oxPSZ+vRd
UC0oxsyJyVzJhPxGAu5r/JAIC5aiRais6jTCxuCjE1d+R55mK6zjZDJ0czoq2lJb
wck4wi1nOUKZDQ2uYDwUNvJr78aJIR3QFJ1RnHt2YP7PCy0klA0AobnnZo2SwzHT
QwrKx5dRVBQD4N/uVE5s3P9/GmaPRbDjMjA1FoHHIGurV627k52+MvyCwiHqBOaU
XWFMr4eZcRgRS0GgoSBypToqWeCK+GaC1hfl/CexFs5gx52yodgpYiatbrdyVPrY
qSyAdWEX+SGuGHjQoDptw+8GoPOvpdRHgnCghBAkx9wd+z1j7U1SwtrSQl6qEDe7
nPLFmUzrOXB3vSQXpG4flAL1dyHT1AWqT6g5nIupM6GXancyZJjOhImPjrUG5Rs6
55EybaWUJy4Ua/vO00GWqDyZO9YPG5PKWLmgaqYOZAuqk+3EsWhVbNsUfha2Nxff
qkGyN2X/Vmr8t0tws4e/
=F7/3
-END PGP SIGNATURE-
Re: multipart/alternative question
On Fri, Jul 17, 2009 at 12:48:45AM -0500, Kyle Wheeler wrote: On Thursday, July 16 at 10:51 PM, quoth lee: On Thu, Jul 16, 2009 at 10:16:57PM -0500, Kyle Wheeler wrote: But anyway, I don't consider this message to have ANY attachments. The person didn't send me any extra files to look at. They sent me the same message twice, one with extra formatting and one without. I don't think most people would consider that to be a message with attachments, so I don't think mutt should say that there is an attachment. Well, I would consider such a message as attachment only: No message (i. e. no body), only three attachments. Logically, an attachment needs something to be attached TO. Ok, maybe I should have that expressed less ambiguous. What you get is a message (RFC822) that doesn't have a body (or has an empty body). To this message, something is attached. The MIME equivalent of what I just described is this: I 1 no description [multipart/mixed] I 2 |-no description [text/plain] A 3 `-no description [image/jpeg] Entity #3 is the attachment. It is attached to Entity #2. Entity #1 is the staple: it exists only for the purpose of attaching #3 to #2. Yeah, I see what you mean. But you've skipped a step: the message. If you consider the implementation, starting with RFC822 (and considering RFC821), you have a message. The message doesn't have a body. Your entity #1 is attached to the message. That entities #2 and #3 are contained in entity #1 doesn't change the fact that they are, though indirectly, attached to the message. That entity #3 could be considered as attached to entity #2 doesn't change the fact that they are (indirectly) attached to the message, either. The fact that all entities are attached to the message makes all of them attachments to the message, regardless of their purpose, regardless of how they might be attached to each other and regardless of how they are attached to the message. Thus you cannot deny that you have a message (without a body and) with three attachments. *You cannot send attachments without a message.* I understand, having read enough philosophy, that you can argue ad infinitum about the truth that the letter is just as much the attachment to the photograph as the photograph is an attachment to the letter, but that's a really pointless argument. ok :) Then we don't need to argue whether a message is still a message or not when it doesn't have a body. RFC822 gives us the basic definition of what a message is. That still seems to be in use. Other RFCs define attachments --- I'll admit that I didn't read those because I didn't need to yet and because there are so many and because it's hard to tell which ones are current and which ones are superseded by others ...
Re: multipart/alternative question
++ 16/07/09 09:03 -0500 - Kyle Wheeler: Since mutt is set to prefer text/plain, all I see is the plain text message, with no indication that there is an attachment (or even an html part). First, of course there's no obvious indication that there's an html part. Why should there be? Unless you press v to view the MIME hierarchy of the message, mutt doesn't tell you about alternative components to your email. [...] The same issue has been discussed before on this list: [1]. Kyle did a good job of explaining at [2]. [1] http://www.mail-archive.com/mutt-users@mutt.org/msg37364.html [2] http://www.mail-archive.com/mutt-users@mutt.org/msg37430.html -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature
Re: split display?
So, I think I understand what you want: gmail. Yes, it's a web interface, with limited keyboard commands, but the whole basket/basement thing is implemented near exactly as you describe. I think you'd be pretty happy with it, though a specialised version for your own domain costs a bit more than mutt. Then why is it so fumbly? It's fumbly with local maildirs, but try it with IMAP. If you don't enter all the folders you have on the IMAP server into the configuration or something, it's horrible. And every time you create a new IMAP folder or delete one, you'd have to edit the config again ... I've never had any problems. And I don't have to predefine every single folder in a config file, I just tell it what my inbox, draft, and sent folders are. To change folders: c, =foldername, or tab twice for a list. And, mutt + screen is beautiful. I run several instances of mutt, so I can quickly access my various common folders with a simple ctl-a ctl-[np]. jake
Re: split display?
Hm, I need to split this mail because I got it back with a message telling me that only 20k characters are allowed. This is part one. On Thu, Jul 16, 2009 at 09:34:49AM -0500, Derek Martin wrote: On Wed, Jul 15, 2009 at 09:54:16PM -0600, lee wrote: So, in other words, you would need to manually mark the message as belonging to a category. You would need to take action to associate the message with a category. So, what's the problem with just moving the mail to a category-specific mail folder, exactly? 1.) It is awkward. My point above was that it's going to be awkward regardless; you're going to have to take some action to manually mark your messages with your category. Yes, but that doesn't mean that there couldn't be an easier way to do that than there is now. 2.) It would mess up the folder hierarchy I already have by greatly increasing the number of folders. It's too complicated. You can adress this with the macros I suggested to put you in category mode vs. normal mode. It has the effect of distinguising the folders for categories from your regular mail folders. Maybe, but to do that, I would have to spend a lot of time to learn how to create macros and to program some that would do what I want. And I don't want to use two different modes. 3.) It's incompatible with the folder hierarchy I have. Given the above, I don't see how... It would create another folder hierarchy within the one I already have --- or, even more complicated, somewhere else. 4.) The messages would be out of sight and not easy to access and would be forgotten. I already covered this; you leave them marked new, and Mutt will remind you that they are there. This is not any different from the way you are currently managing new mail in different folders... I would have to keep marking them as new after I read them, then move them into other folders. Then mutt would keep nagging me about them. If there's another new message that would belong to a category I have, I would have to browse through the folder hierarchy, and I would have to remember for each directory I see in the list if it's a maildir or a directory that contains maildirs. Changing folders in mutt is fumbly (c TAB TAB enter CTRL-g CTRL-g c TAB TAB down down ... enter ?? q ??? CTRL-g ... Hmm.? c ...). This is simply false. Press 'c' to change folders. Now press '?' to bring up the list of mailboxes you've told Mutt to watch with the mailboxes configuration keyword. They're all there. Now type the number of the folder you want to enter, or use your keyboard's directional keys to select it if you prefer. It's that easy. It shows all the folders --- pressing y shows only the ones in the config. Some of the folders shown with c are just directories that have maildirs in them, some of them are maildirs, some of the folders I have are maildirs with submaildirs. Mutt shows them without distinction and eventually gets confused when dealing with a directory that is not a maildir, or it treats a maildir that has a submaildir as a directory. Why doesn't mutt show directories as directories, maildirs as maildirs and maildirs with submaildirs as such in the list so that you can tell from the list which is which, without having to switch into a directory first? And is it possible to get a recursive list so that I could switch to a subdirectory directly instead of having to go from one directory to another? 5.) There's no way to delete maildirs from within mutt. Mutt is not a file manager and shouldn't have to be one. This seems not relevant; there's no need for Mutt to delete the maildir. It is relevant to me because I don't want to pile up empty maildirs throughout my mail storage. Mutt doesn't even show you in the list of directories how many mails there are in a directory, so empty ones remain unnoticed. To prevent piling up empty maildirs, I think three times before creating a new one and preferably don't, and when one is empty, I'm forced to open a shell and to delete it right away because if I don't, I either forget which one to delete or would have to write it down. I only did that when I was cleaning up my mails, and that means that when I need to delete an empty maildir, I'm forced to interrupt what I'm doing and to change to another program to find and delete the maildir. On top of that, since maildirs have subdirectories, you either delete four directories or use rm -rf. Of course, rm -rf is something you have to be really careful with ... It's awkward. Just keep the number of maildirs as low as possible. Just ignore it if there's no mail in it. Remove it by hand if you feel you really need to (but you don't). What's the point of having hundreds of maildirs in the list of which many are empty? That makes things just more difficult. But as we've discussed in a different thread, it's not safe for Mutt to remove maildirs -- the implementation is a bit difficult and can't
Re: multipart/alternative question
Hey, On Thu, Jul 16, 2009 at 10:16:57PM -0500, Kyle Wheeler wrote: I 1 no description[multipart/alternative] I 2 |-no description [text/plain] I 3 `-no description [text/html] [...] But anyway, I don't consider this message to have ANY attachments. On Thu, Jul 16, 2009 at 10:51:44PM -0600, lee wrote: Well, I would consider such a message as attachment only: No message (i. e. no body), only three attachments. [...] The fact that all entities are attached to the message makes all of them attachments to the message, regardless of their purpose, regardless of how they might be attached to each other and regardless of how they are attached to the message. Lee, directly or indirectly, you're just playing language games. You're using the word attach to misleadingly describe the process by which a message has message entities added to it. While this is certainly a valid use of the word attach, you're then extrapolating that all entities must therefor be attachments. I guess in some general sense you are correct, but within the context of a MUA, an attachment has a very specific and well defined meaning, that is much more narrow than this. An attachment is a message entity that a user is likely to add or save to and from the file system, as separate to the main message. A good litmus test, although by no means perfect, would be if the entity has an explicit file name. In the example that Kyle gave, there are clearly no attachments, and I would not want to use a MUA that listed any. Best, -- Noah Slater, http://tumbolia.org/nslater
Re: split display?
On Thu, Jul 16, 2009 at 06:25:17PM -0600, lee wrote: 1.) It is awkward. My point above was that it's going to be awkward regardless; you're going to have to take some action to manually mark your messages with your category. Yes, but that doesn't mean that there couldn't be an easier way to do that than there is now. I'd venture a guess that the overwhelming majority of Mutt users don't find it awkward... I certailnly don't. You have to remember that the goal of Mutt is to provide the user with a great deal of power to process mail in a way that's fast and flexible, in the context of a terminal window. Terminal windows historically have dimensions of roughly 80x25 cells of ASCII text, which doesn't leave you a lot of room for the kinds of things you want. Granted, these days most people are using terminal emulators with adjustable sizes, but lots of people still use 80x25 terminal windows, either because they like to maximize their screen real estate, or because they are actually still using those ancient text-oriented termnals, believe it or not! There are also people who read their mail on mobile devices, with screens even smaller than 80x25. Mutt tries to accomodate everyone... but on such small terminal screens, there's a limit to what you can do with the UI and maintain some degree of usability. Mutt optimizes a lot of things for the way the vast majority of people expect to manage their mail, which is the way I outlined. What you want is something entirely different, and Mutt is not designed to do that; nor am I aware of any mailer which does what you want. You're complaining a lot about the UI being clunky -- I think you want a GUI mail client, for starters... Sylpheed or GMail might be more to your liking. Mutt isn't designed to handle mail the way you want, so short of some of the tricks with threading that have been mentioned here (which seem a lot more clunky to me than what I've discussed, honestly), I don't think you're going to get Mutt to do what you want any time soon. A big part of the problem is that you're apparetnly trying to use Mutt through its file browser interface... this is not how Mutt is intended to be used, and yes, it's clunky: Mutt is not a file manager. It's expected that you'll tell Mutt about the folders you care about. You are trying to use Mutt in a way that does not take advantages of the strengths of it, and highlights the weaknesses. If you're unwilling to change the way you process your mail, I think you will become increasingly dissatisfied with Mutt as your mail client over time. You can adress this with the macros I suggested to put you in category mode vs. normal mode. It has the effect of distinguising the folders for categories from your regular mail folders. Maybe, but to do that, I would have to spend a lot of time to learn how to create macros and to program some that would do what I want. I don't think so... I gave you the command you need (mailboxes), you need only look up that in the manual, and then read the secton on macros... I'd bet you could get this working in about 10 minutes. And I don't want to use two different modes. Well, that I can not help you with. Perhaps the mail thread trick is enough for you. 3.) It's incompatible with the folder hierarchy I have. Given the above, I don't see how... It would create another folder hierarchy within the one I already have --- or, even more complicated, somewhere else. But it doesn't matter! Because you just tell mutt about them with the mailboxes command, and the location becomes not interesting. The folder browser prevents you with a flat view of all your mailboxes that you've told Mutt about. You keep insisting that Mutt is clunky and won't do what you want it to, but you haven't even tried to use Mutt the way it's intended to be used. What do you expect? If there's another new message that would belong to a category I have, I would have to browse through the folder hierarchy, and I would have to remember for each directory I see in the list if it's a maildir or a directory that contains maildirs. Changing folders in mutt is fumbly (c TAB TAB enter CTRL-g CTRL-g c TAB TAB down down ... enter ?? q ??? CTRL-g ... Hmm.? c ...). This is simply false. Press 'c' to change folders. Now press '?' to bring up the list of mailboxes you've told Mutt to watch with the mailboxes configuration keyword. They're all there. Now type the number of the folder you want to enter, or use your keyboard's directional keys to select it if you prefer. It's that easy. It shows all the folders --- pressing y shows only the ones in the config. So put your folders in your config. This is the way Mutt is intended to be used. You can even do it programatically, by, for example, writing a script to identify maildirs in a particular directory tree, and output mailboxes commands for each one it finds. Moreover, if you stop
Re: Inline text attachments
On Tue, Jul 14, 2009 at 02:35:50PM -0500, Kyle Wheeler wrote: For reference, since people can and do rebind their keys, it's probably better to refer to things by their function names. In this case (as you can see from the help menu), it's toggle-disposition. Okay, thanks. You *can* automate the process, but creating a random file name is going to be difficult. Mutt isn't set up to do that. Most folks don't want multiple inline text parts (most of us just create a single text part). When I create a new message, mutt creates a file like: /tmp/mutt-tumbolia-1000-2303-0 Is there no way to hook into the same thing? Just to clarify, I have been using emails as a way or archiving various things that I find on the Internet. If I am archiving an image from Wikipedia, I may want to attach the image regularly, and then have two inline messages, one containing the URI the image was retrieved from, and the other containing any out-of-band metadata from the image page on Wikipedia. This might sound like an odd way to be using emails, and I'm sure it is. Hopefully though, you'll see that what I'm essentially wanting to send an email with multiple, but separate, inline messages. You can add a line to your mailcap to handle text/plain messages that contains a compose= setting, like this: text/plain; less; compose=emacs %s For a detailed explanation of that, read the mailcap man page. Interestingly enough, this only seems to half work: new-mimefooentertext/plainenter Emacs is fired up, editing a file at /tmp/foo, which is correct. After saving, I then do: edit-mime And a Vi is started, editing the correct file. Interestingly enough, if I do: edit-file Emacs is fired up, editing the correct file. What's going on here? What's the difference between these two commands? Thanks, -- Noah Slater, http://tumbolia.org/nslater
Re: multipart/alternative question
On Fri, Jul 17, 2009 at 02:36:41PM +0100, Noah Slater wrote: I guess in some general sense you are correct, but within the context of a MUA, an attachment has a very specific and well defined meaning, that is much more narrow than this. Well, I'm not trying to mislead someone. Where is defined what an attachment is for the context of a MUA, and who made the definition? An attachment is a message entity that a user is likely to add or save to and from the file system, as separate to the main message. In Kyles example, that would be saving the html attachment to view it in a web browser. The user might do that himself, the MUA might do it automatically. If you use a MUA that cannot display text/plain, you might save the text/plain to display it ... And who is to decide how likely a particular user is to save a particular attachment, for the purpose of the MUA counting the attachments? The MUA would have a hard time to figure that out. A good litmus test, although by no means perfect, would be if the entity has an explicit file name. In the example that Kyle gave, there are clearly no attachments, and I would not want to use a MUA that listed any. To me, it has clearly three attachments. It doesn't matter if a user is likely to save an attachment or not. BTW, what's a message entity? Attachments are not message entities if you look at RFC822.
Re: Inline text attachments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Friday, July 17 at 04:38 PM, quoth Noah Slater: When I create a new message, mutt creates a file like: /tmp/mutt-tumbolia-1000-2303-0 Is there no way to hook into the same thing? Not that I'm aware of... but very creative people have proven me wrong before. This might sound like an odd way to be using emails, and I'm sure it is. Hopefully though, you'll see that what I'm essentially wanting to send an email with multiple, but separate, inline messages. I still don't understand the benefit of that, but shrug Interestingly enough, this only seems to half work: new-mimefooentertext/plainenter Emacs is fired up, editing a file at /tmp/foo, which is correct. Sure, new-mime == compose. After saving, I then do: edit-mime And a Vi is started, editing the correct file. Ahhh, huh, I didn't realize it, but there's also an (apparently undocumented) edit flag. Check here: http://www.mail-archive.com/debian-bugs-d...@lists.debian.org/msg666929.html note in his attachment, he has: text/html; view %s; edit=emacs22 %s; compose=emacs22 ... %s; needsterminal Interestingly enough, if I do: edit-file Emacs is fired up, editing the correct file. Because THAT uses $editor. I admit, this is all very strange... but it does have a certain logic to it. ~Kyle - -- It is dangerous to be right when the government is wrong. -- Voltaire -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJKYKo2AAoJECuveozR/AWe5DoP/j3D29skc/F3FiJLxgS7bCIU 6Tpl3uUDYw5gR2wvMDBcjS29miiEzOygk6ZbmrvubAQhBASC4/+IglPruUriuXtn 7xf183L9dLAMCalDDYTg44luUfZOVU6ury8L4psTJnT34xfoWh2Dur0jDS3zp76V b1HSC2uyShHf1FmMEJkBtO5iCvNAo7v4Xfbg+v85tKLXRw8zJxr/kaZ7M2dvA9It MPBZmMw65xy30UE8eMm0uXWa4vB/lgh6EjErlrTbt4EyB5gWVigmotzyBSsi/oJN 66vWlNsBKCpzrqdq3pTja+K8RuA+IbHrBwfDvGgZNjZ3fbWpTnkC2yMpf1vlba80 qRGRaMVH/D3PIqCIJNirq/UNk77eI/18Jcw/6KLOWi3WOn4Fv7W+MqEzGKtoZ/SK VbkzpErdVZU0b+v97y62eb+kLaONjKRgqjtmKpQ97JwXpSmq2hJs5GNx7ViIA8xB QH0fKEY1asp/zxW0a3eaid6x622akkV92eqkk8H+345jPg2+raP+jEfjTbo27yQE z2Kn8aK/vh4Rg3tRuBJ6mLK9Op0Wpg1jKtFBVov08GVIlqjpguZRKtmj1WGrgW49 oWnGgWFQQUPhYesRlK6qc0Hpt1RgyYPq6LPafXRx0in02FhJWVbr5MiWFVwWbUxU JISuhKG6zsc/DH/8sD2o =suM9 -END PGP SIGNATURE-
Re: use current folder name as argument to abitrary command
On Mon, Jul 13, 2009 at 02:38:52PM +, Grant Edwards wrote: I repeatedly submitted a patch that did that. It was rejected. [I don't remember what shortcut character I made expand into the current folder.] I eventually gave up. Hopefully you'll have better luck. Any reference? We have a shortcut for the current folder already, which is a mess to use in hooks. I think of read-only variables. Rocco
Re: multipart/alternative question
On Fri, Jul 17, 2009 at 12:39:19AM -0500, Kyle Wheeler wrote: No, I mean that MIME components (aka entities) have meanings that affect the interpretation of other MIME entities. ok I could appeal to something like Wikipedia (which says an email attachment is a computer file which is sent along with an email message), but I'm guessing you don't care much for so-called official definitions. It depends ... I distinguish between definitions and descriptions, and since there are often many different descriptions of something (calling themselves definitions), I don't care much for so-called official definitions. Then look at different languages and the descriptions of the same thing, and even if the description of something may be very similar to one in another language, people who have different native languages can (and usually will) have a different understanding/perception/relationship/opinion of the same thing. That is something very difficult to include into a description, and it's usually not done. As to RFCs, the ones I know are more definitions than descriptions, and I consider RFCs as relevant. They are what is in use; implementing something is either compliant with RFCs or may not work. Without RFCs, one MTA couldn't understand another one, and one MUA couldn't display messages created with another one. Mutt says that there are 0 attachments. I say there's at least 1. We clearly have different definitions of the term. Yes --- but that's ok. I find my definition more useful, because then I can use it to tell me whether there's some component of the message that I can and will want to save to disk. That's fine --- it is what is useful for you. You could rename what is called attachment counter to file counter or something, or you could say that you would like to have a counter telling you how many attachments there are that you might want to save. Mutt already supports this in that you can specify what things should qualify as attachments and be counted. The problem is that the counting doesn't work right. What's the utility of your definition? You mean what the usefulness is of my considering everything that is attached to a message as an attachment? It gives me an impression about how messed up a message might be. If it's a message that might be a SPAM mail, it will prevent me from opening it. What is the usefulness of knowing if something is attached to a message that you might want to save to a separate file? It's useful to you, but not really useful to me. Why do *you* care how many containers are on the ship? See above --- you care about what's in the containers, I care about how many containers there are. How do you want to unload, i. e. would you prefer to unload all the bricks at once by unloading the container (save the whole container to disk with everything in it), or would you rather open the container and unload (save to disk) one brick (file) at a time? It's all about *display*. Do you want the contents a given attachment (or MIME component) to be *displayed* when the rest of the message is displayed, or do you want it to be represented more succinctly, merely letting the viewer know that it exists? The former is an inline attachment, the latter is a non-inline attachment. So you would say that all of them are attachments and therefore should count as such, no matter how they are supposed to be displayed. Am I really that hard to understand, or are you just trying to get under my skin? Well, what were you saying? For the umpteenth time, no, not all MIME entities are attachments. To me, they are. RFC822: RFC 2045: This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII. Thus, in the context of MIME, the RFC 822 definition of a message format is no longer supreme. It has been, in the words of the MIME RFC, redefined. Ok, so which is the current RFC for this? 2045, or is there even another one modifying or superseding 2045? 2045 says: The term message, when not further qualified, means either a (complete or top-level) RFC 822 message being transferred on a network, or a message encapsulated in a body of type message/rfc822 or message/partial. That's a rather unlucky definition because it uses the term it defines in the definition. I don't understand what message means when they say a message encapsulated in a body. Do they mean an RFC822 message? Do they mean body in the sense of RFC822? You shouldn't ask me that because if I wanted to send someone a message and a JPEG, I would send a plain text
Re: multipart/alternative question
On Fri, Jul 17, 2009 at 11:37:50AM -0500, David Champion wrote: * On 17 Jul 2009, lee wrote: Well, I'm not trying to mislead someone. Where is defined what an attachment is for the context of a MUA, and who made the definition? Content-Disposition's role is described in RFC 2183. But attachment is a very ambiguous term. They have a good way of putting it in RFC 2183: Two common ways of presenting multipart electronic messages are as a main document with a list of separate attachments, and as a single document with the various parts expanded (displayed) inline. The display of an attachment is generally construed to require positive action on the part of the recipient, while inline message components are displayed automatically when the message is viewed. A mechanism is needed to allow the sender to transmit this sort of presentational information to the recipient; the Content-Disposition header provides this mechanism, allowing each component of a message to be tagged with an indication of its desired presentation semantics. There is a distinction between attachments and other message components. You could say everything not designated to be displayed automatically in line is considered as an attachment. It's less about what the user wants to do, and more about the component's relationship to the message that the sender composed. But this is still rather subjective. There could be a counter counting message components. The RFC 2183 is supposed to define a means *for the sender* to specify how he wants parts of the message to be displayed. How the recipient deals with the message is up to him. Is there an RFC that defines how a MUA is supposed to deal with such multipart messages? RFC 2183 seems to (reasonably) say only a minimum about what MUAs should do.
Re: multipart/alternative question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Friday, July 17 at 11:37 AM, quoth lee: Mutt already supports this in that you can specify what things should qualify as attachments and be counted. The problem is that the counting doesn't work right. Agreed! What's the utility of your definition? You mean what the usefulness is of my considering everything that is attached to a message as an attachment? It gives me an impression about how messed up a message might be. If it's a message that might be a SPAM mail, it will prevent me from opening it. Hm. See, I find that I really don't care how messed up a message might be. For example, I often get emails from corporate secretaries that use Outlook and some goofy HTML stationery (complete with background picture, goofy fonts, corporate logo, etc.). Knowing that it's a complex MIME structure isn't a useful piece of information to me. But to each his own, I suppose. What is the usefulness of knowing if something is attached to a message that you might want to save to a separate file? It's useful to you, but not really useful to me. Well, the usefulness to me is that occasionally I receive messages that don't make it clear that there IS an attachment in the text. For example, I'll get an email that reads Can you make sure that the schedules are right for next month?. It also has a copy of the schedules attached (probably that's messed up and isn't what had previously been established as the schedules), but that's an easy fact to miss in a text-based email reader (GUI email programs, and webmail, often make such things a bit more obvious). Why do *you* care how many containers are on the ship? See above --- you care about what's in the containers, I care about how many containers there are. How do you want to unload, i. e. would you prefer to unload all the bricks at once by unloading the container (save the whole container to disk with everything in it), or would you rather open the container and unload (save to disk) one brick (file) at a time? See, here's where I think the metaphor becomes a bit strained. I don't know how what you're talking about maps back to email. It's all about *display*. Do you want the contents a given attachment (or MIME component) to be *displayed* when the rest of the message is displayed, or do you want it to be represented more succinctly, merely letting the viewer know that it exists? The former is an inline attachment, the latter is a non-inline attachment. So you would say that all of them are attachments and therefore should count as such, no matter how they are supposed to be displayed. Am I really that hard to understand, or are you just trying to get under my skin? Well, what were you saying? According to the Content-Disposition RFC (2183), which is what defines the idea of an inline MIME entity versus an attached MIME entity, the difference is in presentation (aka display) to the recipient. Here's how they describe it: Two common ways of presenting multipart electronic messages are as a main document with a list of separate attachments, and as a single document with the various parts expanded (displayed) inline. The display of an attachment is generally construed to require positive action on the part of the recipient, while inline message components are displayed automatically when the message is viewed. That, I think, pretty much restates what I was saying. In particular, mutt observes and respects the two disposition types outlined in that RFC: 2.1 The Inline Disposition Type A bodypart should be marked `inline' if it is intended to be displayed automatically upon display of the message. Inline bodyparts should be presented in the order in which they occur, subject to the normal semantics of multipart messages. 2.2 The Attachment Disposition Type Bodyparts can be designated `attachment' to indicate that they are separate from the main body of the mail message, and that their display should not be automatic, but contingent upon some further action of the user. The MUA might instead present the user of a bitmap terminal with an iconic representation of the attachments, or, on character terminals, with a list of attachments from which the user could select for viewing or storage. For the umpteenth time, no, not all MIME entities are attachments. To me, they are. Well, then I think it's safe to say that you have a rather unusual view of MIME entities that is not shared by (at least some of) the designers of the MIME standard. Ok, so which is the current RFC for this? 2045, or is there even another one modifying or superseding 2045? There isn't an RFC that obsoletes 2045. It is updated by 2184 (MIME Parameter values character sets), 2231 (obsolets 2184), and 5335
Re: multipart/alternative question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Friday, July 17 at 12:18 PM, quoth lee: Is there an RFC that defines how a MUA is supposed to deal with such multipart messages? RFC 2183 seems to (reasonably) say only a minimum about what MUAs should do. Not that I know of... The closest I can find is RFC 1521, which says: It may be the case that some user agents, if they can recognize more than one of the formats, will prefer to offer the user the choice of which format to view. This makes sense, for example, if mail includes both a nicely-formatted image version and an easily-edited text version. What is most critical, however, is that the user not automatically be shown multiple versions of the same data. Either the user should be shown the last recognized version or should be given the choice. Granted, this is talking about presentation of the CONTENTS of the multipart/alternative sub-entities, but I think it applies to summaries of that content as well (i.e. attachment counts). In other words, I think the suggestion here is to count attachments from only ONE of the alternatives, not from all of the alternatives, because to count attachments in ALL of the alternatives is equivalent to being show multiple versions of the same data. Of course, this is complicated by the preceeding paragraph: In the case where one of the alternatives is itself of type multipart and contains unrecognized sub-parts, the user agent may choose either to show that alternative, an earlier alternative, or both. It doesn't say what to do if multiple alternatives are of type multipart, and showing both seems to directly contradict what is most critical a mere few sentences later. ~Kyle - -- Preach the Gospel at all times and when necessary use words. -- St. Francis of Assisi -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJKYMlsAAoJECuveozR/AWebUsP/1KhmB/AjnTqQSFJPF/th+Qf X4+kbao9m2xMNSE2pcpT/3eZwyk886gCXsgWfxtA2I78/9In32UTeg2YkNROIAHX BT26rSd3rZMqTAL/5yKyWs5jAcz4NlRES0nCd6UIpS5vk9lNqEFWjhMz/n58UsUo xtiR7PjCEc5fVwTRH5ukN7GKoTdc5rzzmsn8wuehIdTPTbvJOA/9oWaGP8mhXpow X0ak3i4JKBQEfpn1J6lJJFe0FE4Rguex60EdqinWWMqgRL4nmU/I4uNf+sd4KRQt G+6z84bkm1EqQFms6+7DYuP9NTaYMQw1NLfdb5fdbrSFYmi6G9YRgJvy5g86tWKZ dG3/SGyKdzwbvdyIBGo+UJdTqkgI72JtUrBWjjr0ULmKWZg6kmd4nGh/d8p0CzSH A6u9iW9XsVjokXTBTHD1ggswJJrllfLXqaiRK45sHjHRBHJUA5bWayGCdeFywfKz l0KrbtuCTlBxg6VMErRKTd4rVYIYlDhaKX0ooC+rrwbbWxRjo7U9BIkyUU11a8tx KDotd4SKy2gw75pkc10+nWPaVwAVDnqZAclUz4Oe6V1BK+X9Pn4Sv2srMgw8MEin 6P0s389ZFRNKRMlU2PkvE2Op9zv8r7Odjx4GgUKXXG0+HGHv1goVeNKNWCB/LXyA t1v7bcaptJpkJKCQPqSU =U5rt -END PGP SIGNATURE-
Re: multipart/alternative question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Friday, July 17 at 01:56 PM, quoth Kyle Wheeler: On Friday, July 17 at 12:18 PM, quoth lee: Is there an RFC that defines how a MUA is supposed to deal with such multipart messages? RFC 2183 seems to (reasonably) say only a minimum about what MUAs should do. Not that I know of... The closest I can find is RFC 1521, which says: Actually, RFC 2046 is more recent, but says nearly the exact same thing. It adds: Systems should recognize that the content of the various parts [of multipart/alternative sections] are interchangeable. Systems should choose the best type based on the local environment and references, in some cases even through user interaction. By Systems, I'm pretty sure they mean recipient systems. ~Kyle - -- The most important thing a father can do for his children is to love their mother. -- Fr. Theodore Hesburgh -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJKYMsvAAoJECuveozR/AWeCUEP/2ZK1QYpmvo9QjHS52C+IRMG LpH+SrgiKtwx4tqFIqkpcCEzKvpuiUQpwGMBNGBkkX9FmcRyXesbGOUD1Lkey0uP wbf0e5mkCCQA7YAeeTDCa/knpqAQjvck/1jdwiggsgCFh3AGeNS0aGcTRbY1G6SE ONapoo5Pa7ZA6prnBYtrcLVABCiplfx69vAM2VID90T2LRpL7+IZOlakzJCqlEf+ Xt6fWRHq1g07wV9ezJnJi8kc7pnN1pbVQyIdnvSBeuo2jnNaT1+gzjK3epREnvgr NcPG92awoG3ljiEQ3ICNeto4Cs3aqWYYZrzJ1XhJrF3gKWFMVXZHSyPV6kc5gJtF JBsTiwEa1qtiSufq72B8qU7GutzJSUbcupzfOjWAxSJBu18KkLksPRfk2g2GRO0q twhDrCgN3CSKtowZXt66HaQN5kvqM1BEH28qqsnS08RjN+aUFWIrpLNscHyKwFN2 gTDDbfVBovHUQs8oAleYBUubTVGKuL2RuXDiR21bjFxoN+CT9+fRQn8ZhTNnXvdj xyNAm3bDxfEBa6SN1KSgRz8NcKPoIqmVh4IlyYSR0BdJo4DfqvyDUQo7vbg3cvDS 9obqBz4UIG51FZzI5uikkp+tg9ur3+BCzV1xZfHhOivsr9DH2kbXJFCJ08DbEd0V r9U8Z5bX6cn4gwUGDyIQ =xkNv -END PGP SIGNATURE-
Re: SSL encrypts for recipients only
Quoting Bertram Scharpf li...@bertram-scharpf.de on Fri, Jul 17 00:24: I'm just beginning to understand SSL encryption but so far everything works well. Yet, there's one thing I miss: When given an Fcc field, this recipient (myself) will not be included in the list handed over to openssl. I created a patch for this back in 2002 that adds a quad-option called smime_encrypt_self that enables mutt to encrypt to your default S/MIME key too. Patch is available from http://www.mandarb.com/mutt/, named `patch-1.5.19-ow.smime-encrypt-self.1'. Omen -- A professor is one who talks in someone else's sleep. smime.p7s Description: S/MIME cryptographic signature
Re: split display?
On Fri, Jul 17, 2009 at 09:31:02AM -0500, Derek Martin wrote: Yes, but that doesn't mean that there couldn't be an easier way to do that than there is now. even smaller than 80x25. Mutt tries to accomodate everyone... but on such small terminal screens, there's a limit to what you can do with the UI and maintain some degree of usability. I haven't said anywhere that what mutt currently does should be abandoned. Everyone could still use it the same way they're used to. Mutt optimizes a lot of things for the way the vast majority of people expect to manage their mail, which is the way I outlined. Mostly you were suggesting that I use folders instead of categories. You're complaining a lot about the UI being clunky -- I think you want a GUI mail client, for starters... Sylpheed or GMail might be more to your liking. GUI mailers are mostly awful. It's not what I want. A big part of the problem is that you're apparetnly trying to use Mutt through its file browser interface... this is not how Mutt is intended to be used, and yes, it's clunky: Mutt is not a file manager. No, I was looking for a better way to organize mails. Using more folders to store mail in them isn't a good way for me to do that. You agree that mutt gets clunky when you try to do that. And I don't want to use two different modes. Well, that I can not help you with. Perhaps the mail thread trick is enough for you. It's pretty awesome --- not ideal, but it very much does what I want. But it doesn't matter! Because you just tell mutt about them with the mailboxes command, and the location becomes not interesting. The folder browser prevents you with a flat view of all your mailboxes that you've told Mutt about. You keep insisting that Mutt is clunky and won't do what you want it to, but you haven't even tried to use Mutt the way it's intended to be used. What do you expect? It isn't very flexible to use it that way. Every time you would create a new folder to simulate a category or remove a folder, you would have to edit the config again. Removing folders is not supported, renaming them isn't either. It's awkward, or, as you call it, clunky. So put your folders in your config. This is the way Mutt is intended to be used. You can even do it programatically, by, for example, writing a script to identify maildirs in a particular directory tree, and output mailboxes commands for each one it finds. Moreover, if you stop mixing directories and maildirs, you could even use the file browser... though again, that's not how Mutt is intended to be used, so you're giving up a lot of the power of Mutt if you use it that way. Well, are you now saying that mutt is supposed to be used with only one mail folder? It's not so easy, at least not for me, to write a script that will edit the config to synchronize the mailboxes entries with what is found on disk. I'd write that in C. Mutt should be able to do that by itself. I'm telling it where the top-level directory is, and I'm using mutt to create folders. How am I supposed to organize mail in folders when I can't create a folder hierarchy, inevitably mixing maildirs with folders? Why doesn't mutt show directories as directories, maildirs as maildirs and maildirs with submaildirs as such in the list so that you can tell from the list which is which, without having to switch into a directory first? Because a maildir IS a directory, and it's not possible to reliably determine the difference. You can make an assumption that if a directory has cur/ new/ tmp/ in it, it's a maildir, but that may not be the case. And a directory might have some of those, but not all of them, and be an actual maildir. Or it might not be. And moreover, it's because Mutt expects you to tell it about the mail folders you care about. In so doing, it prevents a lot of tedious guesswork that mutt could get wrong, in determining what your mail folders are. Ok, that makes some sense. Still it could show me what is what after I tell it which folders are a maildir. Since you need to tell mutt which folders are maildirs, why can't you tag directories in the directory list to tell mutt that those are maildirs and have mutt write that into its config? Why doesn't mutt optionally ask you when creating a new maildir if you want to add the new directory to your mailboxes? To prevent piling up empty maildirs, I think three times before creating a new one and preferably don't, and when one is empty, I'm forced to open a shell and to delete it right away because if I don't, I either forget which one to delete or would have to write it down. I only did that when I was cleaning up my mails, and that means that when I need to delete an empty maildir, I'm forced to interrupt what I'm doing and to change to another program to find and delete the maildir. On top of that, since maildirs have subdirectories, you either delete four directories or use rm
Re: split display?
On Fri, Jul 17, 2009 at 12:33:20AM -0700, jacob certain wrote: So, I think I understand what you want: gmail. Yes, it's a web interface, with limited keyboard commands, but the whole basket/basement thing is implemented near exactly as you describe. I think you'd be pretty happy with it, though a specialised version for your own domain costs a bit more than mutt. That's interesting; I never tried gmail. An a webinterface isn't what I want, but it means that I really have to try sup. Then why is it so fumbly? It's fumbly with local maildirs, but try it with IMAP. If you don't enter all the folders you have on the IMAP server into the configuration or something, it's horrible. And every time you create a new IMAP folder or delete one, you'd have to edit the config again ... I've never had any problems. And I don't have to predefine every single folder in a config file, I just tell it what my inbox, draft, and sent folders are. To change folders: c, =foldername, or tab twice for a list. Well, I tried it with IMAP, and mutt kept asking me server and password all the time and didn't display any folder list. I had to use a GUI MUA to see what folders there were to access them with mutt, but it was still so fumbly that I ended up using the GUI MUA to move the mail from the IMAP server into my maildirs. Mutt and IMAP is just something that doesn't really work, at least not before you figured out what to put into the config for that. And, mutt + screen is beautiful. I run several instances of mutt, so I can quickly access my various common folders with a simple ctl-a ctl-[np]. ... and then you create a new folder or remove one or want to change an option and have to exit all instances of mutt, edit the configuration, restart all the instances and try to find where you left them because mutt doesn't remember where you left. That's great. I very rarely used several instances, only when I needed to look up a mail while I was writing one. I wished from the beginning that mutt was able to continue to function while I'm writing a mail in an external editor ...
Re: split display?
On Fri 17, Jul'09 at 2:03 PM -0600, lee wrote: Since you need to tell mutt which folders are maildirs, why can't you tag directories in the directory list to tell mutt that those are maildirs and have mutt write that into its config? Why doesn't mutt optionally ask you when creating a new maildir if you want to add the new directory to your mailboxes? It's easy enough to write a shell/python/perl script to scan your mail directory, ignoring boxes/folders your don't want, and spit out muttrc lines. Then just call that script from your mutt rc and you are good to go. Everytime you restart mutt, it's got all your mailboxes ready to go.
Re: multipart/alternative question
On Fri, Jul 17, 2009 at 01:56:45PM -0500, Kyle Wheeler wrote: In other words, I think the suggestion here is to count attachments from only ONE of the alternatives, not from all of the alternatives, because to count attachments in ALL of the alternatives is equivalent to being show multiple versions of the same data. Hm, I don't think that there is a suggestion about counting attachments. But anyway, you could as well argue that all those versions should be counted which could be displayed. However, all this won't have to do much with counting attachments. Maybe attachment isn't something that should be counted at all because there can be so much disagreement about what an attachment is and under what circumstances it should be counted or not. Of course, this is complicated by the preceeding paragraph: In the case where one of the alternatives is itself of type multipart and contains unrecognized sub-parts, the user agent may choose either to show that alternative, an earlier alternative, or both. It doesn't say what to do if multiple alternatives are of type multipart, and showing both seems to directly contradict what is most critical a mere few sentences later. When sub-parts are unrecognizable, it makes sense to allow showing several alternatives because the MUA may not be able to determine which of the alternatives it should show since it contains parts the MUA cannot recognize. And how does a MUA show unrecognizable parts of a message?
Re: multipart/alternative question
On Fri, Jul 17, 2009 at 02:04:15PM -0500, Kyle Wheeler wrote: Actually, RFC 2046 is more recent, but says nearly the exact same thing. It adds: Systems should recognize that the content of the various parts [of multipart/alternative sections] are interchangeable. Systems should choose the best type based on the local environment and references, in some cases even through user interaction. By Systems, I'm pretty sure they mean recipient systems. That's pretty interesting: The MUA *should* choose the best type based on the local environment and references, in some cases even through user interaction. I find that so interesting because it basically means that the MUA should display a type (a message, or part of a message) in just the way the user would want it. Insofar the user is the recipient, the RFC says To hell with how the sender wanted something to be displayed! Always display it as the recipient wants it to be displayed! If you transcribe this to the counting of attachments, it means that the MUA should count attachments the way the user wants them to be counted.
Re: split display?
On Fri, 17 Jul 2009, lee wrote: On Fri, Jul 17, 2009 at 12:33:20AM -0700, jacob certain wrote: So, I think I understand what you want: gmail. Yes, it's a web interface, with limited keyboard commands, but the whole basket/basement thing is implemented near exactly as you describe. I think you'd be pretty happy with it, though a specialised version for your own domain costs a bit more than mutt. That's interesting; I never tried gmail. An a webinterface isn't what I want, but it means that I really have to try sup. Have you looked at nmh? You could probably use sequences for categories, and it could be bent to your way of working using scripts, quite easily. You may need to use another tool if you use IMAP (I don't know), but otherwise it's very flexible. cheers, Adam ...one cannot be angry when one looks at a penguin. - John Ruskin
Re: multipart/alternative question
On Fri, Jul 17, 2009 at 01:38:04PM -0500, Kyle Wheeler wrote: For example, I often get emails from corporate secretaries that use Outlook and some goofy HTML stationery (complete with background picture, goofy fonts, corporate logo, etc.). Knowing that it's a complex MIME structure isn't a useful piece of information to me. Yeah, you want to know what the message says and if something is attached that you might want to do something with. For that, you don't want/need to care about how a message is made up. But to each his own, I suppose. yeah What is the usefulness of knowing if something is attached to a message that you might want to save to a separate file? It's useful to you, but not really useful to me. Well, the usefulness to me is that occasionally I receive messages that don't make it clear that there IS an attachment in the text. For example, I'll get an email that reads Can you make sure that the schedules are right for next month?. It also has a copy of the schedules attached (probably that's messed up and isn't what had previously been established as the schedules), but that's an easy fact to miss in a text-based email reader (GUI email programs, and webmail, often make such things a bit more obvious). Hm, somehow I've never had that problem. When reading the message, I find out if something is attached. But yes, you're right that for such cases it would be nice if it was more obvious that there is an attachment. Perhaps you can somehow change the color of the status line to white on red or change the color of the message display to white on blue in case a message has a part that is not designated as inline but as attachment. For this, mutt would first have to be able to count attachments exactly the way the user wants them to be counted. How do you want to unload, i. e. would you prefer to unload all the bricks at once by unloading the container (save the whole container to disk with everything in it), or would you rather open the container and unload (save to disk) one brick (file) at a time? See, here's where I think the metaphor becomes a bit strained. I don't know how what you're talking about maps back to email. Well, you could have a message with a container. The container could contain a number of files, JPEGs for example --- maybe portraits of your relatives. You could have a choice: Do you want to go to every file in the list and save one after another, or would you rather go to the container and save the whole container with all the files in it at once (as a new directory containing all the JPEGs). That, I think, pretty much restates what I was saying. In particular, mutt observes and respects the two disposition types outlined in that RFC: Now I see what you mean. Well, you're right when you say that not every attachment is an attachment. 2.1 The Inline Disposition Type 2.2 The Attachment Disposition Type For the umpteenth time, no, not all MIME entities are attachments. To me, they are. Well, then I think it's safe to say that you have a rather unusual view of MIME entities that is not shared by (at least some of) the designers of the MIME standard. Sort of ... When I started using email, there weren't any attachments or inlines. If you wanted to send someone something that didn't contain only ASCII characters (and a few others) --- i. e. a file --- you would use an uuencoder to convert the file into characters you could send in a mail. The recipient would save the mail and eventually have to edit it to remove header lines and use an uudecoder to convert the message back into a file. And that was all there was; base64 came some time later but didn't work as well for that. Since different users would use different uuencoders and uudecoders, recipients were not always able to decode a message, or senders were not always able to encode a message so that the recipient could decode it. At some time, all this mime crap (that's how I still think of it) was invented. It's very useful for the purpose of sending files because it makes that easier and more reliable. What they did was basically changing the encoding from uucode to base64 and moving the file from the body of the mail to the end of the mail, i. e. they made it an attachment instead of putting it into the mail. You were able to do the same with uucode if you got a good en-/decoder, and you would even see that the uucode is in the message. To me, sending files is pretty much the only thing the mime stuff is good for and the only thing it should be used for, with the exception of using it for encryption (I used that before there was mime, too, and mime only made it easier ...). I don't want and don't need mails written in HTML or MS Word or something. That really isn't needed, and I don't like it. Mails are plain text. (I'm aware it's not that easy when different languages come into play ...) In the extremely rare case that plain text
Re: storing tagged state?
On Fri, Jul 17, 2009 at 01:53:18AM -0500, Kyle Wheeler wrote: On Thursday, July 16 at 11:52 PM, quoth lee: is it possible to store which messages are currently tagged, to do something and then to restore the previous tags? Sure, it's possible. Not *easy*, but possible. The way I'd suggest is to have your macro pipe all tagged messages to a script that saves their message-id headers... That'll save off all the message ID's. Then you can clear the tags and do your macro work. Next, you need to restore the tags... all you need to do is source the temporary file you created. Thanks, that would work! Not easy, though ... :)
Re: split display?
On Fri, Jul 17, 2009 at 04:18:28PM -0400, Tim Gray wrote: It's easy enough to write a shell/python/perl script to scan your mail directory, ignoring boxes/folders your don't want, and spit out muttrc lines. Then just call that script from your mutt rc and you are good to go. Everytime you restart mutt, it's got all your mailboxes ready to go. Maybe it's easy for you, but it won't be easy for me. I'd have to learn python or perl first or try to figure out how to write a shell script to do that. Like I said, I could do it in C (which isn't the ideal choice for that). In any case, it would take quite some time to do it. That's not what I would call easy enough.
Re: multipart/alternative question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Friday, July 17 at 03:58 PM, quoth lee: Hm, somehow I've never had that problem. When reading the message, I find out if something is attached. You're lucky! These days, I usually use the size as an indicator. A message that's 10K or so is probably text; but 100K or more probably means I need to have a look at its innards (at least that's ONE benefit to MSOffice's giant files). But every now and then, I still manage to miss an attached file (either because I didn't look, or because it was surprisingly small). For this, mutt would first have to be able to count attachments exactly the way the user wants them to be counted. Quite. Well, you could have a message with a container. The container could contain a number of files, JPEGs for example --- maybe portraits of your relatives. You could have a choice: Do you want to go to every file in the list and save one after another, or would you rather go to the container and save the whole container with all the files in it at once (as a new directory containing all the JPEGs). Hmm, well, I guess I see your point, but not even mutt supports batch-decoding like that. Do you perhaps have a perl script of some kind that you use to bulk-decode like that? At some time, all this mime crap (that's how I still think of it) was invented. HEH - way to make me feel old. The first MIME RFC was written in 1993, back when I was barely a teenager and was just about to discover the wonders of HyperCard. (My First Internet (tm) was AOL.) But I see what you mean about your definition of an attachment... though by that logic, a message is essentially defined by its headers (From/To/Subject/etc.) rather than its content. And isn't it outright amazing that the mime guys, in a way, massively failed in clearly defining what an attachment is and what not? Yes and no. I think a lot of those sorts of oversights tend to be the result of assumptions, influenced by popular software abstractions. For example, it's easy to assume that an attachment is anything the user explicitly attached (by clicking the attach button) and that any behind-the-scenes encoding nonsense doesn't count IF (and only if) you typically operate at a level where that stuff is handled transparently such that you never see it. If, on the other hand, you usually read mail with `more` (or `mail` or something else that usually shows raw email content), and you tend to *see* the MIME encoding, then its easier to think of that as attached to the plain text message. As I understand it, this means that a Message is generally a series of text lines similar to that defined in RFC 822 but that may also be divided into one or more sub-parts that are encoded according to the MIME standard (RFC 2045). As such, a message can contain another message, as long as the contained message is encapsulated within a MIME entity/component of the other. Thus, since a MIME entity can encapsulate another message, the entity's body may be a full-blown message in and of itself. Why don't they just say that? But what is an entity? Ehrm... it's defined in section 2.4: The term entity, refers specifically to the MIME-defined header fields and contents of either a message or one of the parts in the body of a multipart entity. The specification of such entities is the essence of MIME. Since the contents of an entity are often called the body, it makes sense to speak about the body of an entity. Any sort of field may be present in the header of an entity, but only those fields whose names begin with content- actually have any MIME-related meaning. Note that this does NOT imply that they have no meaning at all -- an entity that is also a message has non-MIME header fields whose meanings are defined by RFC 822. So... it sounds like, because it's English, words got re-used and redefined into confusion. As I understand it, an entity is essentially anything between a pair of MIME delimiters. Entities have a two-part format based on RFC 822 messages: a header section and a the rest of it section. This latter section is referred to in RFC 822 as the body, thus dooming us to talk about the entity's header and an entity's body. On top of that, since beginning of data and end of data count as MIME delimiters, an original RFC 822 message can be thought of (and often is) as a MIME entity, particularly since they usually include MIME information in their header sections. When a MIME entity is a container for other entities, those sub-entities are contained within the body of their parent. The parent entity's body is segmented by MIME delimiters, and the sub-entities are always contiguous segments of that body, and can therefore be logically referred to as body parts. Of course, body part is an unfortunate piece of what amounts to slang (perhaps jargon is a better term)
Re: split display?
On Fri, Jul 17, 2009 at 13:14, leel...@yun.yagibdah.de wrote: On Fri, Jul 17, 2009 at 12:33:20AM -0700, jacob certain wrote: So, I think I understand what you want: gmail. Yes, it's a web interface, with limited keyboard commands, but the whole basket/basement thing is implemented near exactly as you describe. I think you'd be pretty happy with it, though a specialised version for your own domain costs a bit more than mutt. That's interesting; I never tried gmail. An a webinterface isn't what I want, but it means that I really have to try sup. You should sign up just to see what it's like. Mutt is definitely not intended to be used the way you want to use it. You should definitely look into sup. I don't think you'll completely like it, but I think it does more of what you want than mutt. Then why is it so fumbly? It's fumbly with local maildirs, but try it with IMAP. If you don't enter all the folders you have on the IMAP server into the configuration or something, it's horrible. And every time you create a new IMAP folder or delete one, you'd have to edit the config again ... No, that's wrong. Like I said, I've only defined my inbox, sent, and draft folders. I have at least twenty other folders made mandatory by the it department/exchange, plus several of my own folders that I regularly use. I copy/save/read mail in all of these without problem, and without specifically defining them. Granted, mutt still isn't exactly the interface you want with folders in the same view as messages, so yes, you do have to press c tab tab and select, or c =name-of-folder. Well, I tried it with IMAP, and mutt kept asking me server and password all the time and didn't display any folder list. I believe it should only prompt you for your password once. I, however, am too lazy for even that and keep my password in my muttrc. And, mutt + screen is beautiful. I run several instances of mutt, so I can quickly access my various common folders with a simple ctl-a ctl-[np]. ... and then you create a new folder or remove one or want to change an option and have to exit all instances of mutt, edit the configuration, restart all the instances and try to find where you left them because mutt doesn't remember where you left. That's great. I haven't had this problem using imap. There aren't any local folders for me to muck with, and all instances of mutt happily update themselves without conflicting with each other. I regularly keep instances open for my inbox, sent items, and archive folder for quick and easy searching. I very rarely used several instances, only when I needed to look up a mail while I was writing one. I wished from the beginning that mutt was able to continue to function while I'm writing a mail in an external editor ... Yep, mutt just isn't designed to be a multi-paned app. You should write one. Maybe you'd only need an ncurses type wrapper for mutt, with an added bit of code for your categories. I think it'd be handy. But, I am not a programmer, and so I'm content with Mutt. Way better than Outlook or Thunderbird for plain old email. jake
Re: split display?
On Fri, Jul 17, 2009 at 09:51:41PM +0100, Adam Wellings wrote: Have you looked at nmh? Thanks! Long ago I looked at mh ... I just installed nmh and found it apparently doesn't support maildir. Supporting maildir is a requirement.
