Re: split display?
On Fri, Jul 17, 2009 at 06:08:09PM -0700, jacob certain wrote: On Fri, Jul 17, 2009 at 13:14, leel...@yun.yagibdah.de wrote: 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. Maybe --- I found out that there's a Debian package sup-mail. I installed it and started trying it out, but the idea behind it seems to be the opposite of I was looking for. As I suspected, they have abandoned the idea of organizing mail, and you don't have any folders other than one (the inbox). Unfortunately, it's buggy, so it's difficult to try it out. Even if I should not like it, the good thing is that it leaves all the mail where it is and doesn't mess around with your mail storage. 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. Not my experience --- afair mutt asked me for the server and for the username and for the password every time I wanted to change to another folder, and it didn't list any folders. It really sucks when you have to retype the whole login over and over again and can't even see what's on the server. 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. Like I said, you can probably get it to work when you edit the configuration long enough. But I wanted to use it only to move the mail from the IMAP server to my local storage --- an easy task that shouldn't take more than a few minutes, one would think, but it turned out to be impossible. 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. Mutt automatically updates its configuration after you edited it? There can be other things than folders you may want to change in the configuration. And why do you need to run several instances of mutt when it's no problem to access IMAP folders? You could run only one and change folders when needed. 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. It would take a long time to do that. I thought about it long ago, but decided not to try. Afair at that time, I was thinking that it's probably too difficult --- I wouldn't be afraid about that now, but I don't have the time. 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. A long time ago, I took a look at the source code of mutt. It seemed to be very difficult to figure it out. But it would probably still be much easier than writing a new MUA from scratch. There's actually a patch that shows folders in the side panel so that you can see if there are new messages. I tried it long ago and didn't find it useful. Perhaps I should try it out again. Way better than Outlook or Thunderbird for plain old email. Indeed! I found the email client that was built into Mozilla pretty good. It worked even very well with IMAP after they managed to make it fast enough. I wonder what happened to that ... Not that I would use it when I can use mutt and emacs, but I'm missing the full-featured Mozilla that had the email client and an IRC client. I tried Thunderbird and it somehow sucks. Nowadays you need to have and to use several different web browsers just to display websites because a website that one browser can't display can be viewed with the other one, and the other way round. Why can't they make a decent web browser anymore that doesn't eat 2GB RAM and still struggles with displaying web pages? Outlook is a groupware client that has some sort of half-working email support, but not a MUA ...
Re: split display?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Saturday, July 18 at 02:12 AM, quoth lee: select, or c =name-of-folder. Not my experience --- afair mutt asked me for the server and for the username and for the password every time I wanted to change to another folder, and it didn't list any folders. It really sucks when you have to retype the whole login over and over again and can't even see what's on the server. Why couldn't you use the '=' shortcut in folder names... did you not set $folder to something useful? For example, I set $folder=imaps://k...@imap.memoryhole.net/ and then I can simply go to =INBOX or =Family, and mutt will substitute the full path for the equals sign. Mutt automatically updates its configuration after you edited it? No. You can tell mutt to re-read its configuration, though, without quitting. Like this: :source ~/.muttrc ~Kyle - -- The means of defense against foreign danger historically have become the instruments of tyranny at home. -- James Madison -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJKYYooAAoJECuveozR/AWep0MQAKry58J5l15637cfpuFzuPr4 2tjmtScac9RRuWPsMYvwXw9kFzM2IAo3AKtJxe1H4Jzr+3i7hdtz0d/Lxl91NGVW 0817tR6OaEGu/NcKHBHOQAcDfnGQtU7cfakpcq0PdknENjTAmEtk/EAuW01I9b/z NWIEKD4aH+bPaALe3HZQjyY7fuuoz9b8U0UkiCP7fbFRa2QWbiyv60T+ILvaPaKr L5jVekNs3aNag3qu5HGO5t9Y9LMQknNyM59/mqrAkA7XtqLyKrANZS33q/ziPYaJ 995GlaOEh23u+BG5Wh71lS+sglsV4w0P/KGkSV3R2rpYYSh8jGaIqrj0SVDSR81B B5AkRIPg2EbJBj558N1WLJjiVzWUv/Zb4vR6/ikiJiAmBWIWn6BhfBYor6Exrp22 81YbMUCI3wUVI1RU7fU8TU0sybxfRiQd7UN2+Y2nVZncFtTcE6v9f35MvHGobtwW 4pD5du83ITdIikLkJS1EgAlX58lKLiIJIJT6QTBiXw1sPz6SvlOGa5jZOsPnit+i jd20BEX0j+cHlcrvxQO04nkKF8BMHP/y36rx5vpPbDAxkMphUn8I+yPOaU/AWSIt oiCFqWZ8FjM4z8RxNWyAEF70nNOzeztkT6Bp6kShWkV4B/Arz7AVZEYEbYGWQEsh BS813KhTX94EEHxDRxrC =gBCs -END PGP SIGNATURE-
Re: use current folder name as argument to abitrary command
On 2009-07-17, Rocco Rutte pd...@gmx.net wrote: 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? No, that was probably 12-13 years ago, and I've lost track of the patch. We have a shortcut for the current folder already, which is a mess to use in hooks. I think of read-only variables. -- Grant
Re: split display?
On 2009-07-18_03:39:05, Kyle Wheeler wrote: On Saturday, July 18 at 02:12 AM, quoth lee: select, or c =name-of-folder. Not my experience --- afair mutt asked me for the server and for the username and for the password every time I wanted to change to another folder, and it didn't list any folders. It really sucks when you have to retype the whole login over and over again and can't even see what's on the server. Why couldn't you use the '=' shortcut in folder names... did you not set $folder to something useful? For example, I set $folder=imaps://k...@imap.memoryhole.net/ and then I can simply go to =INBOX or =Family, and mutt will substitute the full path for the equals sign. Mutt automatically updates its configuration after you edited it? No. You can tell mutt to re-read its configuration, though, without quitting. Like this: :source ~/.muttrc I have an idea that might be useful, but I haven't been following really closely, please excuse the possible noise The thread code arranges the display based on some field/information that correllates sub-sets of email. I don't know what it is, but if the place where it looks to decide whether or not to include a partcular email in a thread were a setable option, like $folder - would that met OP's needs? Of course threading, as implemented now, assumes that the grouping is a rooted tree, which is actually more complicated than a simple grouping. -- Paul E Condon pecon...@mesanetworks.net
Re: multipart/alternative question
On Fri, Jul 17, 2009 at 10:21:29AM -0600, lee wrote: 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? To the best of my knowledge, it isn't defined anywhere. But that doesn't matter. The common understanding of an attachment is that it is a file, with a filename, that has been sent as a separate item from the message. 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 ... This is NOT a typical use case. 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 authors of the MUA. To me, it has clearly three attachments. It doesn't matter if a user is likely to save an attachment or not. And you should be free to configure your MUA to display those as attachments, but the way you think about message parts is uncommon, and would be confusing for the average user. Best, -- Noah Slater, http://tumbolia.org/nslater
Re: multipart/alternative question
On Fri, Jul 17, 2009 at 06:28:35PM -0500, Kyle Wheeler wrote: 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! Yay! ;) 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). That's because mutt doesn't count the attachments right and doesn't make it very obvious that they are there. Not making it obvious has advantages in that you don't need to worry about them when viewing a message. But in your case, it's not so good because it leads you to miss attachments ... If I got such mails, I might miss them as well. Well, you could have a message with a container. The container could contain a number of files, 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? Unfortunately not; but I haven't needed one yet. Saving whole containers is merely a possibility that comes to mind when considering attachments as containers that contain something. That's something I didn't do before. Once you do, it's evident that a MUA could have a way to save a whole container like that. Perhaps we should make a feature request? I'm not sure how useful that would be, but I can imagine that there are ways of explicitly using it. In case you want to send someone several files, you (or the MUA) could make a container to contain them. The recipient could save the whole container instead of having to save all the files separately. If you want to go a step further, you could invent a way of specifying something that should be done after saving the files, similar to Debian packages specifying what to do to configure the software that is in the package ... Like someone could attach a folder with files in it, the MUA would attach them as/in a container, and the sender would specify that make should be run after saving the files and then program that's compiled because he's sending you the new version of the program. That's a dangerous feature, so the MUA would have to ask to user before doing something ... Speaking of which, I sometimes wished that I could just attach a whole folder instead of having to attach all the files separately. Moott, that was when I wanted to send several pictures to someone. I would resize them and convert them to JPEG and collect them in a folder, and when I had all the pictures gathered, I naturally wanted to tell mutt to send the folder --- but that doesn't work. Since pictures can be large, the user should be able to specify a size limit after attaching a folder (or large files) to a message, and the MUA should automatically split the thing up as needed. These mime guys did only part of the job --- or maybe it's the MUA developers. I used to split up files when the message size limit was 64k and had scripts for sending them and splitting them up automatically. The limits aren't that tight anymore, but the files are also larger. Try sending someone 5 or 10 TIFFs as they come out of your camera --- you may find that you can't even send one because he's got a mailbox limit of 5MB or a size limit of 20MB and one TIFF is about 18MB ... So where's the full MUA support of the mime stuff? At some time, all this mime crap (that's how I still think of it) was invented. HEH - way to make me feel old. Well, how should I feel? ;) 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.) You started early then. In 1993, only a few people had even heard about internet --- it was something very expensive that only a few institutions like universities could/would afford. At that time, I had news and mail, but no internet ... 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. *The headers are content.* The headers are the substantial part of the message. What content the headers or other parts of a message have doesn't define what a message is. The definition is formal and doesn't concern the contents. You can send something via SMTP that doesn't have headers and a body because the MTA doesn't care about the content. That's why the SMTP protocol knows such things as envelope sender and envelope recipient. What you put into the headers as From: and To: can be different from what's in the envelope. For example: l...@cat:~/Mail$ telnet localhost smtp Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 cat.rubenette.is-a-geek.com ESMTP Exim 4.69 Sat, 18 Jul 2009 12:37:07 -0600 helo cat.rubenette.is-a-geek.com 250 cat.rubenette.is-a-geek.com Hello localhost [127.0.0.1] MAIL FROM: l...@yun.yagibdah.de 250 OK
Re: split display?
On Sat, Jul 18, 2009 at 03:39:05AM -0500, Kyle Wheeler wrote: On Saturday, July 18 at 02:12 AM, quoth lee: Not my experience --- afair mutt asked me for the server and for the username and for the password every time I wanted to change to another folder, and it didn't list any folders. It really sucks when you have to retype the whole login over and over again and can't even see what's on the server. Why couldn't you use the '=' shortcut in folder names... did you not set $folder to something useful? I don't think I did because I was using it only temporarily and didn't think of it --- and that's what I was saying, you have to adjust the configuration to get it to work with IMAP. You might not even know that you have to. Mutt automatically updates its configuration after you edited it? No. You can tell mutt to re-read its configuration, though, without quitting. Like this: :source ~/.muttrc Cool :)
Re: split display?
On Sat, Jul 18, 2009 at 09:15:27AM -0600, Paul E Condon wrote: The thread code arranges the display based on some field/information that correllates sub-sets of email. I don't know what it is, but if the place where it looks to decide whether or not to include a partcular email in a thread were a setable option, like $folder - would that met OP's needs? That is interesting, but if I understand it right, it assumes working with threads, and the content of $folder would need to change during displaying the message list to include so many different folders. Then what about the messages in a folder that aren't (or are) part of a thread? You still have what is used now to correlate messages, so you would have to add another information by which messages are correlated (i. e. $folder). If that could be done, you might end up with a display similar to what sup has: Display all messages in the same list from all sources the user has defined (like $folder), no matter where they are unless they are archived (i. e. read) or otherwise excluded from display (SPAM, killed thread, display limited to messages matching a search pattern, ...). Now that would be an interesting feature! However, it would (allow to) abandon the idea of organizing mail altogether, as sup does. I'm not sure yet how to deal with that, it might be possible. The only thing that sup seems to have for organizing mail is using labels. They aren't viewed as that but as a means to help finding messages. Having that option in mutt might be awesome ...
Re: multipart/alternative question
On Sat, Jul 18, 2009 at 09:20:49PM +0100, Noah Slater wrote: On Fri, Jul 17, 2009 at 10:21:29AM -0600, 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? To the best of my knowledge, it isn't defined anywhere. But that doesn't matter. The common understanding of an attachment is that it is a file, with a filename, that has been sent as a separate item from the message. Well, then most people have a wrong understanding. 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 ... This is NOT a typical use case. Why not? Mutt does it, sup does it. When I have a mail with an html part and want to view that, I can press ENTER on it and mutt and sup will start galeon (Yuck! I need to change that.) to display it. I haven't verified, but I'm pretty sure that the MUA saves the html part as a file so that a web browser can load the file to display it. The MUAs probably do the same with other parts of a mail, unless they can display the part themselves. Since they can display plain text, they're not saving it, but if they couldn't display plain text, wouldn't they handle it the same way they handle parts they can't display themselves? 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 authors of the MUA. The RFC leaves it up to the user how he wants to display a (part of a) message. And since each user has preferences, it's not up to the authors of the MUA to force the user to display a message in a particular way or to decide what the user would consider as an attachment. To me, it has clearly three attachments. It doesn't matter if a user is likely to save an attachment or not. And you should be free to configure your MUA to display those as attachments, but the way you think about message parts is uncommon, and would be confusing for the average user. Yeah, I configured mutt to count all attachments, but mutt doesn't do that. It doesn't go into some containers. Don't get me wrong: Reasonable defaults are fine and should be there, and since its up to each user, it doesn't matter what you or I or most users consider as an attachment. As you say, each user should be free to configure his MUA the way he wants.
Re: multipart/alternative question
On Sat, Jul 18, 2009 at 03:37:32PM -0600, lee wrote: To the best of my knowledge, it isn't defined anywhere. But that doesn't matter. The common understanding of an attachment is that it is a file, with a filename, that has been sent as a separate item from the message. Well, then most people have a wrong understanding. This is an absurdly prescriptivist statement. 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 ... This is NOT a typical use case. Why not? Mutt does it, sup does it. Sure, many MUAs will let you do it, but it's not a typical use case. As in, if you did a survey of all the people on the planet, and asked them if they had ever saved the HTML component of a simple email message, I am willing to bet the number would be under 1%. The authors of the MUA. The RFC leaves it up to the user how he wants to display a (part of a) message. And since each user has preferences, it's not up to the authors of the MUA to force the user to display a message in a particular way or to decide what the user would consider as an attachment. I never said force. I'm only talking about sane defaults. And you should be free to configure your MUA to display those as attachments, but the way you think about message parts is uncommon, and would be confusing for the average user. Yeah, I configured mutt to count all attachments, but mutt doesn't do that. It doesn't go into some containers. Don't get me wrong: Reasonable defaults are fine and should be there, and since its up to each user, it doesn't matter what you or I or most users consider as an attachment. As you say, each user should be free to configure his MUA the way he wants. Agreed. Best, -- Noah Slater, http://tumbolia.org/nslater
Re: multipart/alternative question
On Sat, Jul 18, 2009 at 10:51:05PM +0100, Noah Slater wrote: On Sat, Jul 18, 2009 at 03:37:32PM -0600, lee wrote: To the best of my knowledge, it isn't defined anywhere. But that doesn't matter. The common understanding of an attachment is that it is a file, with a filename, that has been sent as a separate item from the message. Well, then most people have a wrong understanding. This is an absurdly prescriptivist statement. I'm not sure what prescriptivist means. See Message-ID: 20090718204148.ga8...@cat.rubenette.is-a-geek.com, there's an explanation why I could maintain saying that. As in, if you did a survey of all the people on the planet, and asked them if they had ever saved the HTML component of a simple email message, I am willing to bet the number would be under 1%. A simple email message doesn't have any HTML components. You probably wouldn't get any valid results from such a survey because the percentage of people who wouldn't know what you're talking about would be too high.
Re: multipart/alternative question
On Sat, Jul 18, 2009 at 09:37:04PM -0600, lee wrote: On Sat, Jul 18, 2009 at 10:51:05PM +0100, Noah Slater wrote: On Sat, Jul 18, 2009 at 03:37:32PM -0600, lee wrote: To the best of my knowledge, it isn't defined anywhere. But that doesn't matter. The common understanding of an attachment is that it is a file, with a filename, that has been sent as a separate item from the message. Well, then most people have a wrong understanding. This is an absurdly prescriptivist statement. I'm not sure what prescriptivist means. Compare the following topics: http://en.wikipedia.org/wiki/Descriptive_linguistics http://en.wikipedia.org/wiki/Linguistic_prescription In other words, if most people think attachment means X then, by definition, attachment means X - regardless of your personal preference for what it should mean. This is how language works. As in, if you did a survey of all the people on the planet, and asked them if they had ever saved the HTML component of a simple email message, I am willing to bet the number would be under 1%. A simple email message doesn't have any HTML components. That depends on what you mean by simple - and you have already demonstrated that your definitions are unusual. That is not meant to be offensive, because I can see where you're coming from. Nevertheless. You probably wouldn't get any valid results from such a survey because the percentage of people who wouldn't know what you're talking about would be too high. I think that would probably support my thesis. Heh. Best, -- Noah Slater, http://tumbolia.org/nslater
Re: multipart/alternative question
On Sat, Jul 18, 2009 at 09:37:04PM -0600, lee wrote: I'm not sure what prescriptivist means. See Message-ID: 20090718204148.ga8...@cat.rubenette.is-a-geek.com, there's an explanation why I could maintain saying that. Sorry, you might have that. Here's the References: header (which you probably have): References: 20090716055919.ga6...@cat.rubenette.is-a-geek.com 20090716141914.gc4...@atakapa.local 20090717021854.ga7...@cat.rubenette.is-a-geek.com 20090717030916.gn4...@atakapa.local 20090717042711.gf7...@cat.rubenette.is-a-geek.com 20090717053919.gp4...@atakapa.local 20090717173748.gd14...@cat.rubenette.is-a-geek.com 20090717183804.gt4...@atakapa.local 20090717215821.gf1...@cat.rubenette.is-a-geek.com 20090717232835.gw4...@atakapa.local
