Re: How to disable mailbox shortcuts in mailbox browser
On 2022-06-03 05:48 +, Sam Lee via Mutt-users wrote: > In the sidebar, my mailbox is displayed in a format like > "imaps://john-...@example.com/INBOX". However, in the mailbox browser > (accessed using keybinding 'y' or :exec browse-mailboxes), it is > displayed as "=INBOX". In the mailbox browser, how do I make Mutt > display it as "imaps://john-...@example.com/INBOX" instead? > > Is there some kind of setting similar to > "set sidebar_use_mailbox_shortcuts=no", but for the mailbox browser? OP here. By the way, I am aware of that I can explicitly give labels to each mailbox by using mailboxes' "-label" argument. However, I am using "set imap_check_subscribed" instead of explicitly listing each mailbox in the configuration file, so the "-label" method is not practical (especially with multiple email accounts, each with many folders, some of which I may change/rename through the email provider's web interface).
How to disable mailbox shortcuts in mailbox browser
In the sidebar, my mailbox is displayed in a format like "imaps://john-...@example.com/INBOX". However, in the mailbox browser (accessed using keybinding 'y' or :exec browse-mailboxes), it is displayed as "=INBOX". In the mailbox browser, how do I make Mutt display it as "imaps://john-...@example.com/INBOX" instead? Is there some kind of setting similar to "set sidebar_use_mailbox_shortcuts=no", but for the mailbox browser?
How to stop Mutt from prompting for Subject
When I want to compose a new email, Mutt will prompt for the recipients
("To:"), followed by the subject ("Subject:"). How do I disable the
prompting for the subject? The `autoedit` configuration option will not
help here because it disables both prompts (i.e. both "To:" and
"Subject:"). I only want to disable the "Subject:" prompt. How can I do
this in Mutt?
How to warn before sending email if "Subject:" is empty
Is it possible to make Mutt warn about an empty "Subject:" right before sending the email? The `abort_nosubject` configuration variable is not relevant here because `abort_nosubject` is only for configuring what happens when there is no subject given at the subject prompt. I am looking for something similar to `abort_noattach`'s "No attachments, cancel sending?" warning that appears right before email is sent. Is there something similar for warning about an empty "Subject:"?
NeoMutt Opinions
I was wondering if anyone has an opinion on the neomutt project. I've been a long time mutt user, on and off for 15 years. Neomutt seems to be popular with a certain set of users these days. The configs seem pretty much compatible. I haven't seen any features that aren't in mutt, and it's sole virtue seems to be a more colorful site page. Lee
Timeout surpassed, mailbox closed on sync
Greetings. This is my first post on the list, and I'm new to Mutt. I've searched the mailing list, and didn't see anything quite like this. Maybe someone can tell what's happening. I'm running MUTT 1.5.23 on OpenBSD 5.8. The only patch is the trash folder patch. I have Mutt set up to work with an IMAP account. It's able to log in, read, send, save, and make folders properly. There seems to be some trouble with the sync operation when it moves messages to the Trash folder. When I sync, either after pressing '$' or on quit or mailbox change, Mutt will ask if I want to expunge deleted messages. I type 'y', and it begins uploading messages (presumably moving them to my Trash folder). Then, it gets stuck around 95% or 98% on one of the transfers. Next, it will tell me "Timeout suprassed", and after another minute or so, my message index is gone, and the status line shows (no mailbox), indicating that I'm no longer in the mailbox I was in. Then when I go back to the mailbox, the messages haven't been expunged. When I don't set my trash folder, everything works fine (but of course I lose the security of a trash folder). Any good ideas on this one? All my timeout variables are default values (timeout=600, connect_timeout=30, smime_timeout=300). Note: my mail server apparently requires that imap_pipeline_depth is set to 0. That's the only "weird" thing I think I have going on. Sincerely, Nathan
Multi-boot and Mutt
I used Mutt for several years when I first became a Linux user in 1999, and am considering returning to it if it gives me a shot at an objective I've been trying to achieve. For a variety of reasons, none of which are germane to this topic, I have arranged for my primary work computer (a Macbook Pro) to triple-boot into Mac OS X (Lion), Windows 7, and Linux (Ubuntu 12.04). I want to be able to both read new mail and all my archived email from any of those OSes, since I need to communicate whatever environment I happen to be working in at the moment. I tried to make Thunderbird do that, since it seems to allow for such behavior, but there were constant issues with file permissions and data reliability. It occurred to me recently that Mutt might be the answer. So here are the questions I can think of: 1. I don't expect this to be easy--but is there some reason it's just plain impossible? 2. Is it possible to write a single .muttrc that I can copy to the three home directories that can determine the folder path based on the current OS? That is, the common mail folder is called /Volumes/Common/Mail in OS X, D:/Common/Mail in Windows, and /Common/Mail in Linux. Or do I just have to have three separate .muttrc files and manually coordinate them? (I've never actually used the Windows version of Mutt, so I'm guessing at the path format.) 3. Does anyone have any advice for someone whose Mutt skills are rusty at best? -- Daryl Lee If logic tells you that life is a meaningless accident, don't give up on life. Give up on logic. -- Shira Milgrom
Re: wiki macro page expansion (was Re: The wiki lies about macros and tags.)
If no-one comments further, I'm going to see if I have perms to change the wiki page with this tutorial. -Robin On Thu, Jul 19, 2012 at 12:58:34PM -0700, Robin Lee Powell wrote: On Thu, Jul 19, 2012 at 10:55:07AM -0700, Robin Lee Powell wrote: On Thu, Jul 19, 2012 at 10:48:03AM -0700, Robin Lee Powell wrote: On Thu, Jul 19, 2012 at 12:44:31PM -0500, David Champion wrote: * On 19 Jul 2012, Robin Lee Powell wrote: The section about tags in http://wiki.mutt.org/?MuttGuide/Macros is flat-out wrong in 1.5.21 and 1.5.20, as far as I can tell, and In what way, specifically? The statements appear to be correct and there are no functional examples (only illustrative ones), so it's hard to infer what's incorrect. If you define a macro to work with a single entry, then it can not be applied to tagged entries just by using tag-prefixmacro-key!!! is flat-out false in every version of mutt I have access to. This means that the entire section Special usage: applying to several tagged entries is both false and useless. Based on that statement, given the following macro: macro index ,t tag-entry I would expect the following sequence of characters to error out: ttt;,t But in fact it works perfectly. It just occured to me that it may be that it is intended to mean that given: macro index ,t tag-entry this won't work: macro index ,x tag-prefix,t But in fact that is also false; all 4 of the following work exactly as you'd expect: macro index ,t t macro index ,T tag-entry macro index ,x tag-prefix,t macro index ,X tag-prefix,T at least in 1.5.21, where I just tested them. And now I think I understand what it's *actually* trying to say. I took: If you define a macro to work with a single entry, then it can not be applied to tagged entries just by using tag-prefixmacro-key!!! to mean that *no* macros *ever* work with tags unless set to do so explicitely, but it means that *some* macros will do unpexpected things. I'm going to suggest some wording here that I'd like to put in that section of the wiki, and y'all can tell me if it's halfway decent. Tags, Advancement, And Other Macro Surprises All macros devolve in the end, essentially, to a sequence of keystrokes sent to mutt. This means that working with tagged messages in macros can be tricky, at least unless you have auto_tag turned on, because if you simply hit the tag-prefix key (default ;) before the macro, the tag-prefix key will only apply to the first action. If your macro does more than one thing, each seperate thing that it does must be tag-prefixed seperately. Here's an example; this (totally useless) macro: macro index ,g 'pipe-entrywc -lenterdelete-message' useless: count lines, throw away the count, and then delete pipes a message to a shell command and then deletes it. If, however, you use tab-prefix first (i.e. ;,g), it doesn't pipe each message to the shell and then delete them, it pipes them all to the shell and then deletes the one under the cursor. In other words, assuming default bindings and using enter to stand in for hitting the enter key, the keystrokes: |wc -lenterd become: ;|wc -lenterd which pipes all the messages but only deletes one message (and not any of the ones you had tagged, probably, but rather the one under the cursor!) and not: ;|wc -lenter;d which pipes and deletes all of them, as you might expect. A slightly tricky bit there is that pipe-entry asks for user input, which you might not want in a macro; this can be handled by temporarily disabling that behaviour and then (assuming you want it on) turning it back on, like so: macro index ,G 'enter-commandset wait_key=noenterpipe-entrywc -lenterdelete-messageenter-commandset wait_key=noenter' useless: count lines, don't wait, throw away the count, and then delete The wait_key bit is to stop it from explicitely asking you to press enter. This behaves even worse with tag-prefix, because what you end up with is: ;:set wait_key=noenter|wc -lenterd:set wait_key=yesenter Which is a problem because as soon as you type the :, the prefix-ness just gets completely lost; you might as well have not even typed ;. For some macros, there's no problem; this macro will work just fine with tag-prefix: macro index ,s 'save-message=spamenter' Dump to spam folder Because it only performs one action, with tag prefix this turns into: ;s=spamenter which works perfectly. If you do need a macro that performs multiple actions, though, what you'll need to do is have a version that expects no tags, and a versian that accepts tags. [INSERT CURRENT CONTENTS OF Special usage: applying to several tagged
The wiki lies about macros and tags.
The section about tags in http://wiki.mutt.org/?MuttGuide/Macros is flat-out wrong in 1.5.21 and 1.5.20, as far as I can tell, and should be entirely removed or cordoned off. I tried, and I cannot replicate the old behaviour at all. Does anyone know when this behaviour changed? -Robin -- http://singinst.org/ : Our last, best hope for a fantastic future. .i ko na cpedu lo nu stidi vau loi jbopre .i danfu lu na go'i li'u .e lu go'i li'u .i ji'a go'i lu na'e go'i li'u .e lu go'i na'i li'u .e lu no'e go'i li'u .e lu to'e go'i li'u .e lu lo mamta be do cu sofybakni li'u
Re: The wiki lies about macros and tags.
On Thu, Jul 19, 2012 at 10:30:42AM -0700, Robin Lee Powell wrote: The section about tags in http://wiki.mutt.org/?MuttGuide/Macros is flat-out wrong in 1.5.21 and 1.5.20, as far as I can tell, and should be entirely removed or cordoned off. 1.5.18, too. -Robin
Re: The wiki lies about macros and tags.
On Thu, Jul 19, 2012 at 12:44:31PM -0500, David Champion wrote: * On 19 Jul 2012, Robin Lee Powell wrote: The section about tags in http://wiki.mutt.org/?MuttGuide/Macros is flat-out wrong in 1.5.21 and 1.5.20, as far as I can tell, and In what way, specifically? The statements appear to be correct and there are no functional examples (only illustrative ones), so it's hard to infer what's incorrect. If you define a macro to work with a single entry, then it can not be applied to tagged entries just by using tag-prefixmacro-key!!! is flat-out false in every version of mutt I have access to. This means that the entire section Special usage: applying to several tagged entries is both false and useless. Based on that statement, given the following macro: macro index ,t tag-entry I would expect the following sequence of characters to error out: ttt;,t But in fact it works perfectly. -Robin -- http://singinst.org/ : Our last, best hope for a fantastic future. .i ko na cpedu lo nu stidi vau loi jbopre .i danfu lu na go'i li'u .e lu go'i li'u .i ji'a go'i lu na'e go'i li'u .e lu go'i na'i li'u .e lu no'e go'i li'u .e lu to'e go'i li'u .e lu lo mamta be do cu sofybakni li'u
Re: The wiki lies about macros and tags.
On Thu, Jul 19, 2012 at 10:48:03AM -0700, Robin Lee Powell wrote: On Thu, Jul 19, 2012 at 12:44:31PM -0500, David Champion wrote: * On 19 Jul 2012, Robin Lee Powell wrote: The section about tags in http://wiki.mutt.org/?MuttGuide/Macros is flat-out wrong in 1.5.21 and 1.5.20, as far as I can tell, and In what way, specifically? The statements appear to be correct and there are no functional examples (only illustrative ones), so it's hard to infer what's incorrect. If you define a macro to work with a single entry, then it can not be applied to tagged entries just by using tag-prefixmacro-key!!! is flat-out false in every version of mutt I have access to. This means that the entire section Special usage: applying to several tagged entries is both false and useless. Based on that statement, given the following macro: macro index ,t tag-entry I would expect the following sequence of characters to error out: ttt;,t But in fact it works perfectly. It just occured to me that it may be that it is intended to mean that given: macro index ,t tag-entry this won't work: macro index ,x tag-prefix,t But in fact that is also false; all 4 of the following work exactly as you'd expect: macro index ,t t macro index ,T tag-entry macro index ,x tag-prefix,t macro index ,X tag-prefix,T at least in 1.5.21, where I just tested them. -Robin
wiki macro page expansion (was Re: The wiki lies about macros and tags.)
On Thu, Jul 19, 2012 at 10:55:07AM -0700, Robin Lee Powell wrote: On Thu, Jul 19, 2012 at 10:48:03AM -0700, Robin Lee Powell wrote: On Thu, Jul 19, 2012 at 12:44:31PM -0500, David Champion wrote: * On 19 Jul 2012, Robin Lee Powell wrote: The section about tags in http://wiki.mutt.org/?MuttGuide/Macros is flat-out wrong in 1.5.21 and 1.5.20, as far as I can tell, and In what way, specifically? The statements appear to be correct and there are no functional examples (only illustrative ones), so it's hard to infer what's incorrect. If you define a macro to work with a single entry, then it can not be applied to tagged entries just by using tag-prefixmacro-key!!! is flat-out false in every version of mutt I have access to. This means that the entire section Special usage: applying to several tagged entries is both false and useless. Based on that statement, given the following macro: macro index ,t tag-entry I would expect the following sequence of characters to error out: ttt;,t But in fact it works perfectly. It just occured to me that it may be that it is intended to mean that given: macro index ,t tag-entry this won't work: macro index ,x tag-prefix,t But in fact that is also false; all 4 of the following work exactly as you'd expect: macro index ,t t macro index ,T tag-entry macro index ,x tag-prefix,t macro index ,X tag-prefix,T at least in 1.5.21, where I just tested them. And now I think I understand what it's *actually* trying to say. I took: If you define a macro to work with a single entry, then it can not be applied to tagged entries just by using tag-prefixmacro-key!!! to mean that *no* macros *ever* work with tags unless set to do so explicitely, but it means that *some* macros will do unpexpected things. I'm going to suggest some wording here that I'd like to put in that section of the wiki, and y'all can tell me if it's halfway decent. Tags, Advancement, And Other Macro Surprises All macros devolve in the end, essentially, to a sequence of keystrokes sent to mutt. This means that working with tagged messages in macros can be tricky, at least unless you have auto_tag turned on, because if you simply hit the tag-prefix key (default ;) before the macro, the tag-prefix key will only apply to the first action. If your macro does more than one thing, each seperate thing that it does must be tag-prefixed seperately. Here's an example; this (totally useless) macro: macro index ,g 'pipe-entrywc -lenterdelete-message' useless: count lines, throw away the count, and then delete pipes a message to a shell command and then deletes it. If, however, you use tab-prefix first (i.e. ;,g), it doesn't pipe each message to the shell and then delete them, it pipes them all to the shell and then deletes the one under the cursor. In other words, assuming default bindings and using enter to stand in for hitting the enter key, the keystrokes: |wc -lenterd become: ;|wc -lenterd which pipes all the messages but only deletes one message (and not any of the ones you had tagged, probably, but rather the one under the cursor!) and not: ;|wc -lenter;d which pipes and deletes all of them, as you might expect. A slightly tricky bit there is that pipe-entry asks for user input, which you might not want in a macro; this can be handled by temporarily disabling that behaviour and then (assuming you want it on) turning it back on, like so: macro index ,G 'enter-commandset wait_key=noenterpipe-entrywc -lenterdelete-messageenter-commandset wait_key=noenter' useless: count lines, don't wait, throw away the count, and then delete The wait_key bit is to stop it from explicitely asking you to press enter. This behaves even worse with tag-prefix, because what you end up with is: ;:set wait_key=noenter|wc -lenterd:set wait_key=yesenter Which is a problem because as soon as you type the :, the prefix-ness just gets completely lost; you might as well have not even typed ;. For some macros, there's no problem; this macro will work just fine with tag-prefix: macro index ,s 'save-message=spamenter' Dump to spam folder Because it only performs one action, with tag prefix this turns into: ;s=spamenter which works perfectly. If you do need a macro that performs multiple actions, though, what you'll need to do is have a version that expects no tags, and a versian that accepts tags. [INSERT CURRENT CONTENTS OF Special usage: applying to several tagged entries HERE] Another surprise is that most commands in mutt at the index level move to the next message, at least with default settings, and this is true when they are invoked as macros as well. This means that: macro index ,t 'toggle-newdelete-message' broken: toggle new, then delete something else
Re: The wiki lies about macros and tags.
On Thu, Jul 19, 2012 at 01:04:23PM -0500, David Champion wrote: * On 19 Jul 2012, Robin Lee Powell wrote: If you define a macro to work with a single entry, then it can not be applied to tagged entries just by using tag-prefixmacro-key!!! is flat-out false in every version of mutt I have access to. This means that the entire section Special usage: applying to several tagged entries is both false and useless. It's not false or useless, but it is incomplete. Sorry, I started my big mail before I saw this. :) What it means is that if a macro contains two or more operations, and you press your tag-prefix keystroke before executing the macro, it will execute the first operation on each tagged entry and then execute each subsequent operation on the current entry, whichever entry happens to be current after the first operation is done. The current wording is correct in a logical sense, but not in a practical sense. Perhaps it should say: If you define a macro to work with a single entry, then it can not **necessarily** be applied to tagged entries just by using tag-prefixmacro-key! Or: If you define a macro to perform multiple actions, then it can not be applied to tagged entries just by using tag-prefixmacro-key! Or: tag-prefix affects only the next action performed by a macro, not the entire macro as a whole. I got into documentation mode and suggested some rather extensive additions; please let me know what you think. -Robin -- http://singinst.org/ : Our last, best hope for a fantastic future. .i ko na cpedu lo nu stidi vau loi jbopre .i danfu lu na go'i li'u .e lu go'i li'u .i ji'a go'i lu na'e go'i li'u .e lu go'i na'i li'u .e lu no'e go'i li'u .e lu to'e go'i li'u .e lu lo mamta be do cu sofybakni li'u
Re: archive messages in gmail
On Tue, Jul 17, 2012 at 06:56:19PM -0500, Luis Mochan wrote: I have used gmail from mutt occasionally using the attached rc file. Today I decided to clean my gmail account, deleting some messages and saving others in their corresponding folders under, for example =here or =there (under imaps://imap.gmail.com:993/). Things seemed to be working well. After saving each message, it was marked as Deleted from my INBOX. My problem is that when I expunged the messages from the INBOX, they also dissapeared from the folder to which I had copied them! You're going to need to tell us the exact keystrokes you're pressing for us to be able to usefully comment. This is very confusing to me (and probably I couldn't explain the situation clearly). How could one manage gmail labels in gmail from within mutt in a safe way? I've had no problem whatsoever with just: s=Labelenter But then I don't use labels with gmail very much at all because the search is so good; in fact I have s rebound to save to all mail, which removes things from the inbox but does nothing else. Here's all my gmail-related stuff, with comments, in case it helps: # Gmail-related keyboard shortcuts # This allows going to space-containing folders bind editor space noop # The trash variable doesn't exist in this version of mutt, so we # trash with delete; we also turn off pattern delete due to no ask # for user input command; just use the tag functions # # Note that saving to Trash immediately, forcefully, deletes the message from # the inbox; this causes a Mailbox was externally modified. Flags # may be wrong. message, and often causes the cursor to go # somewhere weird. This does not seem to be fixable, although you # could add last-entry or something to these macros and at least # end up in a predictable place. # macro index,pager d save-message=[Gmail]/Trashenter Gmail trash message macro index,pager D noop macro index,pager ^D tag-threadtag-prefixsave-message=[Gmail]/Trashenter Gmail trash thread macro index,pager escd tag-subthreadtag-prefixsave-message=[Gmail]/Trashenter Gmail trash thread # Saving to Trash immediately, forcefully, deletes the message from # the inbox; this means undelete of all kinds is useless, you have # to go to the trash and save them to another label, or use the web # interface. macro index,pager u noop macro index,pager ^u noop macro index,pager escu noop # I don't use labels basically ever, so by default save just means # get it out of my inbox macro index,pager s save-message=[Gmail]/All Mailenter Remove from inbox/save to all mail macro index,pager ,s save-message Normal save macro index,pager S save-message Normal save # Macros to go to common gmail labels. macro index,pager ,i change-folder=INBOXenter Go to inbox macro index,pager ,a change-folder=[Gmail]/All Mailenter Go to all mail macro index,pager ,s change-folder=[Gmail]/Sent Mailenter Go to outbox macro index,pager ,d change-folder=[Gmail]/Draftsenter Go to drafts -Robin -- http://singinst.org/ : Our last, best hope for a fantastic future. .i ko na cpedu lo nu stidi vau loi jbopre .i danfu lu na go'i li'u .e lu go'i li'u .i ji'a go'i lu na'e go'i li'u .e lu go'i na'i li'u .e lu no'e go'i li'u .e lu to'e go'i li'u .e lu lo mamta be do cu sofybakni li'u
Re: archive messages in gmail
On Thu, Jul 19, 2012 at 01:38:21PM -0700, Robin Lee Powell wrote: On Tue, Jul 17, 2012 at 06:56:19PM -0500, Luis Mochan wrote: I have used gmail from mutt occasionally using the attached rc file. Today I decided to clean my gmail account, deleting some messages and saving others in their corresponding folders under, for example =here or =there (under imaps://imap.gmail.com:993/). Things seemed to be working well. After saving each message, it was marked as Deleted from my INBOX. My problem is that when I expunged the messages from the INBOX, they also dissapeared from the folder to which I had copied them! You're going to need to tell us the exact keystrokes you're pressing for us to be able to usefully comment. This is very confusing to me (and probably I couldn't explain the situation clearly). How could one manage gmail labels in gmail from within mutt in a safe way? I've had no problem whatsoever with just: s=Labelenter But then I don't use labels with gmail very much at all because the search is so good; in fact I have s rebound to save to all mail, which removes things from the inbox but does nothing else. Here's all my gmail-related stuff, with comments, in case it helps: My apologies, these needed more testing. It turns out that whether or note something you've saved to a label leaves your inbox is dependent on whether you send the IMAP delete command for that email in your inbox, so the behaviour of the delete variable becomes important; delete=no means save saves to labels but keep in the inbox, delete=yes means save saves to labels and removes from the inbox, approximately. My stuff again: # Gmail-related keyboard shortcuts # This allows going to space-containing folder names bind editor space noop # The trash variable doesn't exist in this version of mutt, so we # trash with delete; we also turn off pattern delete due to no ask # for user input command; just use the tag functions # # Note that saving to Trash immediately, forcefully, deletes the message from # the inbox; this causes a Mailbox was externally modified. Flags # may be wrong. message, and often causes the cursor to go # somewhere weird. This does not seem to be fixable, although you # could add last-entry or something to these macros and at least # end up in a predictable place. # macro index,pager d save-message=[Gmail]/Trashenter Gmail trash message bind index,pager D noop macro index,pager ^D tag-threadtag-prefixsave-message=[Gmail]/Trashenter Gmail trash thread macro index,pager escd tag-subthreadtag-prefixsave-message=[Gmail]/Trashenter Gmail trash thread # I don't use labels basically ever, so by default save just means # get it out of my inbox # # This version, and the variable setting, auto-expunge such # messages; if you don't want that, comment out the next two lines # and uncomment the one after that. set delete=yes macro index,pager s save-message=Savedentersync-mailbox Remove from inbox/save to all mail # macro index,pager s save-message=Savedenter Remove from inbox/save to all mail macro index,pager ,s save-message Normal save macro index,pager S save-message Normal save # Macros to go to common gmail labels. macro index,pager ,i change-folder=INBOXenter Go to inbox macro index,pager ,a change-folder=[Gmail]/All Mailenter Go to all mail macro index,pager ,s change-folder=[Gmail]/Sent Mailenter Go to outbox macro index,pager ,d change-folder=[Gmail]/Draftsenter Go to drafts -Robin
Re: archive messages in gmail
On Thu, Jul 19, 2012 at 04:15:49PM -0500, Luis Mochan wrote: On Thu, Jul 19, 2012 at 01:38:21PM -0700, Robin Lee Powell wrote: On Tue, Jul 17, 2012 at 06:56:19PM -0500, Luis Mochan wrote: I have used gmail from mutt occasionally using the attached rc file. Today I decided to clean my gmail account, deleting some messages and saving others in their corresponding folders under, for example =here or =there (under imaps://imap.gmail.com:993/). Things seemed to be working well. After saving each message, it was marked as Deleted from my INBOX. My problem is that when I expunged the messages from the INBOX, they also dissapeared from the folder to which I had copied them! You're going to need to tell us the exact keystrokes you're pressing for us to be able to usefully comment. If I remember correctly (I haven't reproduced the problem) I typed s=mailboxenter to save a message, $ to purge the message, which had been marked with a D, from the INBOX c=mailboxenter to open the mailbox and the message seems to have disappeared. AAH! I get it. That's because you have trash= set to Google's Trash, which is how you tell it that you want things purged forever. So $ obeys the trash= variable, which trashes it completely. If you drop trash= and use my macros instead for deleting, which actually save to Trash instead of deleting, you should be fine. -Robin
Re: Is mutt extensible with a programming language?
XeCycle xecy...@gmail.com writes: On Sat, Jun 25, 2011 at 03:04:09AM +0200, lee wrote: Gnus has one big disadvantage: It can be awfully slow. Yes... It's more than *awfully* slow. Now I use it as a newsreader, subscribing several groups at gmane and also some RSS feeds. Mixing them with mail will probably be even more slow, which is also a reason for my insisting on mutt. So far, I have found only two things gnus is slow with: * processing incoming email is *awfully* slow * creating a summary buffer when there are *many* unread messages to show The second one isn't really an issue. The first one is currently very annoying because I still have a lot of messages that need to be processed in the process of switching from maildir to nnml --- and that's mainly my fault because I started doing it the wrong way. Still that should be much faster. It's not a fair comparison, though, because it's something mutt doesn't do. Mutt is awesome and totally reliable; gnus is awesome and extremely powerful. (I can't tell yet how reliable gnus is.) Recently I'm also trying Chromium; I use Firefox with Pentadactyl now. In Chromium, I didn't find anything comparable to Vimperator/Pentadactyl, but it's much faster than Firefox. Well, these comparisons are similar. Chromium is a MUA? I tried it and found it can't even display PDF documents and cannot be configured to do anything but display a web page. It isn't noticeably faster than konqueror (with webkit) or seamonkey.
Re: Is mutt extensible with a programming language?
XeCycle xecy...@gmail.com writes: Hello, I've been using mutt for several months, and I like it. However I'm an Emacs fan, so I tried Gnus, but failed... it really is not a mail client. But Gnus can be easily extended with Emacs Lisp, which is a killer feature compared to mutt. After using mutt for about 15+ years, I recently switched to gnus. It may take some reading of the documentation and some trying to get started, and the documentation is a little overwhelming at first. Nonetheless I'm finding it extremely worthwhile even though I have only just begun to explore the possibilities. Gnus has one big disadvantage: It can be awfully slow. Mutt is awesome and totally reliable; gnus is awesome and extremely powerful. (I can't tell yet how reliable gnus is.) One of the things I missed very much with mutt was seamless integration with emacs. You can only get pretty close. Since you're an emacs fan, you might want to give gnus another, very serious try rather than waiting 15 years or so before you switch :)
Re: EXITCODE==255
Athanasius m...@miggy.org writes:
##
## Things that aren't spam per se, but we don't seem to be able to
## unsubscribe from
##
:0
* ^FROM.*lists@meridianmagazine\.com
{
EXITCODE=67
:0
/dev/null
}
'67' is 'EX_NOUSER', i.e. it should go back up the procmailrc/MTA chain
to tell the sender User doesn't exist.
Your MTA should deny such messages instead of receiving them.
Re: prevent startup imap connection
Mark Smith mutt...@awayand.sleepmail.com writes: I am trying to prevent mutt from opening a connection to my imap spoolfolder on startup. Comment out the imap entry in muttrc and change to the imap folders manually? Unfortunately, that won't work. I still want to access my cached messages. So when I start mutt, it should show me my cached inbox without connecting automatically... Are these messages cached on the IMAP server? If not, how about mutt -f ~/cached-inbox and then connecting at will? I am using the directives: set header_cache = ~/.mutt/cache/headers set message_cachedir = ~/.mutt/cache/bodies so setting for example mutt -f .mutt/cache/bodies/imaps\:user\@fastmail.fm\@mail.messagingengine.com\:993/INBOX/ won't work as it tells me ... is not a mailbox. Ah, I see. Perhaps you can use offlineimap to synchronize you emails with the IMAP server and use mutt without connecting directly at all. I wonder if I just have to give up on this. Can't believe I am the only one having this issue. Maybe I should put a request in to have this implemented or report a bug that imap_passive is not working as described? The description of imap_passive says: , |When set, mutt will not open new IMAP connections to check for new mail. |Mutt will only check for new mail over existing IMAP connections. This is |useful if you don't want to be prompted to user/password pairs on mutt |invocation, or if opening the connection is slow. ` So imap_passive is about the checking for *new* mail. I guess you can have a setup in which you have email stored locally, while newly incoming emails are found on IMAP servers. With such a setup, you could use imap_passive as described above, since mutt could work with the email stored locally. When you have mutt set up to access email on an IMAP server, what other choice does it have than to open the connection to let you access your email --- unless there was some sort of offline mode? However, I haven´t tried it, so someone else probably knows better. When you make a feature request for an IMAP offline mode, you´ll probably be told to use offlineimap instead.
Re: [OT] fetchmail slowing with succesive polls
Jan-Herbert Damm jan-h-d...@web.de writes: running fetchmail fom the macro puts me into a terminal where the fetchmail program prints dots to mark its progress. When it is polling the second and especially the following mail-adresses, mails with only say 2500 bytes take approximately 15 seconds on a 6000 mbit broadband cable connection. whereas the mails from the first poll take much less than a second. Do you have the same effects when changing the order of the polling entries? Perhaps the servers are just slow?
Re: EXITCODE==255
Joseph syscon...@gmail.com writes: I have in my .maildir folder file name: EXITCODE==255 -rw--- 1 joseph joseph 226435 Jun 12 23:20 EXITCODE==255 it looks like collection of html emails. Any ideas how to retrieve this mail? Rename the folder with mc?
Re: prevent startup imap connection
Mark Smith mutt...@awayand.sleepmail.com writes: I am trying to prevent mutt from opening a connection to my imap spoolfolder on startup. Does anyone know how to prevent this? I would simply like to view my cached messages and connect to imap manually if I want to. Comment out the imap entry in muttrc and change to the imap folders manually?
Re: prevent startup imap connection
Mark Smith mutt...@awayand.sleepmail.com writes: I am trying to prevent mutt from opening a connection to my imap spoolfolder on startup. Does anyone know how to prevent this? I would simply like to view my cached messages and connect to imap manually if I want to. Comment out the imap entry in muttrc and change to the imap folders manually? Unfortunately, that won't work. I still want to access my cached messages. So when I start mutt, it should show me my cached inbox without connecting automatically... Are these messages cached on the IMAP server? If not, how about mutt -f ~/cached-inbox and then connecting at will?
Re: return reciepts
On Sun, Jul 04, 2010 at 12:33:22PM +0200, Simon Ruderich wrote: Either directly or in a wrapper script (which could even be in C, but I would use something faster to develop, like Shell, Perl, Python, ..) used in $editor. It would check the mail after you exit the editor, and then ask you - based on a configuration file - if you want to add a request, and if yes add the necessary header. Yes, other programming languages than C would be better suited for this, but I'd have to learn them first. But if the recipient doesn't care about your mail, then how does adding a receipt request help? In this case, I started to request them because they don't answer --- and guess what, I got a reciept. That way they can't claim they didn't get my mail. It's extremely useful. Besides, do you seriously trust in that every admin involved has set up their mailservers correctly? Do you seriously trust in that email never gets lost? Do you seriously trust in that you will always get an error message sent back to you in case something goes wrong? I've seen servers at ISPs set up so that they don't even accept error messages sent to them ... In this case, the alternative would be to print the message on paper to deliver it in person and have them certify that they recieved it. I like return reciepts better for now. Practice has shown that it is not best practice. Because of poor support, maybe :) Or because it's a bad idea. It's still way better than the alternative. like them) easily be done with $display_filter. Ah, that's cool :) Now I have the pieces I'd need to interface with mutt, thanks.
Re: return reciepts
On Sat, Jul 03, 2010 at 09:51:03AM -0400, Patrick Shanahan wrote: * lee l...@yun.yagibdah.de [07-03-10 09:13]: On Sat, Jul 03, 2010 at 12:12:38AM +0200, Rado S wrote: Practice has shown that it is not best practice. Because of poor support, maybe :) Or, more likely, requests for features that most do *not* want presented in a haughty manner What's haughty about this? which would require coding and where work-a-rounds have been presented. Just look at the replies, ppl told me at first that a feature I have use for is useless, troublesome and pointless and that they don't want it because they don't like it. How haughty is that? And keep in mind that nobody would be forced to use this feature if they don't like it. Just look at your own comment and how haughty that is: Apparently the idea that implementing a feature would require some work is horrible to you, so you're telling me that everyone who has use for it should implement the feature by doing the necessary steps for each message manually. Do it manually was the only workaround presented, but that's silly considering that I already said in my OP that I can do it manually but am wondering if there's a better solution available. Besides, it has probably escaped you that there's a difference between solution and workaround. Isn't it amazing that ppl can't say something like hey I don't have use for this feature and I don't like it and I don't know of any implementation, but it would sure be great if you were to come up with a solution everyone could use? You know, I've already been asking myself if I should make such a solution available for everyone who wants it if I ever implement it after seeing the rude comments I got here. Don't be surprised when at some time, you'll find yourself out of free software because you finally managed to piss off everyone who was willing to provide some.
Re: return reciepts
On Sat, Jul 03, 2010 at 12:12:38AM +0200, Rado S wrote: Your original request just sounds like reversing the default from mostly no r-r, with manual exceptions to mosty _DO_ r-r, with manual exceptions, it actually requires you still to make a manual choice... That is not at all what I want. The default is NOT to request reciepts, and that won't change. But in some cases I do want to request them --- and that without having to add header lines manually, which is inconvenient and too easy to forget. Let me add that you just got me to the idea that a simple yes/no for a combination of recipients won't suffice: It would have to be always/once/no/never, meaning that for the combination of recipients in question, the requesting of reciepts would either always be enabled or for that particular message only or no reciept for the particular message will be requested or reciepts are never requested. No doubt that the kind of support for reciepts I have in mind could be used otherwise, but how someone makes use of a feature is always up to them. It's a common feature in many MUAs, so mutt could as well support it --- or there could already be a solution. You've been given technical details elsewhere. I once thought it would make things easier for me and worked with it myself, until I realized it didn't improve anything really, just added more overhead for the sender creating and the recipient dealing with it. That's the way it is now, I agree. It is why I'm looking for a better solution that avoids these disadvantages. Wasted effort compared to an editor macro to add some line like please acknowledge receipt and respond ASAP. What makes you think that the recipient would bother to write an answer? It would involve even more overhead for them to manually write and send a response than it is to use a feature of their MUA that reduces the overhead to just pressing a single key --- or doesn't involve any overhead at all for them because they have chosen to always automatically send reciepts when requested. Practice has shown that it is not best practice. Because of poor support, maybe :)
Re: What map is default for .maildir?
On Thu, Jul 01, 2010 at 01:33:09PM -0800, rog...@sdf.org wrote: In another shell within GNU Screen, I successfully did a stuff command to refresh the Mutt display using one of it's key bindings every 60 seconds: screen -X at Mutt stuff $'echo refresh key' Not sure what you mean, Ctrl-l doesn't work for you? what to consider as mailboxes. That would require you to keep editing your ~/.muttrc to keep the list of mailboxes up to date. #mailboxes `echo ~/.maildir/.* ~/.maildir/*` mailboxes `find ~/.maildir/ -type d -name cur -printf '%h '` Yep, you could use something like that --- but mutt-mb can do a little more than that :)
Re: return reciepts
On Thu, Jul 01, 2010 at 11:09:22PM +0200, Rado S wrote: =- lee wrote on Thu 1.Jul'10 at 18:08:43 +0200 -= Noone using return reciepts? No, because if you want that, just write it in your eMail. That's awfully annoying and too easy to forget. It's a common feature in many MUAs, so mutt could as well support it --- or there could already be a solution. If there isn't, I might go ahead and write something for the purpose. But I don't want to re-invent the wheel unnecessarily. As to comments about the requests being ignored and therefore pointless: Sorry, but these comments are themselves pointless. It's a feature useful to me, and lacking better alternatives, I want to make use of it. Unfortunately, mutt doesn't have this feature, so I'm asking what's available before putting my time into creating support for it myself. Besides, it's hard to believe that noone on this mailing list has use for return reciepts and/or that everyone handles them manually.
Re: return reciepts
On Fri, Jul 02, 2010 at 05:15:36PM +0100, Toby Cubitt wrote: the Disposition-Notification-To: header. So to request receipts, it may be sufficient to add this header to your outgoing emails using mutt's my_hdr command. That puts the header into every outgoing email, and ppl on mailing lists will complain about it. As for automatically sending a read receipt when you open a mail in mutt, I imagine it should be possible to cook something up using message-hooks and a little scripting. If you can do what I described in my OP with a little scripting, that's great for you, but I don't see how to do it. I'd have to write a program in C for it and somehow make it work with mutt --- and preferably make it so that it can be used with other MUAs as well. I don't know of any MUA that deals with return reciepts in the way described in my OP. So, with a little effort, what you want can probably already be done using standard mutt features (plus maybe some external tools for automatically sending receipts). Ok, how so? Refer to to my OP for a more detailed description of how it's supposed to work ... As to comments about the requests being ignored and therefore pointless: Sorry, but these comments are themselves pointless. No, the comments were not pointless. I'm aware of the issues involved with return reciepts but still have use for them. It's not my intention at all to debate the usefulness or privacy concerns of return reciepts in general or in particular. Such a debate wouldn't take me any closer to a solution. I'd find it much more interesting to talk about how a good support for return reciepts should be designed. This is not to say these points aren't valid. I'm not sending return reciepts, either, but that's because there isn't good support for them: None in mutt, apparently, and I've seen only MUAs that offered only to either ask if I want to send a reciept or always send one or don't send any at all. None of these three options is sufficient. If there's a MUA that can do better, I'd be curious to hear about it. And why shouldn't mutt be the MUA that can do better in that than others? Having that said, it comes to mind that more users of mutt might make use of return reciepts if there was well designed support for them ... One way to address privacy concerns could be, for example, to queue the reciepts one wants to send and then send them all at once automatically, perhaps once or twice a day at fixed times. Perhaps that's a poor idea, I don't know.
Re: return reciepts
On Fri, Jul 02, 2010 at 12:11:27PM -0500, David Champion wrote: * On 28 Jun 2010, lee wrote: Hi, how do you handle return reciepts with mutt? I know I can add header You could try Werner Koch's rfc2298 MDN patch, but afaik it has not been updated in years and probably needs some love. http://intevation.de/roundup/aegypten/file34/mutt-patch-1.5.6cvs.g10.mdn.1.asc Thanks, that could be very useful :) However, it makes me think again that something to handle return reciepts that works (mostly) independantly of mutt might be a better approach. Patching a recent mutt version with a patch that's 7 years old and like 14 versions back could turn out to be a little difficult ...
Re: return reciepts
On Fri, Jul 02, 2010 at 01:45:57PM -0400, Patrick Shanahan wrote: * lee l...@yun.yagibdah.de [07-02-10 13:16]: On Fri, Jul 02, 2010 at 05:15:36PM +0100, Toby Cubitt wrote: the Disposition-Notification-To: header. So to request receipts, it may be sufficient to add this header to your outgoing emails using mutt's my_hdr command. That puts the header into every outgoing email, and ppl on mailing lists will complain about it. No, it puts the header in the messages *you* put it in. You do have control of your email client! As for automatically sending a read receipt when you open a mail in mutt, I imagine it should be possible to cook something up using message-hooks and a little scripting. If you can do what I described in my OP with a little scripting, that's great for you, but I don't see how to do it. I'd have to write a program in C for it and somehow make it work with mutt --- and preferably make it so that it can be used with other MUAs as well. I don't know of any MUA that deals with return reciepts in the way described in my OP. So, what you *really* want is for someone to code/script it for you. The offer of renumeration will more than likely provide you with candidates. Can you read at all?
Re: return reciepts
On Fri, Jul 02, 2010 at 06:23:23PM +, Grant Edwards wrote: On 2010-07-02, lee l...@yun.yagibdah.de wrote: Having that said, it comes to mind that more users of mutt might make use of return reciepts if there was well designed support for them Doubit it. Well designed support for evil is still evil. 1/2 :) There's nothing evil about return reciepts. ... One way to address privacy concerns could be, for example, to queue the reciepts one wants to send and then send them all at once automatically, perhaps once or twice a day at fixed times. Perhaps that's a poor idea, I don't know. It's the actual sending of receipts that's a problem. I don't see how queueing them up helps. Then don't send them if you don't want to. Queueing them could be do done for not to disclose when you handled the message.
Re: return reciepts
On Fri, Jul 02, 2010 at 07:40:45PM +0100, Toby Cubitt wrote: in discoursing from the armchair without actually trying to implement it, there are very quite likely difficulties I'm missing here. See, it's not all that easy :) So before spending a lot of time to figure it out, I thought it a good idea to see if there's already a solution available. Anyway, personally, I would set $edit-headers and implement this in the editor rather than in mutt. I hear vim is reasonably scriptable these days, but I find Lisp to be a more elegant language... ;-) That would be a good approach if I could program emacs. Unfortunately, I'm finding Lisp anything else than elegant --- rather totally unreadable and not at all understandable. But if you prefer to do your coding in C, that's great too. It would only be the easiest way for me. I just thought you might want to avoid having to hack the mutt source code, Yes, that's something I want to avoid. Good luck! Thanks!
Re: mutt-users should I be scared?
On Wed, Jun 30, 2010 at 08:40:00PM -0800, Roger wrote: .maildir0| .openoffice3| .mutt-users666(4)[7]| .roger 6(1)| ... I just consider it off-topic. ;-) l...@yun:~$ ~/src/c/systools/mutt-mb/mutt-mb -report 0 ~/Mail/ [...] 4198 /home/lee/Mail/Lists/linux/mutt-users 67550 /home/lee/Mail/Lists/linux/exim-users 68894 /home/lee/Mail/Lists/linux/debian-user [...] That should be refined, though, to display by new and read, the sizes and a total. Once I do that, it's time for a new release ...
Re: Multiple accounts at same privider
On Wed, Jun 30, 2010 at 08:57:02AM +0200, J. Prendick wrote: If now a equals b we do have a problem. I could for example change the macro-lines to macro index f1 change-folderimaps://user1:passwo...@a.com macro index f2 change-folderimaps://user2:passwo...@a.com which enables me to switch between the accounts, but e.g. from=, pgp_sign_as=, ... are not beeing set correctly. Does anyone have any idea how to solve that problem? Looks like a simple solution might be to run two instances of mutt, each with its own configuration file?
return reciepts
Hi, how do you handle return reciepts with mutt? I know I can add header lines to request a reciept (with my_hdr), but how do I make it so that reciepts are requested based on, for example, recipients? The idea is something like mutt asking me if I want to request a reciept when sending a message to a combination of recipients not yet recognized by mutt. It then would remember my decision and add that particular combination of recipients to some list for later reference as to what decision I have made. Next time when sending messages to that same combination of recipients, mutt would automatically either request a reciept or not, depending on my decision once made --- unless I explicitly instruct mutt otherwise when sending a message. Handling the sending of return reciepts when requested by incoming messages could work very much the same. How do I configure mutt to do that? Or is there already support for return reciepts?
Re: What map is default for .maildir?
On Mon, Jun 28, 2010 at 12:29:54PM -0800, rog...@sdf.org wrote: On Mon, Jun 28, 2010 at 07:59:13PM +0200, Christian Brabandt wrote: It's browser. :set bind browser \Cn sidebar-next It is :bind browser \Cn sidebar-next (if your mutt is compiled with the sidebar patch). Still error, sidebar-next: no such function in map You could check out this one: http://sourceforge.net/search/?type_of_search=softwords=mutt-mb There's no need for the sidebar anymore with mutt-mb.
remote frontend on a Mac
Hi, how do you set up a remote frontend on a Mac? I tried, but: 1.) it's unusably slow 2.) apparently, it uses at least part of the settings for a frontend on one computer on another one as well 3.) it produces error messages about failed communication with the backend 4.) it is unknown which access rights to the database the remote frontend needs 5.) the remote frontend tries to update the database and fails 6.) it's not possible to watch recordings 7.) the recordings of one user are available to the remote frontend and thus to another user I expected it would be possible for a user at the remote frontend to use his own settings and make his own recordings and watch them at his frontend, independent of other users at other frontends (as far as hardware limitations of the TV card allow), with an option to share recordings between users if they want to. If that isn't possible, what's the point?
playback of HD recording stuttering
Hi, how comes that the playback of a HD recording in mythfrontend is stuttering? Other players like mplayer and vlc play the same file just fine. But playing it from within mythfrontend, it's like the video is moving backwards a few frames all the time while playing forward. Mythfrontend is supposed to use VDPAU already, and I'm pretty sure the other players use that by default. BTW, how do you export a recording other than creating a DVD? And can I put something recorded in HD on a DVD just like other recordings, or will the resolution be reduced? How does mythfrontend deal with recordings that don't fit onto a single DVD? That HD recording is 10GB.
Re: playback of HD recording stuttering
On Wed, Dec 16, 2009 at 01:27:26PM +0100, lee wrote: Hi, how comes that the playback of a HD recording in mythfrontend is Sorry, this went into the wrong list!
Re: remote frontend on a Mac
On Tue, Dec 15, 2009 at 03:53:31PM +, Grant Edwards wrote: On 2009-12-15, lee l...@yun.yagibdah.de wrote: how do you set up a remote frontend on a Mac? I tried, but: I think using mutt to watch recorded videos is bound to fail. 1.) it's unusably slow Sorry, this has also gone to the wrong list! I need to be more careful ...
remote frontend on a Mac
Hi, how do you set up a remote frontend on a Mac? I tried, but: 1.) it's unusably slow 2.) apparently, it uses at least part of the settings for a frontend on one computer on another one as well 3.) it produces error messages about failed communication with the backend 4.) it is unknown which access rights to the database the remote frontend needs 5.) the remote frontend tries to update the database and fails 6.) it's not possible to watch recordings 7.) the recordings of one user are available to the remote frontend and thus to another user I expected it would be possible for a user at the remote frontend to use his own settings and make his own recordings and watch them at his frontend, independent of other users at other frontends (as far as hardware limitations of the TV card allow), with an option to share recordings between users if they want to. If that isn't possible, what's the point?
Re: HTML mail: Why isn't it displayed?
On Sat, Nov 07, 2009 at 06:12:14AM -0400, Monte Stevens wrote: On Fri, Nov 06, 2009 at 09:22:40PM -0700, lee wrote: Well, I have set implicit_autoview. Even when I press 'v' to view the attachments and then Enter to display it, I'm seeing the HTML source. A recent post from Martin Krafft describes a problem rendering html. It sounds similar to yours; perhaps the issue is the same. The subject is, mutt no longer renders HTML or spawns browser on text/html attachments. Yeah, I've read that last night but couldn't find view-mailcap on the help page. Now I've found it, and it's working --- might have to do with me updating my Debian testing last night ... Here's a link to the most recent message in that thread. (I hope that sending you an html link is not a bad joke.) http://marc.info/?l=mutt-usersm=125750062424772w=2 Nah, that's fine. Sending an URL is a totally different thing than sending an HTML message. Ok, so how do I get mutt to use a specific mailcap? You did it, by setting: mailcap_path=~/.mailcap That works now, too :) Thanks!
Re: HTML mail: Why isn't it displayed?
On Sat, Nov 07, 2009 at 06:35:17PM +0800, bill lam wrote: On Tue, 03 Nov 2009, lee wrote: Hi, I've got an email with these headers: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam_score: 4.4 X-Spam_score_int: 44 X-Spam_bar: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xml:lang=de lang=de head I suspect that email is mal-formated. The html is included inline rather than as a multipart attachment. Did you see the any attachments in the attachment page? It doesn't seem to have attachments: I have the counter displayed in the message list, and it's 0 --- though that counter isn't always right. When I look at the message with 'v', I'm seeing: q:Exit s:Save |:Pipe p:Print ?:Help I 1 no description [text/html, quoted, iso-8859-1, 7.2K] So that would be inline, I guess? Is there an RFC specifying that HTML source must not be inlined? I'd need something to point the sender of the message to to have them change it.
HTML mail: Why isn't it displayed?
Hi, I've got an email with these headers: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam_score: 4.4 X-Spam_score_int: 44 X-Spam_bar: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xml:lang=de lang=de head Mutt displays the HTML garbage as plain text, unreadable. Now I've no idea if the problem is with mutt, or if the headers or something else are wrong. If the problem is with the email, it would be nice to know which RFCs are to be applied so that I can refer the sender of these mails to them and have them send them correctly encoded.
Re: HTML mail: Why isn't it displayed?
PS: Mutt seems to ignore ~/.mailcap. l...@cat:~/Mail$ mutt -nF /dev/null -Q mailcap_path mailcap_path=~/.mailcap:/usr/share/mutt/mailcap:/etc/mailcap:/etc/mailcap:/usr/etc/mailcap:/usr/local/etc/mailcap l...@cat:~/Mail$ So which of the mailcap files mutt finds in the mailcap_path will it use? The manual doesn't say. On Tue, Nov 03, 2009 at 10:58:02PM -0700, lee wrote: Hi, I've got an email with these headers: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam_score: 4.4 X-Spam_score_int: 44 X-Spam_bar: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xml:lang=de lang=de head Mutt displays the HTML garbage as plain text, unreadable. Now I've no idea if the problem is with mutt, or if the headers or something else are wrong. If the problem is with the email, it would be nice to know which RFCs are to be applied so that I can refer the sender of these mails to them and have them send them correctly encoded.
Re: UTF-8 signatures with BOM
On Fri, Aug 07, 2009 at 03:52:10PM +0200, Alexander Dahl wrote: 24 feffAlexander Dahl, Staff Engineer This is the same signature you should see below and you should also find this special character in it. Is it possible to use this character in the body of a mail? I'm not seeing a special character in the signature. As to where it comes from, the character is in the signature file. I wouldn't expect the MUA to remove characters from the signature file. Why is it important to have this character in the file?
Re: how to prevent external commands from being substituted in
On Fri, Jul 24, 2009 at 10:53:32PM -0700, Brandon Sandrowicz wrote: macro index .a enter-commandunmailboxes *enter \ enter-commandmailboxes \`mutt-mb -line 4 ~/Mail\`enter It's the space that you have in there. That space is just like you hitting the space bar while sitting in the index (since after the first enter there is command being constructed). You're right, it works without the space. Thanks!
Re: Couldn't lock /var/mail/russ? message when trying to access
On Sat, Jul 25, 2009 at 08:38:42AM -0500, Russell Urquhart wrote: Hi, I recently had to restart my system (os x) and now, in mutt, when i try and search for new mail (shift-g) i get the Couldn't lock message. I am able to send mail out. Did something not get locked properly? Perhaps there's a stale lock file somewhere? That might make mutt think that there is a lock when there isn't any and prevent it from obtaining a lock itself. Unfortunately, I don't know exactly what to look for.
Re: how to prevent external commands from being substituted in
On Thu, Jul 23, 2009 at 01:34:38PM +0200, Rocco Rutte wrote: Hi, * lee wrote: macro index .a unmailboxes * ; mailboxes `mutt-mb -line ~/Mail`enter macro index .l unmailboxes * ; mailboxes `mutt-mb -line ~/Mail/Lists`enter That's not how macros work. If you hit '.a', mutt will simulate you pressing the keys 'u', 'n', 'm', ... and so on. I.e. it does not issue 'unmailboxes *'. You need to tell it that a rc command is following like so: macro index .a 'enter-commandunmailboxes *enter...' And you may also want to try to escape the backticks in the command because otherwise the command will be expanded at startup time and not execution time. Thanks, that's exactly what I'm looking for! Unfortunately, it doesn't work: macro index .a enter-commandunmailboxes *enter ; \ enter-commandmailboxes \`mutt-mb -line 4 ~/Mail\`enter This seems to do the unmailboxes part, but not the second part of it. Mutt says key not bound and displays the currently selected mail instead.
Re: how to prevent external commands from being substituted in
On Sat, Jul 25, 2009 at 12:04:12PM +1000, Cameron Simpson wrote: Get rid of the semicolon and retry. Mutt aborts macros when something goes wrong, which was probably the semicolon. Remember, the macro is as if you have _typed_ it all. There's no semicolon needed before the next thing you type:-) Ah, that makes sense. It's basically working now, but it still displays the currently selected message. It seems to do that after the first enter. If I try without the second enter, it still displays the message and leaves the second part of the macro in the command line so that I have to press enter myself. What might be causing that? Do I need to escape the '*' in unmailboxes *? It would be logical that I should ... Hm, it works when the '*' is escaped, but still displays the current message. macro index .a enter-commandunmailboxes *enter \ enter-commandmailboxes \`mutt-mb -line 4 ~/Mail\`enter
Re: program to generate mailboxes lines
On Tue, Jul 21, 2009 at 05:55:36PM +0100, Christian Ebert wrote: * lee on Monday, July 20, 2009 at 22:28:25 -0600 On Mon, Jul 20, 2009 at 10:11:15PM -0600, lee wrote: Here's the program. Let me know how you like it :) Nice. I put a better version on http://sourceforge.net/projects/mutt-mb/ :) snip // it's a maildir printf(mailboxes = %s\n, this); Wouldn't it be easier to just print out a list of mailboxes? Not if you want to create a file to source or to put the lines into your ~/.muttrc. a) how do you use it in muttrc (without awk, maybe, or most certainly I'm being dense)? Not at all --- I quickly found that I didn't want to use a file but use it directly. I changed it to support different output formats: mailboxes, just a list and a single line. mailboxes = `mutt-mb ~/Mail` would be the easiest, imho. You can do that with the new version: unmailboxes * mailboxes = `mutt-mb -line ~/Mail` b) Mutt might be a tiny bit faster as you only issue 1 command. Possible --- but it depends on what's in the disk cache and/or on how fast your disks are, i. e. it might be a lot faster to read one file and use many mailboxes commands than it is to run only one command that has to scan through your mail storage. Since the new version supports both ways, everyone can use what they like better or is faster. One thing not supported is using relative paths. It can be done, but I don't know how important that is.
Re: program to generate mailboxes lines
On Wed, Jul 22, 2009 at 10:18:14AM +0100, Christian Ebert wrote: mailboxes = `mutt-mb ~/Mail` mailboxes `mutt-mb ~/Mail` grr, mailboxes is a command, not a variable. Both work --- does it make a difference?
Re: program to generate mailboxes lines
On Wed, Jul 22, 2009 at 03:53:20PM +0200, Rocco Rutte wrote: Hi, * lee wrote: On Wed, Jul 22, 2009 at 10:18:14AM +0100, Christian Ebert wrote: mailboxes = `mutt-mb ~/Mail` mailboxes `mutt-mb ~/Mail` grr, mailboxes is a command, not a variable. Both work --- does it make a difference? Yes and no. Given 'mutt-mb ~/Mail' prints '~/Mail/foobar' and given that $folder is ~/Mail, you get: mailboxes ~/Mail ~/Mail/foobar with the former and: mailboxes ~/Mail/foobar with the latter. See mailbox shortcuts in the manual. Ah, I see what you mean. With the first, I'm getting an entry for =/ in the list, with the second version, I don't. So the second one is the one I want. I'll change that in the documentation of mutt-mb.
Re: generating mailboxes command (was: split display?)
On Tue, Jul 21, 2009 at 12:03:03PM +0100, Christian Ebert wrote: Sure, but (my find doesn't have printf): ~$ time find ~/Mail -type d -name cur -execdir pwd \; /dev/null real0m54.973s user0m0.447s sys 0m54.159s ~$ time find ~/Mail -type -d \( \( -name cur -o -name new -o -name tmp \) -prune -o -print \) /dev/null find: -type: -d: unknown type Hm, I think it's find -type d rather than find -type -d.
Re: [mutt] generating mailboxes command (was: split display?)
On Tue, Jul 21, 2009 at 02:52:57PM +0100, Adam Wellings wrote: If the set of maildirs rarely changes, would it be faster to generate a file and just source that in your .muttrc? It depends on what information from the file system is already cached. Assuming that nothing is cached, I would think that a file is faster. I can't do that as I use procmail to sometimes create new maildirs in some situations. Also, I've looked up why my script is no longer used, it took ~8-9s to produce the list. I'm sure it could be improved upon generally, but as find does the job, it'd purely be an academic exercise. Then mutt-mb is for you, it's pretty fast :)
Re: [mutt] generating mailboxes command
On Tue, Jul 21, 2009 at 05:49:13PM +0100, Christian Ebert wrote: lee's little C program mutt-mb that he posted in this thread Message-ID: 20090721042825.gj27...@cat.rubenette.is-a-geek.com It's better to use the version on sourceforge instead. The one posted here doesn't free all the memory it allocates, and there are other improvements in the new version: http://sourceforge.net/projects/mutt-mb/ does the job quite well and reasonably fast. l...@cat:~$ time mutt-mb -line ~/Mail/ /dev/null real0m0.064s user0m0.000s sys 0m0.070s l...@cat:~$ time mutt-mb -check ~/Mail/ check mode enabled, not creating list real0m0.065s user0m0.000s sys 0m0.070s l...@cat:~$ That's on over 700 directories and 20 files. The disk cache helps, I guess. (Using /dev/null is not entirely fair, though; it helps making it fast.) Hm, /usr/bin/find is 230k, mutt-mb is only about 15k.
Re: split display?
On Wed, Jul 22, 2009 at 10:29:50AM +0100, Arthur Dent wrote: On Tue, 2009-07-14 at 00:31 -0600, lee wrote: Or is there another MUA which can do this and work on maildir? It may be heresy to say this on a Mutt list, but have you tried Evolution? Yes --- it's polluting my mail storage by putting index files (or whatever it is) everywhere. Besides that I don't like that, it probably also means that information is stored which only Evolution can use so that I would be without this information when using another MUA. Evolution has the ability to tag (not in the Mutt sense, but in a categorising sense - with an associated colour) That's probably the kind of information stored in the extra files. Of course Evolution is a (very) heavyweight GUI application and if you are used to the agility and flexibility of Mutt it may not be what you want.. Indeed --- being heavyweight wouldn't matter much, but having to deal with all the different windows or with displaying many things at once and not having enough room for that and the keyboard only half-way supported are some things that make me not like GUI MUAs. The only one I found ok was the built-in one mozilla had, but it was somewhat limited in functionality. And what when I want to read my mails on the console, like when X isn't working or when I feel like doing that? The last one I tried was wanderlust, running in emacs. It's nice but can be awfully slow and doesn't really have advantages over mutt, so I went back to mutt. Gnus didn't want to work, and it seems to be too much a newsreader to make for a good MUA.
Re: setting mailboxes from the output of a command
On Tue, Jul 21, 2009 at 04:04:23PM -0500, Kyle Wheeler wrote: mailboxes = `mutt-mb /home/lee/Mail` Just to make sure you notice: mailboxes is a *command*, not a value, so mutt is interpreting that = as a mailbox name to expand (namely, $folder). Thanks, I found it another post here. Before that, I didn't realize that it's a command rather than a variable.
how to prevent external commands from being substituted in macro definitions
Hi, how do I prevent external commands from being processed when mutt is parsing a macro definition in ~/.muttrc? What I'm trying to do is: macro index .a unmailboxes * ; mailboxes `mutt-mb -line ~/Mail`enter macro index .l unmailboxes * ; mailboxes `mutt-mb -line ~/Mail/Lists`enter This gets substituted correctly, but it is not what I want. It creates interesting entries in the help screen and funny effects when the macro is run ... The external command must not be executed before I actually run the macro, i. e. it must be as if I type it on the : commandline inside mutt (When I do that, it works as intended.).
Re: navigation
On Wed, Jul 22, 2009 at 10:46:12AM -0700, Robert Holtzman wrote: On Mon, 20 Jul 2009, lee wrote: Did you get sidebar-scroll-up and sidebar-scroll-down to work? I can bind them to keys, but mutt says the key isn't bound when I press it. The sidebar scroll works great but the pager scroll doesn't. Not sure why. I can still use the arrow keys for the pager. Hm, I was able to scroll up and down one line after another, but when you bind sidebar-scroll-up and sidebar-scroll-down to keys, you're supposed to be able to scroll the sidebar up or down by a page. That didn't work for me.
mailboxes = generator and storage checker on sourceforge
Hi, I uploaded a better version than I posted here on sourceforge: http://sourceforge.net/projects/mutt-mb/ The version posted here doesn't free all the memory it allocates --- doesn't matter, but it's ugly. That's fixed in the version on sourceforge, plus a few extensions. The program can be used directly within ~/.muttrc, see the documentation on sourceforge (doc is included in the mutt-mb.tar.gz).
Re: navigation
On Sun, Jul 19, 2009 at 10:44:07AM -0700, Robert Holtzman wrote: Running mutt and mutt-patched 1.5.17 with the side panel listing mailboxes on Ubuntu Hardy. I can't find a way to navigate in this list other than by using c and ?. Is the side panel functional or just informative? I run mutt and mutt-patched 1.5.18 in Debian Lenny and it exhibits the same behavior. http://www.lunar-linux.org/index.php?option=com_contenttask=viewid=44 Did you get sidebar-scroll-up and sidebar-scroll-down to work? I can bind them to keys, but mutt says the key isn't bound when I press it.
Re: split display?
On Mon, Jul 20, 2009 at 09:55:42AM -0400, Tim Gray wrote: On Sun 19, Jul'09 at 10:03 PM -0600, lee wrote: mailboxes `/path/to/script/listbox.py /path/to/mail/folders` Thanks! Doesn't that need to produce some output, or does mutt have a way to assign the content of dirs from the script to mailboxes? The command in your muttrc ends up looking like mailboxes +mailbox1 +mailbox2, which is the syntax mutt wants. Oh. I was trying the script from the command line just to see what it would do, and it didn't produce any output. It seems the script fills a variable it uses. I'm wondering how mutt knows that it needs to take its information from this variable. BTW, I ended up making a list for the MUA I was trying out. I cleaned things up and found I got 173 maildirs. I converted the list so that mutt can use it. Now things would be a lot easier to find if mutt had a hierarchical display for the mailfolders. I hope I can at least turn off the sorting, but I haven't looked into that yet. And it would require that there are exclusively maildirs in the directory you supply as parameter to the script because it doesn't distinguish between maildirs and directories. That's a distinction a script needs to make. Well, it was a quick script I wrote for *my* purposes. Sorry, I didn't mean to complain. Don't get me wrong, I was only trying to explain what a script would need to do. Maybe I should try to write one, could be fun. If you run mboxes instead of maildirs, you'd want to look for files and ignore directories, instead of vice-versa. Yeah --- but it's only that I have an old mbox file or two around from before I switched to maildir. The first MUA I tried on Linux was pine ... I think I also tried elm, but I wasn't happy with them. Then I found out that there's mutt. That must have been around 1993--1995. Thanks to mutt, I've never lost a mail. It has always been reliable. That's awesome work the developers are doing. Thanks! Furthermore, I believe for a technically correct maildir structure, you shouldn't have subdirectories in that top level folder. See: http://wiki.mutt.org/?MuttFaq/Maildir Ah, I have what they show under point 2. custom layout of separate Maildirs, the bottom version. When cleaning up, I found a directory that was a maildir but contained other maildirs instead of mails, so I changed that. Having maildirs that also contain other maildirs or directories isn't a good idea. I wanted to keep my mail compatible with an IMAP server if I so chose, so I am using the #1 suggestion in the link. So I have 'subfolders' named like so: work.misc work.proj1 Hm. Does it really matter? When you transfer the mail to IMAP, how do you create the folders on the IMAP server? A script to automatically set up the mailboxes would have to check all directories under ~/Mail and create mailbox statements for only those that are maildirs. See above. Not an issue in my case. Feel free to modify the code to suit your purposes. If you have a limited number of folders, you could always just call the code multiple times: Thanks! But I don't know python --- I might try where I get to with a bash script, maybe using find ... But now that I have the list, I could try to keep them up to date.
Re: xemacs qyestion
On Mon, Jul 20, 2009 at 01:33:23PM +0200, Joost Kremers wrote: On Thu, Jul 16, 2009 at 09:14:22PM -0600, lee wrote: That's what I mean: How do you know all that? years of using emacs... ;-) i follow two emacs-related newsgroups, i regularly consult emacs documentation, i read the wiki http://www.emacswiki.org/, i experiment, that sort of thing. Ha, it can be very frustrating. When you want to do a simple thing, you don't want to spend years on following newsgroups and reading documentation and testing. I've been using emacs for a very long time, but never got to using it for more than an editor ... The good thing is that if I want it to do something, there's usually a solution that can do it better than I would have thought of --- but the problem is to find out how to get it to do what I want. emacs has a lot of built-in documentation. just check out the help function by typing 'C-h ?'. There's something wrong with the documentation I have. I seem to be missing at least some info packages, and I haven't found out yet which package I need to install to get all the documentation. I'm sure it's somewhere there, just not installed.
Re: xemacs qyestion
On Mon, Jul 20, 2009 at 01:29:24PM +0200, Joost Kremers wrote: On Thu, Jul 16, 2009 at 09:23:54PM -0600, lee wrote: Oh? The post-mode worked just fine once I installed the package. If there was something added to the configuration, the package management must have done that for me. probably. gnu emacs doesn't have such package management... But Debian does :) Thanks for the offer! It's working now --- if flyspell-mode only turns on after the first mail I'm editing, well, I can live with that :) that's still weird, though... but i'm not sure what might be going on there... I guess it was just me. It doesn't seem to wait for the second message to edit now :)
Re: split display?
On Mon, Jul 20, 2009 at 03:16:25PM -0400, Tim Gray wrote: On Mon 20, Jul'09 at 1:02 PM -0600, lee wrote: Oh. I was trying the script from the command line just to see what it would do, and it didn't produce any output. Hmm, when I call the script here from the command line, I get an output like +mailbox1 +mailbox2 +mailbox3. Maybe some sort of print statement was missing (cut off). If I wanted to run an IMAP server on my computer, so my maildirs were accessible to other mail clients (say a GUI client that couldn't read maildir), then I need to make sure my mail folder can be used directly with the IMAP server, serving those files directly. Is there an IMAP server that can handle maildir? I'd use Cyrus, it uses a storage format similar to maildir, and it's fast and reliable. But you'd have to move/copy the mails to the IMAP server unless you'd write a script to convert them to Cyrus' storage format.
Re: split display?
On Mon, Jul 20, 2009 at 07:24:48PM -0400, Tim Gray wrote:
On Mon 20, Jul'09 at 4:54 PM -0600, lee wrote:
Maybe some sort of print statement was missing (cut off).
Yeah I probably left it off or something. It should look something like
this:
for i in dirs:
print '+l/%s' % i,
Thanks! But see below ...
Is there an IMAP server that can handle maildir?
I've not done it yet, but it was my understanding that UW-IMAP and
Dovecot at least both serve from maildir. I think Courier might as well.
Now that would be cool! It's been a few years since I looked for one,
and I didn't find any that were able to use maildir.
Ok, I wrote a program to generate mailboxes lines for mutt. It will
print out those lines on stdout; errors and warnings go to
stdout.
Considered as maildirs are directories that have the subdirectories
cur, new and tmp. If the program finds such a directory, it prints a
mailbox line. In case it finds other directories and that directory,
it prints a warning to stdout. It looks like this:
l...@cat:~/src/c/systools/mutt-mailboxes$ ./mutt-mb .
mailboxes = /home/lee/src/c/systools/mutt-mailboxes/rel/tmaildir
warning: 1 strange directory/-ies found in
/home/lee/src/c/systools/mutt-mailboxes/rel/tmaildir
l...@cat:~/src/c/systools/mutt-mailboxes$
If you have an extremely deep directory hierarchy and a low ulimit -s,
the program can run into a stack overflow because it operates recursively.
Here's the program. Let me know how you like it :)
// check a directory hierachy for maildir directories recursively; print
// mailbox commands that can be used for mutt
// error messages are printed to stdout
// print a warning to stderr when there are other directories
// than cur, new, tmp found in a maildir
//
// (c) H. Wilmer, Mon Jul 20 17:17:45 MDT 2009
// l...@yun.yagibdah.de
// licensed under the GNU GENERAL PUBLIC LICENSE
// use at your own risk
//
// to compile: # gcc mutt-mb.c -o mutt-mb -O2
//
// version 0.1
//
// mutt-mb.c
// returns !0 on error
#include stddef.h
#include stdlib.h
#include stdio.h
#include dirent.h
#include string.h
#include unistd.h
#include errno.h
// proto
int main(int argc, char *argv[] );
extern void usage();
int weed_out_nondirectories(const struct dirent *);
int scan_directory(char *dirp);
void usage() {
fputs(usage: mutt-mb [directory]\n, stderr);
fflush(stderr);
}
// filter function, see man 3 scandir
int weed_out_nondirectories(const struct dirent *de) {
// weed out non-directories
if(de-d_type != DT_DIR) {
return 0;
}
// weed out directory pointers
if( !strcmp(de-d_name, .) ) {
return 0;
}
if( !strcmp(de-d_name, ..) ) {
return 0;
}
// it's a directory
return 1;
}
int scan_directory(char *dirp) {
static int recursion_level = 0;
struct dirent **namelist;
int scan = -1, check = 0;
int ret = 0;
int cwd = -1;
char *this;
int found_cur;
int found_new;
int found_tmp;
int found_other;
// change into the directory
cwd = chdir(dirp);
if(cwd 0) {
fputs(dirp, stderr);
perror(chdir);
return 2;
}
// and find out where we are
this = getcwd(NULL, 0);
if(this == NULL) {
perror(getcwd);
// this shouldn't happen, so rather exit
return -1;
}
// scan this directory
check = scan = scandir(this, namelist, weed_out_nondirectories, alphasort);
if(scan 0) {
perror(scandir);
free(this);
return 1;
}
// check if this is a maildir
found_cur = 1;
found_new = 1;
found_tmp = 1;
found_other = 0;
while(check--) {
//printf(check %s/%s\n, this, namelist[check]-d_name);
if(found_cur) {
found_cur = strcmp(cur, namelist[check]-d_name);
} else {
found_other++;
}
if(found_new) {
found_new = strcmp(new, namelist[check]-d_name);
} else {
found_other++;
}
if(found_tmp) {
found_tmp = strcmp(tmp, namelist[check]-d_name);
} else {
found_other++;
}
if( !found_cur !found_new !found_tmp) {
// it's a maildir
printf(mailboxes = %s\n, this);
found_other -= 3;
if(found_other) {
fprintf(stderr, warning: %5d strange directory/-ies found in %s\n, \
found_other, this);
}
}
}
free(this);
// for each directory in this, look for subdirectories
while(scan--) {
recursion_level++;
ret = scan_directory(namelist[scan]-d_name);
switch(ret) {
case 0:
// means ok
// there shouldn't be any errors ...
break;
case 2:
fputs(couldn't change into subdirectory\n, stderr);
fflush(stderr);
return 2;
break;
case -1:
fputs(coulnd't find out what the current directory is\n, stderr);
fflush(stderr);
return -1;
break;
case 1:
fputs(couldn't scan a directory\n, stderr);
fflush(stderr);
return 1;
break;
case -2:
fputs(couldn't change back to directory above\n, stderr);
fflush(stderr
program to generate mailboxes lines (Re: split display?)
On Mon, Jul 20, 2009 at 10:11:15PM -0600, lee wrote:
Here's the program. Let me know how you like it :)
Hn, one small adjustment: The recursion level is irrelevant, but I
forgot to remove the counter.
// check a directory hierachy for maildir directories recursively; print
// mailbox commands that can be used for mutt
// error messages are printed to stdout
// print a warning to stderr when there are other directories
// than cur, new, tmp found in a maildir
//
// (c) H. Wilmer, Mon Jul 20 17:17:45 MDT 2009
// l...@yun.yagibdah.de
// licensed under the GNU GENERAL PUBLIC LICENSE
// use at your own risk
//
// to compile: # gcc mutt-mb.c -o mutt-mb -O2
//
// version 0.2
//
// mutt-mb.c
// returns !0 on error
#include stddef.h
#include stdlib.h
#include stdio.h
#include dirent.h
#include string.h
#include unistd.h
#include errno.h
// proto
int main(int argc, char *argv[] );
extern void usage();
int weed_out_nondirectories(const struct dirent *);
int scan_directory(char *dirp);
void usage() {
fputs(usage: mutt-mb [directory]\n, stderr);
fflush(stderr);
}
// filter function, see man 3 scandir
int weed_out_nondirectories(const struct dirent *de) {
// weed out non-directories
if(de-d_type != DT_DIR) {
return 0;
}
// weed out directory pointers
if( !strcmp(de-d_name, .) ) {
return 0;
}
if( !strcmp(de-d_name, ..) ) {
return 0;
}
// it's a directory
return 1;
}
int scan_directory(char *dirp) {
struct dirent **namelist;
int scan = -1, check = 0;
int ret = 0;
int cwd = -1;
char *this;
int found_cur;
int found_new;
int found_tmp;
int found_other;
// change into the directory
cwd = chdir(dirp);
if(cwd 0) {
fputs(dirp, stderr);
perror(chdir);
return 2;
}
// and find out where we are
this = getcwd(NULL, 0);
if(this == NULL) {
perror(getcwd);
// this shouldn't happen, so rather exit
return -1;
}
// scan this directory
check = scan = scandir(this, namelist, weed_out_nondirectories, alphasort);
if(scan 0) {
perror(scandir);
free(this);
return 1;
}
// check if this is a maildir
found_cur = 1;
found_new = 1;
found_tmp = 1;
found_other = 0;
while(check--) {
//printf(check %s/%s\n, this, namelist[check]-d_name);
if(found_cur) {
found_cur = strcmp(cur, namelist[check]-d_name);
} else {
found_other++;
}
if(found_new) {
found_new = strcmp(new, namelist[check]-d_name);
} else {
found_other++;
}
if(found_tmp) {
found_tmp = strcmp(tmp, namelist[check]-d_name);
} else {
found_other++;
}
if( !found_cur !found_new !found_tmp) {
// it's a maildir
printf(mailboxes = %s\n, this);
found_other -= 3;
if(found_other) {
fprintf(stderr, warning: %5d strange directory/-ies found in %s\n, \
found_other, this);
}
}
}
free(this);
// for each directory in this, look for subdirectories
while(scan--) {
ret = scan_directory(namelist[scan]-d_name);
switch(ret) {
case 0:
// means ok
// there shouldn't be any errors ...
break;
case 2:
fputs(couldn't change into subdirectory\n, stderr);
fflush(stderr);
return 2;
break;
case -1:
fputs(coulnd't find out what the current directory is\n, stderr);
fflush(stderr);
return -1;
break;
case 1:
fputs(couldn't scan a directory\n, stderr);
fflush(stderr);
return 1;
break;
case -2:
fputs(couldn't change back to directory above\n, stderr);
fflush(stderr);
return -2;
break;
}
free(namelist[scan]);
}
free(namelist);
cwd = chdir(..);
if(cwd 0) {
perror(chdir);
// shouldn't happen
return -2;
}
return 0;
}
int main(int argc, char *argv[] ) {
int ret = 0;
// check args
if(argc != 2) {
usage();
exit(1);
}
// scan the directory
ret = scan_directory(argv[1]);
if(ret) {
fprintf(stderr, error: %d\n, ret);
exit(ret);
}
exit(0);
}
Re: split display?
On Mon, Jul 20, 2009 at 09:39:27PM +0100, Christian Ebert wrote: The following could be a start, it came up in comp.mail.mutt: mailboxes `find ~/Mail -type d \( \( -name cur -o -name new -o -name tmp \) -prune -o -print \) \ | tr '\n' ' '` (if your find has -printf you can get rid of the tr call) It still lists directories that contain Maildirs, haven't found an elegant way to get rid of those. Personally I just use printf. The find I have does have printf ... I took a look at that, but it's easier for me to write a program in C for this than to figure out how to do it with find :) I've posted it in this thread; maybe you have use for it. It's non-trivial, but pretty elegant --- I love C ... (BTW, the counter for strange directories in the program dosn't count right; I've changed it so that the number doesn't get printed anymore. It would be somewhat tricky to get it to count right. But it doesn't matter much, it's working.) To update your mailboxes you could put that command in a file and then have a macro that does something like unmailboxes * ; source mailboxes.muttrc Maybe it's possible to somehow pipe the output of the program into mutt so that a file with mailboxes lines isn't even needed. I'll see if I can find that out ...
setting mailboxes from the output of a command
Hi, how do you set mailboxes from the output of a command? The documentation says: my_hdr X-Operating-System: `uname -a` The output of the Unix command ``uname -a'' will be substituted before the line is parsed. Note that since initialization files are line oriented, only the first line of output from the Unix command will be substituted. Now I tried: mailboxes = `/src/c/systools/mutt-mailboxes/mutt-mb /home/lee/Mail` But that doesn't work. Is there a limit on how long the output can be? It's 5418 characters. I can modify the output of the program, like to generate many complete mailboxes lines, or to generate a long line listing all the mailboxes. Generating mailboxes lines probably won't work because mailboxes is already specified in the .muttrc. How do I set the mailboxes from the command output? I don't want to use a file with mailboxes lines and source that.
Re: setting mailboxes from the output of a command
On Mon, Jul 20, 2009 at 11:22:03PM -0600, lee wrote: How do I set the mailboxes from the command output? I don't want to use a file with mailboxes lines and source that. Never mind, I found that the program to run must be in the path. It's working now: mailboxes = `mutt-mb /home/lee/Mail`
Re: multipart/alternative question
At Sun, 19 Jul 2009 04:50:05 +0100, Noah Slater wrote: 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. 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. Ah, I see what you mean. But aren't RFCs prescriptive by nature? And if they are, it's silly to say that a statement resulting of an interpretation of an RFC is absurdly prescriptive. --- The interpretation can be wrong, but that's another question. A simple email message doesn't have any HTML components. That depends on what you mean by simple sure does 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. I don't see how invalid results could support a hypothesis based on them. If you ask 100 people the way to the museum while having a hypothesis that you should go to the right and about 90 of them tell you that they don't know what you're talking about, would you think that the answer you got from those 90 people supports your hypothesis? Or would you rather ignore their answers?
Re: multipart/alternative question
At Sun, 19 Jul 2009 14:54:15 -0500, Kyle Wheeler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Saturday, July 18 at 02:41 PM, quoth lee: 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? Perhaps we should make a feature request? Well, I was thinking that it might be possible using tags and piping with a slick perl script, that you could glue together with a macro.. Yeah, IIRC, there are perl libraries to handle mime things. Or you could always make some bash script that uses one of the softwares that can handle mime, like metamail, to send a whole folder out as a message. Another script could handle unpacking the message. Speaking of which, I sometimes wished that I could just attach a whole folder instead of having to attach all the files separately. You *can* do the tag-and-attach approach. Saves time over attaching each file independently. I know, but I just happend to try to attach the whole folder somethimes without thinking and then found that I can't ... So where's the full MUA support of the mime stuff? Good question. For what it's worth, another way to segment large files (or collections of files) is to use the shell utility `split` Not exactly *convenient*, though... but unless your recipient is using Outlook Express, there's not much point in using a MIME trick that they can't take advantage of. Hm. I wonder what mutt --- or wanderlust, which I'm trying out now --- would do with messages containing parts of files. You might be able to save something from each message but then be left with the problem of having to figure out how to put the pieces together. English has its trade-offs, like most things. While it is a bit sloppy and leaves a lot up to interpretation, that leads to lots of fun double- or triple-entendres (which has benefits in the realms of poetry, humor, and other forms of literature), and lets us use nouns as verbs, among other things. By not requiring the speaker to make distinctions about everything, it leaves a lot more room for interpretation, which is both liberating and frustrating for the exact same reason. That's probably true for other languages as well, in one way or another, to a greater or lesser extent. I wonder if there's a German translation of that RFCs --- it's probably extremely difficult to translate if the interpreter was to transcribe what it's supposed to mean to the full extent ... I've always been reading things like that in English, even when there was a translated version available. It's a lot easier because the translations ignore that the original originates from a totally different mindset, which makes them hard to understand and sometimes even incomprehensible. For example, there is no German word for segmentation fault. It is not translatable not only because there isn't a word for it, there's also no concept for it. Interpreters confronted with the problem of translating it made something up, but it is nonsense. It's like trying to explain to a blind person what colors look like. When you watch German TV, you start asking yourself where you are because like half the words are English. They do that to make what they are saying to appear important, and the less they know what they are trying to say, the more English words they (ab-)use. It's really awful --- but nobody would ever say segmentation fault.
Re: split display?
At Sun, 19 Jul 2009 19:41:24 -0500, Derek Martin wrote: [1 text/plain; iso-8859-1 (7bit)] On Fri, Jul 17, 2009 at 02:03:44PM -0600, lee wrote: 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. No, I do not agree to any such thing. It gets clunky when you try to manage arbitrary folders that you're creating and removing on the fly, That is exactly the sort of flexibility needed. Why, for example, doesn't mutt recognize a folder I'm creating when I'm saving a mail into a new folder? It'll ask me nicely if I want to create the folder, but that's all. That's the way to go when you want to lose track of your folders and mail. I am (was --- I'm trying out another MUA now) using mutt to administer my mail. I wasn't using an editor to administer my mail, which you need to do when using mutt because you have to keep adjusting the config. It's only a small detail, but it makes mutt awkward. Have you ever considered that the arrangement of categories you're selecting is just too complicated? You can either choose your categories carefully, perhaps somewhat broadly, so that you never (or at least very rarely) need to add or remove any folders... The arrangement isn't complicated at all. Using the thread-marking-and-linking workaround, I created eight plain categories and assigned some mails to them. The categories are going to stay a while. I could have used folders instead, but mutt wouldn't recognize the folders (unless I edited the config); it wouldn't distinguish the categories from folders and it wouldn't keep the categories visible at hand in the inbox. One wonders what kind of e-mail you're receiving that you need to have so many categories... Who says that I have many categories? You get a bill that doesn't fit into one of the folders you already have... What do you do? put it somewhere where it probably gets lost and I probably won't remember after a while However, it wouldn't happen. When bills cannot be processed, the company doesn't get money. Removing folders is not supported, renaming them isn't either. Mutt can only do either of those operations safely if all of the follwing are true: 1) No mail is being delivered to the folder in question. It depends on how mail is being delivered. 2) The new name chosen is on the same physical device and partition as the current one. Huh? 3) #2 also applies for deletes, because deleting a directory is not an atomic operation, so you need to rename the directory first. Huh?? Mutt can never reliably determine #1. Mutt often can not determine the others I'm telling you all the time that it doesn't need to determine anything. It's the user deleting a maildir --- he can use a shell, a file manager or whatever. But he can't use his MUA because the MUA doesn't provide a way to delete a maildir. That's silly. However the user deletes a maildir, he can do that safely or not. You're basically arguing that a shell (or rm) or file managers shouldn't allow anyone to delete or move maildirs because they can't do that safely. But if you add the feature to Mutt, people will use it, even if you tell them it's not safe, and some people will lose mail, and complain. So, if you're a Mutt maintainer, you've got to be crazy to add a feature like this. If you add a feature to delete files to a file manager, people will use it, even if you tell them it's not safe, and some people will lose files, and complain. So, if you're a file manager maintainer, you've got to be crazy to add a feature like this. Well, are you now saying that mutt is supposed to be used with only one mail folder? Eh? I think there may be some language barrier here... I'm not sure how put your folders [- note the plural folders] in your config got interpreted as use only one folder... They're not even close. What you are saying is that I shouldn't use folders --- because maildirs are static and never to be changed and must not have hierarchies --- but that I should use folders to simulate categories which can more or less frequently change and which don't persist indefinitely. Perhaps there's some misunderstanding here? I keep saying that I don't want to use folders to simulate categories because folders are not suited for that for a number of reasons. You keep saying that folders are not suited to simulate categories for a number different reasons than the ones I have but that I should use them to simulate categories. Ok, that makes some sense. Still it could show me what is what after I tell it which folders are a maildir. It does. If you specify them with mailboxes, they're listed separately in one of the file browser screens from any other files in your directory tree. Unless there's a screen I haven't seen yet, that screen shows only the folders I have told mutt
Re: split display?
At Sun, 19 Jul 2009 22:16:23 -0400, Tim Gray wrote: Fair enough. Well, if you are interested, I've attached the code below between the dashes. I'm assuming you have python installed. Save it wherever you want and name it whatever you want. If you want specific folders ignored, add them in the ignore statement. Then add the following line to your muttrc file: mailboxes `/path/to/script/listbox.py /path/to/mail/folders` Thanks! Doesn't that need to produce some output, or does mutt have a way to assign the content of dirs from the script to mailboxes? And it would require that there are exclusively maildirs in the directory you supply as parameter to the script because it doesn't distinguish between maildirs and directories. That's a distinction a script needs to make. What I have is like: ~/Mail ARCHIVE # directory containing maildirs and/or files or directories Maildir # that's the inbox lists # directory containing maildirs mutt-users debian-user ... drafts spam trash Per # directory containing maildirs and/or files or directories ARCHIVE # directory containing maildirs and/or files or directories person-1 person-2 ... Gov # directory containing maildirs and/or files or directories ... Com # directory containing maildirs and/or files or directories ... file-1 file-2 logfile mboxfile ... A script to automatically set up the mailboxes would have to check all directories under ~/Mail and create mailbox statements for only those that are maildirs.
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: 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 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: 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
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: 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
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: 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: 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: 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: 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: 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.
Re: multipart/alternative question
On Thu, Jul 16, 2009 at 12:31:26AM -0400, Tim Gray wrote: On Wed 15, Jul'09 at 10:08 PM -0600, lee wrote: And more general, is there a way to get an indication that a mail does have an attachment or attachments? I would give them a different color in the list; that would prevent me from opening such messages without checking them before. You could set up a coloring rule using the ~X matching pattern. Something like: color index red default ~X 1- should work. Hm, I was reading the manual, and there's an object attachment that can be used with color. But I don't understand what that is for: color attachment brightred black doesn't do what I thought it might. You can also use the %X sequence in your index_format definition to display the number of attachments in a message. However, I don't think either of those methods pick up on inline attachments. Hm, I would expect that attachments are attachments and count as such ... I 1 no description [multipa/alternativ, 7bit, 2.0K] I 2 no description [text/plain, quoted, iso-8859-1, 0.7K] I 3 no description [text/html, quoted, iso-8859-1, 1.0K] I 4 no description [text/plain, 7bit, us-ascii, 0.2K] For that one, %X says the mail has 1 (one) attachment. But apparently it has 4 attachments, so what's %X for? Other than that, if I get a mail that isn't readable, I delete it. If someone sends me a mail but makes it difficult to read, he obviously doesn't care if I read it or not, so why should I waste my time with it. Unfortunately I have collaborators whom I must work with who aren't particularly email savvy. I can't just toss their emails. Perhaps you can help them to fix their MUAs? If you can find out if what they are doing is compliant with RFCs or not, you could act accordingly. Unfortunately that's a difficult task, but if they are compliant, you need to change something on your side. It's hard to examine the problem without having an example email ... What happens when you notice that you got such a mail and have mutt display what attachments there are? Can you view the attachments from there?
Re: split display?
On Thu, Jul 16, 2009 at 12:55:34PM -0500, Derek Martin wrote: On Thu, Jul 16, 2009 at 09:34:49AM -0500, Derek Martin wrote: You could say that mutt is designed to handle a lot of mail and each mail individually, accessible through a list of mails. That you can switch to different folders is not actually supported and only merely possible. I have no idea what you're talking about. I think you just don't know how to use Mutt properly... FWIW, this sort of comment (and possibly other things I wrote) may come off sounding insulting, but that wasn't my intent. I just mean to say that it sounds like you may not be aware of all of Mutt's functionality regarding handling different mail folders, and maybe the reason you think that handling your mail this way won't work for you is more because of that than any technical deficiency... Yeah, I know what you mean, happens to me, too. Maybe what I'm looking for can be done and I don't know it. Can it?
