Re: Sidebar keys
On Mon, May 04, 2009 at 06:24:34PM EDT, Derek Martin wrote: On Mon, May 04, 2009 at 06:10:32PM -0400, Chris Jones wrote: After 3 year, why has it not been integrated to mainstream code? [...] As to the 'why?', this should give you an idea: http://article.gmane.org/gmane.mail.mutt.user/31390 You mean the changelog at the top that metntions a few bugs and the date they were corrected..? I think you're looking at the wrong link. The link above explains in some detail why the patch was rejected (and AFAIK still remains true). OK. That explains it.
Re: Check folders in an alphabetical way
Aiko [05.Mai.2009 10:33]: To be precise: The 'c' (change-folder) key shall return the next folder in alphabetical order. For example: =INBOX/servers/mail01 =INBOX/servers/mail02 I am not familiar with IMAP folders, but isn't that the usual behavior with for example maildirs? After new mail is delivered into my directories, pressing 'c' defaults to the next dir in alphabetical order: Ebay - Listen/Mutt - Listen/Procmail - Spam etc. Might it be that you are directed to an email due to its arrival date other than folder location? Just a thought. JP
Re: [Solved?] mailing lists and gmail with mutt
On Sat, May 02, 2009 at 08:55:41AM +0200, Nicolas Sebrecht wrote: Recently, I moved one of my email address to gmail. The problem is that Google thinks it's a good idea to not show what _they_ consider to be duplicated mails. I have one folder per mailing list. When I send/receive emails to a mailing list, I expect to have a copy into my INBOX and another copy into the dedicated folder (e.g. the sender did To: list-address Cc: me ) Also, I'm filtering emails with imapfilter. The rules are based on fields like List-Id. What's happening quite often is that when somebody answers (both to a mailing list and me), the first message I receive is that which addressed to me. As the second mail is not downloaded, it breaks the threads in the folder of the mailing list. There seems to be a workaround. Instead of basing the filter rules against the List-Id field, imapfilter can easily parse both the Cc: and To: headers (contain_cc() and contain_to()) and copy the mails to the good folder (copy_messages()). I expect it should work but as the folders are labels at Google, I can't say. I didn't tested and probably won't because I've already switched to gmx. -- Nicolas Sebrecht
problem with Mime headers
During searching for a way to pretty print my Emails from mutt I found, that all messages (or at least the message under concern) are stored from ISO-8859-1 to quoted-printable. I tried various converters, especially recode and recode is complaing about some ungueltige Eingabe in data. (when I type =FC into stdin, recode behaves brave and issues an u-umlaut), so it's not the needs getting used to command line syntax of recode. Anyway, looking closer to the stored message I find this: |This message is in MIME format. Since your mail reader does not understand |this format, some or all of this message may not be legible. | |--Boundary_(ID_nSHaJBsO42WhPK/6brziZw) |Content-type: multipart/alternative; |boundary=Boundary_(ID_MKUMWPz0I4J+Cb9RfTtFtg) | | |--Boundary_(ID_MKUMWPz0I4J+Cb9RfTtFtg) |Content-type: text/plain; charset=iso-8859-1 |Content-transfer-encoding: quoted-printable Then the quoted printable message text follows with the next message boundary. My questions are: \1 What mechanism causes mutt to produce a quoted printable encoded copy of the message, when I save the file? \2 When I view the message in mutt, umlauts are shown as two byte characters, e.g. an u-umlaut is represented as \374. Would be nice, mutt would do that right away with the correct character set. Only when invoking the editor (vi) to write a reply, the characters are shown correctly. -- Christoph
Re: problem with Mime headers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday, May 5 at 01:32 PM, quoth Christoph Kukulies: During searching for a way to pretty print my Emails from mutt I found, that all messages (or at least the message under concern) are stored from ISO-8859-1 to quoted-printable. I don't understand... you mean they're *converted* into quoted-printable from ISO-8859-1? I tried various converters, especially recode and recode is complaing about some ungueltige Eingabe in data. (when I type =FC into stdin, recode behaves brave and issues an u-umlaut), so it's not the needs getting used to command line syntax of recode. I'm pretty sure recode is not what you want. My *guess* is that you have unset $print_decode, so mutt is passing raw message data to your $print_command. If you set $print_decode, mutt should convert all output into $charset as it gets passed to $print_command. My questions are: \1 What mechanism causes mutt to produce a quoted printable encoded copy of the message, when I save the file? None. Let me clarify: when you save a copy of a message somewhere, mutt leaves it AS IS (unless you use something like decode-save). So if the message was encoded with quoted-printable to begin with, it will stay that way. \2 When I view the message in mutt, umlauts are shown as two byte characters, e.g. an u-umlaut is represented as \374. Would be nice, mutt would do that right away with the correct character set. Only when invoking the editor (vi) to write a reply, the characters are shown correctly. Technically, that's not a question. ;) But if mutt is displaying umlauts as byte-codes (e.g. \374) instead of as an umlaut or even as a masked unprintable character (displayed as a question mark), then your charset environment is incorrectly configured. Let me guess, you set $charset manually, don't you. (Hint: that's almost always the wrong thing to do, for lots of reasons.) Step 1: stop setting $charset Step 2: set up your LANG environment variable correctly Possible Step 3: correctly configure your terminal ~Kyle - -- I think we ought always to entertain our opinions with some measure of doubt. I shouldn't wish people dogmatically to believe any philosophy, not even mine. -- Bertrand Russell -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkoAVQwACgkQBkIOoMqOI14LxACgw/qx8gVs3NDg8276Y2EUXom6 Mz0AmQEVnCdDTDoefCbXHNWUPbzcHLvn =dg0V -END PGP SIGNATURE-
Re: problem with Mime headers
Kyle Wheeler schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday, May 5 at 01:32 PM, quoth Christoph Kukulies: During searching for a way to pretty print my Emails from mutt I found, that all messages (or at least the message under concern) are stored from ISO-8859-1 to quoted-printable. I don't understand... you mean they're *converted* into quoted-printable from ISO-8859-1? Yes, they are converted to quoted printable in the saved file. I tried various converters, especially recode and recode is complaing about some ungueltige Eingabe in data. (when I type =FC into stdin, recode behaves brave and issues an u-umlaut), so it's not the needs getting used to command line syntax of recode. I'm pretty sure recode is not what you want. My *guess* is that you have unset $print_decode, so mutt is passing Yes, that's the case. I don't have $print_decode. raw message data to your $print_command. If you set $print_decode, mutt should convert all output into $charset as it gets passed to $print_command. My questions are: \1 What mechanism causes mutt to produce a quoted printable encoded copy of the message, when I save the file? None. Let me clarify: when you save a copy of a message somewhere, mutt leaves it AS IS (unless you use something like decode-save). So if I don't have anything special WRT saving. But mutt definitely doesn't save the message as is. At least I think so. I would have to fish out the message next time from my inbox before mut gets hold on it. OK, here is the content of the message from /var/spool/mail: Dies ist ein Test mit Ãmläuten This is how it shows in a mutt terminal window (putty): Dies ist ein Test mit \334ml\344uten And in the save message Dies ist ein Test mit Ãmläuten OK, no conversion took place, you're right. Strange though that the multipart mime-encoded message was converted (or did it arrive already that way?) I cannot reproduce that case at the moment. the message was encoded with quoted-printable to begin with, it will stay that way. \2 When I view the message in mutt, umlauts are shown as two byte characters, e.g. an u-umlaut is represented as \374. Would be nice, mutt would do that right away with the correct character set. Only when invoking the editor (vi) to write a reply, the characters are shown correctly. Technically, that's not a question. ;) But if mutt is displaying umlauts as byte-codes (e.g. \374) instead of as an umlaut or even as a masked unprintable character (displayed as a question mark), then your charset environment is incorrectly configured. Let me guess, you set $charset manually, don't you. (Hint: that's Yes, in .muttrc I have : set charset=iso-8859-1# character set for your terminal That's my output of locale: LANG=de_DE.UTF-8 LANGUAGE=de_DE:de:en_GB:en LC_CTYPE=de_DE.UTF-8 LC_NUMERIC=de_DE.UTF-8 LC_TIME=de_DE.UTF-8 LC_COLLATE=de_DE.UTF-8 LC_MONETARY=de_DE.UTF-8 LC_MESSAGES=de_DE.UTF-8 LC_PAPER=de_DE.UTF-8 LC_NAME=de_DE.UTF-8 LC_ADDRESS=de_DE.UTF-8 LC_TELEPHONE=de_DE.UTF-8 LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=de_DE.UTF-8 LC_ALL= almost always the wrong thing to do, for lots of reasons.) Step 1: stop setting $charset Step 2: set up your LANG environment variable correctly Possible Step 3: correctly configure your terminal ~Kyle Thanks. -- Christoph
folder-hook commands
Hello! I have a problem using a command in folder-hooks. I wnat to read a config file using folder-hooks: folder-hooks: folder-hook . set sort = reverse-date-received folder-hook = freebsd-current source ~/.mutt/defaults.maillist defaults.maillist: set sort = threads set strict_threads = yes set collapse_unread = yes set uncollapse_jump = yes Using this i get unknown command when i open the mailbox. Is it not possible to use source in folder-hooks? If not how can i configure it to get it working? Thanks in advance Alex
Re: problem with Mime headers
* On Tue, May 05, 2009 05:33PM +0200 Christoph Kukulies (k...@kukulies.org) muttered: Yes, in .muttrc I have : set charset=iso-8859-1# character set for your terminal That's my output of locale: LANG=de_DE.UTF-8 LANGUAGE=de_DE:de:en_GB:en LC_CTYPE=de_DE.UTF-8 Why charset iso-8859-1 but utf-8 locales? Let mutt autodetect $charset, or at least don't let charset differ from your locales. HTH, Michael -- To the systems programmer, users and applications serve only to provide a test load. PGP-Key-ID: 0xDC1A44DD Jabber: init...@amessage.de
Re: folder-hook commands
On 2009-05-05, Alex Huth wrote: Hello! I have a problem using a command in folder-hooks. I wnat to read a config file using folder-hooks: folder-hooks: folder-hook . set sort = reverse-date-received folder-hook = freebsd-current source ~/.mutt/defaults.maillist defaults.maillist: set sort = threads set strict_threads = yes set collapse_unread = yes set uncollapse_jump = yes Using this i get unknown command when i open the mailbox. Is it not possible to use source in folder-hooks? If not how can i configure it to get it working? The folder-hook command is expecting to see the command as a single argument. Therefore, if the command includes any whitespace, the command must be enclosed in quotes, or the whitespace otherwise removed. With that change, your hooks would become: folder-hook . set sort=reverse-date-received folder-hook =/freebsd-current source ~/.mutt/defaults.maillist I removed the spaces surrounding the = in the set command because the manual doesn't indicate that spaces are allowed there. I also added a / in the folder name of the second folder-hook, assuming that one belongs there. HTH, Gary
