Bug#339555: mutt: Segmentation fault when displaying a iso8859-1 mail header
On Tuesday, November 29, 2005 at 8:59:01 +0800, WANG Xu wrote: > the segfault occured even in: >| LANG=en_US >| LC_CTYPE=zh_CN.GBK The charset of all the categories must be the same as the terminal, or strictly compatible. In your case only GBK or US-Ascii. That en_US having an implicit Latin-1 charset is conflicting: You should remove LC_CTYPE, and set back LANG=zh_CN.GBK. Does it still segfault? Yes. Now try with "set thorough_search=yes" in muttrc. Does it still segfault? Not anymore? > I am sorry for the annoying No problem, GDB is not an easy tool at first encounter. :-) > #0 0xb7d0b5ef in memcpy () from /lib/tls/libc.so.6 > #1 0xb7d3ca52 in re_set_registers () from /lib/tls/libc.so.6 > #2 0xb7d3cd15 in re_set_registers () from /lib/tls/libc.so.6 > #3 0xb7d5074a in re_compile_pattern () from /lib/tls/libc.so.6 > #4 0xb7d51beb in regexec () from /lib/tls/libc.so.6 > #5 0xb7daaf1c in regexec () from /lib/tls/libc.so.6 Looks like my hypothesis was not so bad. So it's another instance of glibc regexp invalid multibyte segfault, now in 2.3.5-6. Probably you can also segfault outside of Mutt, doing things like: | $ printf "\xE9" | grep "^Subject.*" If confirmed, probably this bug will have to be reassigned. ¿Dato? Bye!Alain. -- set honor_followup_to=yes in muttrc is the default value, and makes your list replies go where the original author wanted them to go: Only to the list, or with a private copy.
Bug#339555: mutt: Segmentation fault when displaying a iso8859-1 mail header
On Thursday, December 1, 2005 at 11:34:17 +0800, WANG Xu wrote: > On Tue, Nov 29, 2005 at 01:40:44PM +0100, Alain Bench wrote: >> remove LC_CTYPE, and set back LANG=zh_CN.GBK. > do you mean this: >| $ locale >| LANG=zh_CN.GBK >| LC_CTYPE= >| LC_ALL= Almost: Yet unset LC_CTYPE, or rather remove it from startup scripts. And verify LC_ALL is also really unset (and not set to empty string as was LC_CTYPE). >>| $ printf "\xE9" | grep "^Subject.*" > It print nothing by this line, nor by pring "\xE9" And what about: | $ printf "Rog\xE9rio\n" | egrep "^R.*" | $ printf "Rog\xA8\xA6rio\n" | egrep "^R.*" >> have to be reassigned. ?Dato? ^ Note my previous mail was ISO-8859-1, because of this one character before "Dato". Character U+00BF not existing in GBK, therefore masked by a question mark for you on display, and quoted in your reply. In these conditions, it didn't segfault. Bye!Alain. -- Mutt muttrc tip to send mails in best adapted first necessary and sufficient charset (version for Western Latin-1/Latin-9/CP-850/CP-1252 terminal users): set send_charset="us-ascii:iso-8859-1:iso-8859-15:windows-1252:utf-8" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339555: mutt: Segmentation fault when displaying a iso8859-1 mail header
On Saturday, December 3, 2005 at 10:39:57 +0800, WANG Xu wrote: >| $ export LC_ALL= The variable still exists, with an empty content. This should not (in theory), but could (in practice), perturbate things. To really remove those variables from environment do: | $ unset LC_ALL LC_CTYPE LANGUAGE >| LANG=zh_CN.GBK >| LC_CTYPE=C > It did not segfault, and print the iso char as: >| Rog\250\246rio Brito Steps: -1) Semething converted the E9 char from Latin-1 to GBK. -2) Mutt asked libc if the result is printable in current C locale. -3) Libc replied that A8 and A6 are not printable in US-Ascii. -4) Therefore Mutt printed octal escapes \250\246. The important point here is: How did original Latin-1 get converted to GBK. I mean: How could possibly Mutt know you use a GBK terminal. There are 2 cases: -a) You force "set charset=GBK" in muttrc: Remove this line. $charset must be free to follow the current locale, whatever it is. -b) Some filter does the conversion. Which one? > Did this mean 1) The library think this char is in GBK charset. Well a discrepency: Part thinks it's good GBK, part it's invalid US-Ascii. In a correct C setup, the display should be masked by one "?" (because the E9 byte does not exist in US-Ascii): | Rog?rio Brito > 2) This char cannot be found in my GBK fonts. It surely exists in font, because at shell you can see a "lowercase e with an acute accent" (a small slash above the e letter) doing: | printf "\xA8\xA6" BTW: On your GBK terminal, is it a "half-wide" character as Ascii e, or full-width as Chinese chars? > On Fri, Dec 02, 2005 at 08:40:19PM +0100, Alain Bench wrote: >> Character U+00BF not existing in GBK, therefore masked by a question >> mark for you on display, and quoted in your reply. In these >> conditions, it didn't segfault. > Sorry for the annoying. And hope we can solve it. Not annoying at all: This fact brings 2 small informations to the puzzle. Precious, as any other precisions you give us. I still don't get the full picture, since my best so far "invalid multibyte" hypothesis seems dead. Let's dig a little more, if you accept. On Saturday, December 3, 2005 at 10:46:03 +0800, WANG Xu wrote: >>| $ printf "Rog\xA8\xA6rio\n" >>| Rog[e acute]rio > This line sent by myself will lead to segfault when I try to review it While both your mails were perfectly valid UTF-8 mails. So the segfault is not only with ISO-8859-1 chars. Yet another small piece for the puzzle. :-) Hum... Random idea. Could you check: | $ printf "Rog\xE9rio\n" | iconv -f l1 -t wchar_t | iconv -f wchar_t -t gbk Bye!Alain. -- When you want to reply to a mailing list, please avoid doing so from a digest. This often builds incorrect references and breaks threads. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#177504: mutt/1441: can't of a message/rfc822 attachment ed in compose
Synopsis: can't of a message/rfc822 attachment ed in compose Comment added by ab on Tue, 01 Nov 2005 09:55:05 +0100 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#177504: mutt/1441: can't of a message/rfc822 attachment ed in compose
Synopsis: can't of a message/rfc822 attachment ed in compose Comment added by ab on Tue, 01 Nov 2005 10:00:38 +0100 crossref /2085 closed duplicate add /2085 reporter to notifieds retitle from inaccurate "Subject:view-header (v) does not work in forwarded message" deduppe unform -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336708: message-hook and patterns, [: invalid command
Hello Brian, and much thanks for the problem report! On Monday, October 31, 2005 at 20:23:01 -0500, Brian Clark wrote: > After upgrading to Mutt 1.5.11-2, when starting mutt, I get the error: >| Error in /home/brian/.mutt/rc.private, line 62: [: invalid command > Line 62 of /home/brian/.mutt/rc.private contains the following: >| message-hook "~h X-Spam-Status:.*hits=[0-9]+" "unignore X-Spam-Status" > Previously worked with 1.5.9. Confirmed problem with stock 1.5.11, while 1.5.9 and 1.5.10 do work. This might be due to the new =x string matching patterns, so perhaps bug should be upstreamed so Brendan can comment (if he's there). In the meantime, as a workaround, you can prepend the "=" with 2 backslashes, like this: | message-hook "~h X-Spam-Status:.*hits\\=[0-9]+" "unignore X-Spam-Status" This syntax is backward compatible. Bye!Alain. -- KW> Program received signal SIGSEGV, Segmentation fault. I'm not really here, but also try nuking your header cache. -- BC in "Real Programmers Don't Eat Cache on Holidays" -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339555: mutt: Segmentation fault when displaying a iso8859-1 mail header
Hello, and thank you very much for the report. On Thursday, November 17, 2005 at 11:24:20 +0800, WANG Xu wrote: > I am using mutt to read mailing list, and segfault occured sometimes. > And I found it will occur whenever the mail's ``From'' is in ISO8859-1 > encoding, and if I remove the ``=...='', content, segfault will never > occur. Unreproducable here: The From is partly displayed OK, partly masked by question marks (unconvertable chars). All OK. It crashes when: Displaying the index, opening the mail, or? Does it crash without muttrc (mutt -nF /dev/null)? Could you please: -1) Copy one such segfaulting message to a temporary mbox, gzip it, and send it here attached. Or if mail contains secrets, to me personally. -2) Let segfault create a core, gdb $(which mutt) core, then type "bt" and "quit". -3) What's the output of "locale" command? Bye!Alain. -- Give your computer's unused idle processor cycles to a scientific goal: The [EMAIL PROTECTED] project at http://folding.stanford.edu/>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339555: mutt: Segmentation fault when displaying a iso8859-1 mail header
On Monday, November 21, 2005 at 10:44:12 +0800, WANG Xu wrote: > The failed mail is attached as mailfail.gz It is a well-formed Latin-1 mail, with 1 e acute in "From:", and 2 in signature. As the e acute exists in GBK charset (printf "\xa8\xa6"), the mail should be perfectly displayed. > with `mutt -nF /dev/null', segfault occured when the latin-1 specific > char in the mail was displayed. I assume you mean the e acute in signature, or just before? So segfault in pager scrolled down to nearly the end. > While with the attached configure file `muttfail.gz', segfault occured > when the ``From'' header was displayed Interesting: In the past coloring regexps have already been found to trigger glibc segfaults in specific conditions and locales. Now, it would be the first time I hear this in a clean GBK setup... BTW there is no need to end color header regexps by ".*": The full header is colored anyway. >| LANG=zh_CN.GBK >| LC_ALL=zh_CN.GBK >| $ echo $LANGUAGE >| zh_CN.GBK Bug or not bug, you should remove LC_ALL forever. And you should also remove LANGUAGE: Does it still segfault? > I am not familiar with gdb, and I followed your indication. I type the > command above, then `run', after segfault, I `generate-core-file', and > then `bt' and `quit'. Is this right? Unfortunately I could not make use of the core. What I meant was: -0) Verify "ulimit -c" prints "unlimited" for core files size. -1) Use Mutt alone until segfault: A core file is created. -2) Type "gdb /usr/bin/mutt core". -3) At the GDB prompt type "bt" then "quit". -4) Copy/paste us the text printed by GDB. It should give us the function where the segfault occurred, and calling functions. Bye!Alain. -- Everything about locales on Sven Mascheck's excellent site at new location http://www.in-ulm.de/~mascheck/locale/>. The little tester utility is at http://www.in-ulm.de/~mascheck/locale/checklocale.c>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318270: mutt: edited messages are deleted
Hello Rick, and thanks for reporting this. On Thursday, July 14, 2005 at 8:48:45 AM -0400, Rick Pasotto wrote: > Version: 1.5.9-2 > After pressing 'e' to edit a message in the mailbox, the original is > marked as deleted (as it always has been) but the edited version is > now nowhere to be found. No such bug with stock Mutt 1.5.9 here: The edited version is appendend to the mbox, detected as "New mail in this mailbox.", and appears immediatly in index. Note that depending on it's own status, the mail itself may not be new, but old/read/answered/flagged. Your new mail detection works? Have you sufficient free space and inodes in $tmpdir? You use mbox? > Locale: LANG=en_US, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) BTW this locale has conflicting charsets: en_US implicitly uses Latin-1, and Latin-1 and Latin-9 are not compatible. Better set the same charset for all locale categories. Bye!Alain. -- Mutt muttrc tip for mailing lists: set followup_to=yes and declare the list as - subscribe [EMAIL PROTECTED] if you are subscribed and don't want courtesy copy. - lists [EMAIL PROTECTED] if you are not subscribed or want a courtesy copy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317697: mutt: tag-reply only quotes the first message
Hello Chris, and thanks for the report. On Sunday, July 10, 2005 at 12:25:16 PM -0700, Christian H. Stork wrote: > Version: 1.5.9-2 > If I do a tag-reply (or tag-group-reply) of several messages in the > same thread then mutt only quotes the first message and forgets about > the rest. No such problem here with stock Mutt 1.5.9. Have you used or $auto_tag? Bye!Alain. -- When you post a new message, beginning a new topic, use the "mail" or "post" or "new message" functions. When you reply or followup, use the "reply" or "followup" functions. Do not do the one for the other, this breaks or hijacks threads. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317697: mutt: tag-reply only quotes the first message
On Wednesday, July 13, 2005 at 11:51:33 AM -0700, Christian H. Stork wrote: > If tmpdir is set then the multi-quote is cut off at the beginning of > the sig in the first message. If it's not set everything (including > the sig) is quoted. Truncated at around 84 bytes? This may smell like a ~/tmp/mutt/ full problem. I can't reproduce your symptom: Fullquote in both cases. But I have there 428 Mo (and 514738 inodes) free. Can you create some files? Otherwise what lacks exactly? Part of first quoted sig, second attribution line, all second text and quote char, sigdashes and your own default ~/.signature? Bye!Alain. -- Mutt muttrc tip to send mails in best adapted first necessary and sufficient charset (version for Western Latin-1/Latin-9/CP-850/CP-1252 terminal users): set send_charset="us-ascii:iso-8859-1:iso-8859-15:windows-1252:utf-8" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#330933: wrong MIME header in confirmation challenge
package: debbugs severity: minor Hello! On the Debian PTS I subscribed to the bug mailing list of source package . I then received a confirmation challenge like that: +--- | From: Debian Package Tracking System <[EMAIL PROTECTED]> | To: | Subject: CONFIRM | Content-Type: text/plain; charset=ISO-8859-15 | Content-Transfert-Encoding: 8bit | | Hello, | | you asked to be subscribed to the "mailing list"[1] for the Debian | source package called . To complete this process, you | have to reply to this mail by including this command : | CONFIRM | | On any modern mailer, you just have to hit reply and send the mail. | | If you don't understand why you got this mail, please ignore it, | you won't be subscribed to anything unless you confirm it. | | If you have any problem with this service, please contact | [EMAIL PROTECTED] | | Thanks, | | [1] This list receives all the bug reports (and the corresponding logs) | for the package "" that are sent to the Debian | Bug Tracking System. Check http://bugs.debian.org/src: to | see what it looks like. +--- The header contains: | Content-Type: text/plain; charset=ISO-8859-15 | Content-Transfert-Encoding: 8bit There are 3 problems: -1) "Transfer" has a typo final "t". -2) Body really contains US-Ascii 7 bits, so those fields should perhaps not be inserted at all (no need to state default values). -3) If those fields were necessary, there lacks a "MIME-Version: 1.0" field to complete the MIME triplet. Bye!Alain. -- Give your computer's unused idle processor cycles to a scientific goal: The [EMAIL PROTECTED] project at http://folding.stanford.edu/>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318270: mutt: edited messages are deleted
package mutt close 318270 thanks On Sunday, July 17, 2005 at 11:46:54 AM +0200, Alain Bench wrote: > No such bug with stock Mutt 1.5.9 here Unreproducable, and silent reporter: Closing. Bye!Alain. -- DGC> you have a talent for drawing people I'd usually be happy reading DGC> into your spiralling descents into irrelevance I'll take that as a complement :-) DYC in « Wrong In Public Again ». © December 2003.
Bug#316512: mutt: send2-hook broken: does not effect first matching message
package mutt close 316512 thanks Hello Wolfgang, thank you for the precise report. On Friday, July 1, 2005 at 3:30:26 PM +0200, Wolfgang Weisselberg wrote: >| send2-hook . 'my_hdr From: <[EMAIL PROTECTED]>' > observe: From IS NOT SET! That is not a bug, things are designed like that. At the time send2-hooks are triggered, the sender of the currently composed mail is already fixed. It's too late for changing sender via $from, via $reverse_name, or even via "my_hdr From:". In fact it's too late for any "my_hdr". The only way a send2-hook has to change the sender is via pushing : | send2-hook . "push [EMAIL PROTECTED]" The advantage in return is that a send2-hook pattern can depend on the sender. Bye!Alain. -- Mutt muttrc tip for mailing lists: set followup_to=yes and declare the list as - subscribe [EMAIL PROTECTED] if you are subscribed and don't want courtesy copy. - lists [EMAIL PROTECTED] if you are not subscribed or want a courtesy copy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#323385: was setting charset to latin1 in .muttrc :/
Hi Adeodato! On Saturday, August 20, 2005 at 2:59:34 PM +0200, Adeodato Simó wrote: > * Sven Luther [Sat, 20 Aug 2005 14:12:21 +0200]: >> even if my encoding settings where fubar, mutt should be copying the >> line verbatim An invalid byte would have perturbated later operations. > it's not mutt who truncates, but your terminal. More exactly truncation seems in enter.c:my_mbstowcs(), relying on platform's mbrtowc(), itself relying on the current LC_CTYPE locale. On a correctly configured Mutt and system, this works OK. And an incoming invalid byte is already masked upstream when it reaches my_mbstowcs(). Just check with: | From: Joe =?utf-8?q?Trunc=E4te?= <[EMAIL PROTECTED]> On reply this displays: Joe Trunc?te. The invalid is masked, either by a question mark, or by an UTF-8 replacement char U+FFFD. On a misconfigured system, I'm not sure something sensible in all cases can be done. What if the locale was wrong but $charset right? What if both are wrong? What if the name doesn't go thru the prompts because of $fast_reply? And what happens when an invalid come in? Is it worth the hassle? Bye!Alain. -- How to Report Bugs Effectively http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
Bug#323690: slrn: username and hostname settings are ignored for email replies
Hello Tony, thanks for the report.
On Thursday, August 18, 2005 at 12:58:11 AM +0100, Tony Houghton wrote:
> When replying by email, slrn ignores some options such as username and
> hostname, defaulting to system settings. In my case this doesn't
> produce a valid email address for the From: header.
Does this help?
| set generate_email_from 1
Bye!Alain.
--
define display_manual_txt () {
system ("less /usr/local/share/doc/slrn/{manual,slrnfuns}.txt " +
"/usr/local/doc/slang/{slang,slangfun}.txt");
}
definekey ("display_manual_txt", "", "group");
definekey ("display_manual_txt", "", "article");
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316512: mutt: send2-hook broken: does not effect first matching message
On Monday, August 22, 2005 at 11:37:22 PM +0200, Wolfgang Weisselberg wrote:
> the manual schould mention :
>| However, you cannot set "From: " with send2-hook except using
>| 'send2-hook . "push [EMAIL PROTECTED]"',
>| since send2-hook runs too late for any other method.
Well... Manual should probably not give as example the line I gave
you as demo: It has the important drawback to disallow manual override
both thru and thru $editor.
In problem report mutt/1773 http://bugs.mutt.org/1773>, I
informally proposed "Also note that my_hdr commands don't affect the
current message when executed from a send2-hook.".
> Otherwise a reader might get the impression that the main difference
> between send2-hook ("is matched every time a message is changed") and
> send-hook ("[is] only executed ONCE after getting the initial list of
> recipients") is how often it's executed.
Yes: send2-hooks are subdocumented. And suboptimally named ;-).
Volunteer English doc writers are welcome, either directly on mutt-dev
or thru the upstream BTS http://bugs.mutt.org/>. Even for small
additions.
> Yet something *does* happen, for on the next try (recipient2)
> send2-hook *does* set the recipient. Even though that is a completely
> new mail, the old one being aborted. Is that really the correct
> behaviour? To me it looks like data leaking from one mail to another
Correct behaviour. Design principle. My_hdr leaks. As *all* settings
in Mutt, the list of my_hdrs is persistent, until it gets reset or set
to something else. That's why Mutt needs a default send-hook before
specific ones:
| send-hook . "unmy_hdr From:"
>> a send2-hook pattern can depend on the sender.
> Depend on the sender to be what Unchanged by "my_hdr From: "
> directives, as put into the mail header by the writer, as more-or-less
> immutable, even if you should run extensive commands in send2-hook?
I'm not sure to follow you? Depend on the sender of the currently
composed mail. Whatever way was used to set it: Default, automatic, or
manual.
Bye!Alain.
--
Give your computer's unused idle processor cycles to a scientific goal:
The [EMAIL PROTECTED] project at http://folding.stanford.edu/>.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324770: garbles subject line in compose window
package mutt close 324770 thanks Hello Martin, and thanks for the report. On Wednesday, August 24, 2005 at 2:02:43 AM +0100, Martin Michlmayr wrote: > Actually, it seems this may be partly due to a broken message. I saw > that the Subject line is not encoded which (I think) is against RFC. > In any case, it's possible that the message is slightly broken It's not valid MIME, which is not so surprising given it's a Usenet article. To get you money back: | unset strict_mime | set assumed_charset="cp1252" BTW it seems possible your charset or locale settings are broken: You should review them. Bye!Alain. -- When you post a new message, beginning a new topic, use the "mail" or "post" or "new message" functions. When you reply or followup, use the "reply" or "followup" functions. Do not do the one for the other, this breaks or hijacks threads. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#242398: mutt/1906: surprising behaviour in mutt 1.5* versus 1.4* with empty result of limits
Hello Christoph, Enrico, and Grant: Thank you all for your bug reports.
On Thursday, June 24, 2004 at 4:05:01 PM +0200, Christoph von Stuckrad wrote:
> I set a limit, which 'just now' results in 'nothing' Correctly I get
> the message "No messages matched criteria." [...] new mail comes in...
> *** THIS *** Mail is shown in the index, but is completely unrelated
> to the limit.
On Tuesday, April 13, 2004 at 7:25:45 PM +0100, Enrico Zini wrote:
>| mutt/1853: Esc+l does not work right when a filter matches no messages
> If I type 'l' ("limit") and then something impossible like
> "safgalskjhe", then no messages are displayed. However, if I type
> Esc+l ("show-limit"), it tells me "No limit pattern is in effect.",
> which is wrong.
On Tuesday, April 6, 2004 at 6:50:18 AM -0700, Grant Bowman wrote:
>| Bug#242398: limit misrepresentation to user when nothing matches
> Set any limit that matches zero messages. The show-limit function
> l says "No limit pattern is in effect." [...] The limit pattern
> is NOT put into the header line.
Please check patch-1.5.10.ab.empty_limit.1 uploaded to
http://bugs.mutt.org/1906>. It completes the previous changes done
around empty limits:
- New mails appear if they match the limit pattern.
- and %V show the current limit pattern.
- %M shows 0 (number of messages matching limit).
- Patterns beginning by ~A but longer are not confused with ~A.
- and are callable from an empty mailbox.
- also.
Bye!Alain.
--
How to Report Bugs Effectively
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332571: Acknowledgement (Index is unusable in a UTF-8 environment)
Hello Daniel, thanks for the report and the digging. On Friday, October 7, 2005 at 9:45:08 -0700, Daniel Burrows wrote: > I fixed it by going through and replacing each space character in > index_format with a space character. Nice one! Your original $index_format has all spaces as Latin-1 non-breaking spaces coded 0xA0. As the glyph is identical, a space, you could look some long years before seeing the difference. > character in there that displayed properly in some places (i.e., vim) Vim has a "fileencodings" heuristic to auto-sense a file's charset. Probably your muttrc was correctly guessed as written in Latin-1 charset, and vim has then shown you the nbkspc converted to your UTF-8 display. > it would be preferable if mutt failed a bit more gracefully when > invalid characters were present in index_format. And what about setting $config_charset=iso-8859-1, which while reading muttrc will convert on-the-fly the nbkspc to its UTF-8 coding? Bye!Alain. -- When you want to reply to a mailing list, please avoid doing so from a digest. This often builds incorrect references and breaks threads. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333523: mutt: Add command to save thread in pager
Hello Lars, On Wednesday, October 12, 2005 at 12:54:46 +0200, Lars Persson Fink wrote: > to save a thread to a mailbox when in the pager. | macro pager "\ | \ | unset resolve\ | \ | set resolve\ | \ | =ay\ | ""save-thread to =a mailbox" Real men use real keyboards. ;-) Bye!Alain. -- set honor_followup_to=yes in muttrc is the default value, and makes your list replies go where the original author wanted them to go: Only to the list, or with a private copy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#228671: mutt/1771: Screen left in strange mode when piping mail with unknown mime-types
Synopsis: Screen left in strange mode when piping mail with unknown mime-types Comment added by ab on Thu, 13 Oct 2005 20:22:05 +0200 Deduppe and devirus unformatted trail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322040: account-hook doesn't set header with my_hdr for pop
package mutt close 322040 thanks Hello Bryan, and thanks for the report. On Monday, August 8, 2005 at 3:12:35 PM -0700, Bryan Richter wrote: > I have two external mailboxes; one is imaps and the other is pop. What > I want to do is change my From: header to match the address that each > mailbox corresponds to. It doesn't work with pop. If I understand correctly, you are misusing both account-hooks and "my_hdr From:". For your needs you should use folder-hooks and $from. Try something like that: | reset use_from# it's unset by Debian /etc/Muttrc | set [EMAIL PROTECTED] | set realname="Bryan Richter" | folder-hook . "set [EMAIL PROTECTED]" | folder-hook ucdavis "set from=davisaddress" | folder-hook iradeon "set from=iradeonaddress" Though there might exist a more Debianized way to set a default address: Hopefully a guru will tell us. And the regexes are dangerously too lax: Bad example. > I get the following behavior [snip] Well, account-hooks are triggered when they are needed (access, reconnect, check for new mail of other folders, ...), at not really user predictable moments. Apparently inconsistent behaviours may seem to be observed. I use account-hooks only for $pop_authenticators, $pop_pass, $imap_pass, and such, and it works very well. Bye!Alain. -- Mutt muttrc tip to send mails in best adapted first necessary and sufficient charset (version for East Europe Latin-2/CP-852/CP-1250 terminal users): set send_charset="us-ascii:iso-8859-1:iso-8859-15:windows-1252:iso-8859-2:windows-1250:utf-8" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392865: mutt: segfault when viewing spam mail
Hello Georg, and many thanks to you for the report. On Friday, October 13, 2006 at 23:53:27 +0200, Georg Neis wrote: > % mutt -f crash > Sorting mailbox...zsh: segmentation fault (core dumped) mutt -f crash Unreproducible here. Could you please check the backtrace? Let segfault create a core, gdb $(which mutt) core, then type "bt" and "quit". BTW to send attached such offending mails, better use (bound to 'A' by default) than (bound to 'a' by default) in Mutt when applicable. Or even better here: Zip the example mbox and attach the zipfile. This avoids any corruption, transcoding, and added charset ambiguity. Anyway the problem seems to come from raw hibit bytes in the header. I can't be sure of the used charset, but wild guess it could be BIG-5. Does it segfault when you set: | unset strict_mime | set assumed_charset=big-5 Does it segfault when you set a more generic: | unset strict_mime | set assumed_charset=cp1252 Bye!Alain. -- set honor_followup_to=yes in muttrc is the default value, and makes your list replies go where the original author wanted them to go: Only to the list, or with a private copy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402027: mutt: Display of GB2312 should be treated as GB18030 by default
On Friday, December 8, 2006 at 21:12:59 -0500, Ambrose Li wrote: > On Fri, Dec 08, 2006 at 06:36:26PM +0100, Alain Bench wrote: >>| charset-hook ^gb2312$ gb18030 >> How many such under-labelled mails do you receive? > I only receive such mails from time to time. Small benefit, but zero drawback? I'm still for it. > I do encounter a similar problem much more often (Big5-HKSCS mistagged > as simple Big5) Unfortunately static aliasing doesn't seem to be able to solve cleanly this one: Big5-HKSCS apparently lacks some hundreds of Big5 characters, and some of the common chars are coded differently. Something more sophisticated could perhaps be done, as a charset-hook inside a message-hook, unhooked by default. With some appropriate pattern for the message-hook, say some specific X-Mailer. Bye!Alain. -- How to Report Bugs Effectively http://www.chiark.greenend.org.uk/~sgtatham/bugs.html> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402027: mutt: Display of GB2312 should be treated as GB18030 by default
Hi Ambrose, and thanks for the interesting suggestion. On Thursday, December 7, 2006 at 11:03:01 -0500, Ambrose Li wrote: > In practice, GB-based Chinese emails with traditional characters are > tagged as "GB2312" even though technically speaking they are in > GB18030. So you can correct this insufficient MIME label by aliasing it as: | charset-hook ^gb2312$ gb18030 Let's evaluate the thing. The first charset is a (nearly) perfect subset of the second, so there should not be any drawback. In theory, 2 chars are different. But those are an EM DASH against an HORIZONTAL BAR, and a MIDDLE DOT against a KATAKANA MIDDLE DOT. Probably same glyph, or not distinguishable... In practice probably not a drawback at all. Benefit: How many such under-labelled mails do you receive? One from time to time, 10%, 90%, ?? Conclusion: I'm all for including this line to Debian's /etc/Muttrc. What's your opinion, Dato? | # Some GB18030 traditional Chinese mails are wrongly labelled GB2312. | # The first charset is a superset of the second. Let's alias it: | charset-hook ^gb2312$ gb18030 I'm not for upstream inclusion, because I'm not sure if every iconv library out there knows GB18030. But I'll probably begin to advice it. Bye!Alain. -- « if you believe the Content-Type header, I've got a bridge to sell you. »
Bug#399066: locale not correct in Index-View
Hello Michelle, On Friday, November 10, 2006 at 18:23:02 +0100, Michelle Konzack wrote: > In the Index-View I have: électro > and then in the message: électro Perhaps the header cache was filed while $charset=utf-8, and not wiped when you changed to the Latin-9 locale? Or some setting changed between mailbox opening and message viewing: $charset, $assumed_charset, charset-hooks... What is the raw "Subject:" header, when you pipe the message to less with $pipe_decode=no? Bye!Alain. -- « Be liberal in what you accept, and conservative in what you send. » Jon Postel / Robustness Principle / RFC 1122
Bug#298365: mutt: french version ask question with [oui] answer when in fact expecting 'y' key
Hello Benoît-Pierre, and thanks for the report, On Monday, March 7, 2005 at 1:43:40 AM +0100, Benoît-Pierre Demaine wrote: >| LANG=en_GB.ISO-8859-15 >| LC_ALL= > [Mutt] keeps asking me questions in french Hum... So there seems to be a locale/NLS mismatch. But why? Could you please verify: · Is LC_ALL really unset, or set to empty string? · Have you a LANGUAGE env var defined? · Do you get English questions if you export LANG=C? And LC_ALL=C? · Is Mutt's environment really the one you quoted (check from inside Mutt)? Bye!Alain. -- Everything about locales on Sven Mascheck's excellent site at new location http://www.in-ulm.de/~mascheck/locale/>. The little tester utility is at http://www.in-ulm.de/~mascheck/locale/checklocale.c>.
Bug#298310: mutt: fails to set the signature in a send-hook
package mutt close 298310 thanks Hello Ernest, and thanks for the clear report, On Sunday, March 6, 2005 at 5:02:02 PM +0100, Ernest Adrogué wrote: >| send-hook "[EMAIL PROTECTED]" set signature = "echo blah|" > Fails with a "blah|: unknown variable" message. Insufficient quoting. This works: | send-hook "[EMAIL PROTECTED]" 'set signature = "echo blah|"' As I always say: Better a false report than a missed bug! :-) Bye!Alain. -- blah
Bug#298673: mutt: limit ~b does not handle base64 encoded email
package mutt close 298673 thanks Hello Matthew, and thanks for the report, On Wednesday, March 9, 2005 at 12:45:59 AM -0700, Matthew Mueller wrote: > emails with: >| Content-Type: text/plain; charset="utf-8" >| Content-Transfer-Encoding: base64 > using limits doesn't work on them. Ex: l~bdpkg shows nothing Set $thorough_search to search/limit *after* decoding, decrypting, and charset transcoding, at the expense of a little more processor time. Otherwise by default you match against raw bodies. Bye!Alain. -- Give your computer's unused idle processor cycles to a scientific goal: The [EMAIL PROTECTED] project at http://folding.stanford.edu/>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299054: mutt: Attachment filename rfc2047 decoding
Hi Marco! On Friday, March 11, 2005 at 2:28:40 PM +0100, Marco d'Itri wrote: > On Mar 11, Sergey Kogan <[EMAIL PROTECTED]> wrote: >> Many mailers [...] use rfc2047-encoded suggested filenames > This is a standard violation which is not tolerated by the upstream > author (and me as well) and such a patch has been rejected multiple > times. What has been rejected was an option to *send* such bogus attachment names. Brrr! Evil, even if it accomodates sending to Outlook which otherwise rejects correct 2231 names and displays "ATT12345.dat". Sergey wanted to *receive* them, and that option is included in Mutt since ages. Bye!Alain. -- « Be liberal in what you accept, and conservative in what you send. » Jon Postel / Robustness Principle / RFC 1122
Bug#298365: mutt: french version ask question with [oui] answer when in fact expecting 'y' key
package mutt submitter 298365 Benoît-Pierre Demaine <[EMAIL PROTECTED]> close 298365 thanks Salut Benoît-Pierre, To discuss the bug report, you must mail to [EMAIL PROTECTED] Otherwise informations are lost for everyone else, as I will not forward private mails. And please use valid sender address. On Thursday, March 10, 2005 at 8:28:45 PM +, Benoît-Pierre Demaine wrote: >> On Monday, March 7, 2005 at 1:43:40 AM +0100, Benoît-Pierre Demaine wrote: >>>| LANG=en_GB.ISO-8859-15 >>> [Mutt] keeps asking me questions in french Not a Mutt bug, but a misconfiguration. Just unset LANGUAGE and you'll get English questions and expected replies. Bye!Alain. -- How to Report Bugs Effectively http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
Bug#152444: For 1.5.9: iconv-hook patch by Moriyama-san
[ Courtesy Copy to Ilya Konstantinov, ] [ Mutt bug #1269, and Debian Bug #152444 ] On Saturday, February 19, 2005 at 12:41:10 PM +0900, Tamotsu Takahashi wrote: > The problem is that MS thinks ISO-2022-JP means ISO-2022-JP-MS. And MS > does not think there is a charset called ISO-2022-JP-MS. I don't know well those charsets and their differences, but such scheme sounds familiar! So it's *the* new standard? ;-) > I have to tell mutt to convert my eucJP-ms files to ISO-2022-JP-MS, > labelling it with "charset=iso-2022-jp", to send it to MS-MUA users. Ahaah! I perhaps begin to understand. You want to be able to insert an alias name in $send_charset, already known or not. This reminds me bug #1269 associated with Debian Bug #152444. Reporter Ilya wanted to send ISO-8859-8 mails, but labelled "iso-8859-8-i". Those are identical charsets, out of bidirectional reordering. But 8859-8 is known to Mutt and iconv, while -8-i is not. Impossible to set "iso-8859-8-i" in $send_charset, and to influence that with an iconv-hook. Wouldn't your patch-1.5.8.msyk.iconvhook.1 help? > This cannot be corrected by your charset-hook. No: Clearly charset-hook deals with incoming mails only, and this must not change. > Also, the iconv-hook patch is useful for future changes of charsets > definition. If we have no reason to forbid using of iconv-hook for > already-available charsets, this patch goes the right way, IMHO. Hum... Misused this permits self-foot-shoting. As one or two other Mutt features: Nothing new. If it's usefull in such corner cases, I'd say right way, too. What is the exact intended usage of iconv-hook? Bye!Alain. -- Slrn 0.9.8.1pl1 is released. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#152444: For 1.5.9: iconv-hook patch by Moriyama-san
package mutt tags 152444 patch thanks On Monday, February 21, 2005 at 10:32:24 AM +0900, Tamotsu Takahashi wrote: > On Sun, Feb 20, 2005 at 03:45:21PM +0100, Alain Bench wrote: >> Impossible to set "iso-8859-8-i" in $send_charset, and to influence >> that with an iconv-hook. Wouldn't your patch-1.5.8.msyk.iconvhook.1 >> help? > Maybe it does. It works! Or at least it seems so for someone not talking Japanese nor Hebrew ;-). Anyway I simulated with some pairs of charsets, known or not, canonical or not, imaginary... and everything worked as advertised. Displaying, sending, attaching, and even aliasing $charset itself under my feet. Every combination seems possible at will. Seems good to me. Bye!Alain. -- set honor_followup_to=yes in muttrc is the default value, and makes your list replies go where the original author wanted them to go: Only to the list, or with a private copy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#269699: Patch
package mutt tags 269699 patch fixed-upstream thanks Hello Kyle, On Thursday, February 24, 2005 at 2:00:04 AM -0500, Kyle Wheeler wrote: > If it helps, here's the [ddm.pgp-auto-decode] patch. Thanks, but the previous URL was sufficient. Anyway the ddm.pgp-auto-decode patch is now included upstream since Mutt 1.5.8. Bye!Alain. -- When you post a new message, beginning a new topic, use the "mail" or "post" or "new message" functions. When you reply or followup, use the "reply" or "followup" functions. Do not do the one for the other, this breaks or hijacks threads. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413144: Mutt discards headers when saving a message
package mutt close 413144 thanks Hello Claus, and thank you for your report. On Friday, March 2, 2007 at 19:52:28 +0100, Claus Fischer wrote: > When saving a messages with decode-save, mutt strips most headers. obeys $weed. This is the intended behaviour from the beginning, has never changed, and will not change. The function is designed to save more or less what you see in the pager to a text file. Not to make a verbatim save, like you'd want to do to move a mail from a folder to another. I'm sorry you lost data, but it's not a bug. > I am convinced that people who SAVE a mail want it to be complete and > not to LOSE information. Of course, and then they use . Bye!Alain. -- Mutt muttrc tip to send mails in best adapted first necessary and sufficient charset (version for Western Latin-1/Latin-9/CP-850/CP-1252 terminal users): set send_charset="us-ascii:iso-8859-1:iso-8859-15:windows-1252:utf-8" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413144: Mutt discards headers when saving a message
On Saturday, March 3, 2007 at 15:50:11 +0100, Claus Fischer wrote: > they want a decrypt and save, but not a decrypt then lose headers then > save :-) Don't mix "code" and "crypt". The function does a nearly verbatim move, where only PGP and S/MIME encrypted parts get decrypted. Headers are kept complete, regardless of $weed. IIUC that's what you needed from the beginning. The scheme is: , , and (and their <*-copy-*> counterparts) have different main purposes, and so it's normal they behave differently. - main purpose is to move mails from one mailbox to another mailbox. So it's natural it's a verbatim move: No decode, no decrypt, no charset transcode, no header weed. Not a single change, whatever settings. - main purpose is to render a text file usable with any even non-mail tools outside Mutt (perhaps to edit it, print, process in any way...). So it's natural MIME encodings are decoded, charset converted to $charset, HTML rendered, unused multipart/alts removed, bin attachments removed, headers weeded on demand in a configurable way, encrypted parts decrypted, etc... Resulting text file is subject to every "rendering" setting in Mutt or helper apps: auto_view, hdr_order, alternative_order, ignore, $weed, $charset, $display_filter, charset-hook, and so on. - main purpose is to move mails from one mailbox to another, removing only the crypto-protection that was used during mail transport. Note this assumes crypto-protection is needless locally, which is not the case for everyone. It's a nearly verbatim move, where only PGP and S/MIME encrypted parts get decrypted. > people will want a decode-save that does not lose headers Easy changing value of $weed: | macro index,pager \ | " unset weed"\ | "non-weedy decode-save" And no, unfortunately, there is no way to automatically reset $weed to its previous state. Bye!Alain. -- Mutt compressed folders tip for stable archive timestamp: | open-hook \\.gz$ "gzip -cd '%f' > '%t' ; ret=$? ; touch --no-create --reference='%f' '%t' ; exit \$ret" | close-hook \\.gz$ "gzip -c '%t' > '%f' ; ret=$? ; touch --no-create --reference='%t' '%f' ; exit \$ret" | append-hook \\.gz$ "gzip -c '%t' >> '%f'" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#152444: mutt/1269: send_charset doesn't support charset-hook'd charsets
Synopsis: send_charset doesn't support charset-hook'd charsets Comment added by ab on Tue, 06 Mar 2007 20:13:12 +0100 upload patch-1.5.12.msyk.iconvhook.1-ab patch with comments deduppe unformatted. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413144: Mutt discards headers when saving a message
Hi Kyle! On Monday, March 5, 2007 at 15:43:22 -0700, Kyle Wheeler wrote: > On Sunday, March 4 at 01:00 AM, quoth Alain Bench: >> no way to automatically reset $weed to its previous state. > Sure you can: Unfortunately too nice to be true. There is a vicious trap: The prompt for a filename triggered by . Like other prompts in Mutt, you can't let them live in the middle of a macro (unless the macro provides a value and validates). In practice your macro saves to a file called "SentItemsenter-command>setweed=$my_weed". ;-( At first, I had written the very same $my_weed backuping macro for Claus. But me, I tried it before sending... ;-) Bye!Alain. -- « if you believe the manual.txt, I've got a bridge to sell you. »
Bug#402035: mutt: Mutt's internal text viewer confused by out-of-range GB2312 characters
Hi Ambrose, and as usual much thanks for reporting bugs! On Thursday, December 7, 2006 at 12:01:58 -0500, Ambrose Li wrote: > In an allegedly-GB2312 string, any high byte following pure ASCII > should be treated as the lead byte of a presumed double-byte > character, even if it is invalid GB2312. The sequences "?v", "?F", > "?L", and "?h" are all meaningless and should all be simply "??" > (because they are "unknown kanji", not pairs of "unknown 8-bit > character followed by valid ASCII"). Mutt is probably not at fault here, as the iconv command does the same, in any locale. Minimal test case: | $ printf "\xd6\x76\n" | iconv -c -f gb2312 | v I understand your point of view about "??" against "?v". But I suppose one can argue that it can also make sense to restart as soon as possible after something invalid, ie print the valid Ascii "v". I vaguely recall having already stepped on such cases. Anyway here, for this part of the problem, only iconv people can have the last word. Note that "?h" near end of string is special: It's invalid GB2312, once seen as GB18030 it becomes valid, but even then it's still unconvertable to BIG5. | $ printf ">\xad\xf8<\n" | iconv -c -f gb2312 | >< | $ printf ">\xad\xf8<\n" | iconv -c -f gb18030 | >< | $ printf ">\xad\xf8<\n" | iconv -f gb18030 -t utf-8 | >< > The output "祿" [b8 53] and "櫻" [c4 e5] cannot be explained; they > don't seem to be related to the original gb18030 in any way. I don't have the same display here: Where you see "?祿??櫻?", I see "??活??，" , which seems to be correct given the string is "毬活動，" in GB18030. However strangely iconv doesn't agree: | $ printf ">\x9a\xc2\xbb\xee\x84\xd3\xa3\xac<\n" | iconv -c -f gb2312 | >< ...no output at all. While GB18030 is of course OK: | $ printf ">\x9a\xc2\xbb\xee\x84\xd3\xa3\xac<\n" | iconv -f gb18030 | >毬活動，< Explaining this brokenness is not so hard: In those 8 bytes, 5 of the 7 possible pairs are either invalid GB2312, or unconvertable to BIG-5. Only 2 pairs are OK. > This *might* be the same bug as or a related bug of #249626 I'd say 2 very related multi-byte resync problems, but different causes: #249626 is only a Mutt bug, while this #402035 seems an iconv problem, partly confused by a layer of #249626. To give the correct "??活??，", iconv should consider bytes in GB2312 only by even pairs, even when the second high-bit byte could be the first of a valid character (an odd pair)... It's obvious that it would the thing to do in your specific example. But it could break other situations. I'm unsure. A problem, right, but maybe not a bug? Bye!Alain. -- Software should be written to deal with every conceivable error RFC 1122 / Robustness Principle
Bug#402027: Bug#249626: Bug#402027: mutt: Display of GB2312 should be treated as GB18030 by default
Hi Christoph, On Friday, March 9, 2007 at 17:50:24 +0100, Christoph Berg wrote: > does "fixing" this also affect #249626/402035? The hooks fixing #402027 will also prevent most the symptoms described in #402035 (only the unconvertable "?h" stays). But the underlying problem is still there, and generates symptoms in other circumstances. They do not affect #249626. > From reading the reports, there's probably not much we could do short > of reassigning the bugs to iconv. (I'm pondering tagging these > wontfix.) Let's see: #249626 context is ISO-2022-JP valid input not convertable. The symptoms are located where the bytes can *only* come in pairs (after an ESC $ B sequence). Resyncing after an error should be easy. The iconv command gives good results on the test cases. But Mutt fails. I think it's clearly a Mutt bug. #402035 context is a mix of valid input not convertable, and invalid input in the same string. Symptoms are located where the bytes can come single (Ascii) or in pairs (CJK). Thus it's more difficult to resync after an error. Mutt and the iconv command both give bad results. Those results are not identical, which could be an effect of #249626 (weak guess). Anyway I think it's a problem of the iconv lib, perhaps a bug. I'd suggest to unmerge #402035 and reassign it to iconv people (where exactly: glibc?). Do you agree? Further about #249626, I fear it could be the "economic" direct way Mutt calls the iconv() in lib. Mutt should perhaps do a two stage conversion (fromcode to Unicode, then Unicode to tocode), dealing itself with all intermediate errors. This approach would give some infos on what is a character (vs a byte), and permit to skip a whole invalid (or unconvertable) character. This approach would also cost twice the horsepower, twice the memory, and twice the complexity... Hopefully there is a simpler way to fix it. However I'm strongly against a wontfix tag, given the big annoyance this bug provides to multibyte locales (out of UTF-8 of course). It can change a perfectly valid text to whole nonsense. Bye!Alain. -- Give your computer's unused idle processor cycles to a scientific goal: The [EMAIL PROTECTED] project at http://folding.stanford.edu/>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414828: mutt inserts attribution in wrong charset
package mutt
close 414828
thanks
Hello Joerg, and thanks for the report.
Am Mittwoch 14 März 2007 um 0:28:03 +0100, Joerg Friedrich schrieb:
> my locale is LANG=de_DE.UTF-8 when I reply to utf-8 encoded mails, the
> attribution is encoded in iso8859-1 because strftime does not know
> about charsets.
Date and time in attributions don't follow the locale from
environment. They follow Mutt's $locale variable. The user is reponsible
to set $locale to any available value using the same charset as the
current locale.
If you want to attribute in German:
| set locale=de_DE.UTF-8
If you want to automatically follow your own locale:
| set locale=`echo "${LC_ALL:-${LC_TIME:-${LANG}}}"`
If you want to attribute in French:
| set locale=fr_FR.UTF-8
...und so weiter. Does it work now?
| $ attributer de_DE.UTF-8
| set my_save_config_charset="$config_charset"
| set config_charset="utf-8"
| set attribution=" Am %d, %n schrieb:\n"
| set date_format="%A %-d %B %Y um %-H:%M:%S %Z"
| set locale="de_DE.UTF-8"
| set config_charset="$my_save_config_charset"
| unset my_save_config_charset
Bye!Alain.
--
Give your computer's unused idle processor cycles to a scientific goal:
The [EMAIL PROTECTED] project at http://folding.stanford.edu/>.
Bug#414828: mutt inserts attribution in wrong charset
package mutt # time for a debate reopen 414828 retitle 414828 mutt: wish localized default $locale severity 414828 wishlist thanks Hello Christoph, On Sunday, March 25, 2007 at 23:12:59 +0200, Christoph Berg wrote: > I wonder if $locale shouldn't default to $LC_TIME I fully agree, that would be a good thing, a step in the good direction. Naturally users of a mailer expect it to be localized following their current locale. But changing default $locale value or behaviour could break existing muttrcs (those which removed ! from $*_format and count on default $locale to get English time). I can imagine 2 ways to do it: -a) Initialise $locale to current locale. -b) Initialise $locale to "", and make this get the current locale (instead of skipping setlocale()). (b) would have the advantage to follow runtime environment changes (for those using the setenv patch). I'd vote for that. > the default date_format does already start with a ! to disable > localized timestamps there, and index_format/attribution could be > changed as well. Add ! everywhere to reget English by default? Humm... OK, today is only a first step, right? Anyway this would also break some existing muttrcs (those which set $locale and count on default $index_format to get localized time). Conclusion: I'm for it, despite the little problems. Note: See related upstream wish/1158 "persistent locale setting" for another aspect of the problem, and for a patch touching the same places as alternative (b) above. Bye!Alain. -- Give your computer's unused idle processor cycles to a scientific goal: The [EMAIL PROTECTED] project at http://folding.stanford.edu/>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410936: mutt mistakenly reports that mailcap entry is not found
Hello Nik, and thanks for the report. On Wednesday, February 14, 2007 at 12:10:41 -0500, Nik A. Melchior wrote: > When I view an email with an attachment, e.g. a PDF document, the > status line complains: > mailcap entry for type application/pdf not found > However, /etc/mailcap does indeed include this entry. In fact, when > I view the attachment, mutt is happy to spawn xpdf. You have "auto_view application/pdf" or $implicit_autoview=yes, but your mailcap entry has no "copiousoutput" tag, right? Entries without this tag are not suitable to autoview in pager, only to from the attachments menu. Please check adding *after* your xpdf entry an entry as: | application/pdf; pdftotext -nopgbrk %s - ; nametemplate=%s.pdf ; copiousoutput Bye!Alain. -- AB> I'm never happy before I can shout an humiliating « RTFM! ». ;-) Well, I'll see what I can do to accommodate your twisted needs in exchange for some enlightenment. -+- TMZ in Mutt Guide, lesson 4: Brown bag with eyes holes -+-
Bug#389405: mutt: Content-Disposition cannot be changed
package mutt close 389405 thanks Hello Allan, On Tuesday, October 10, 2006 at 10:20:03 -0400, Allan Wind wrote: >>| Compose: >>| ^D toggle-disposition toggle disposition between inline/attachment > [I] did check the manual and found no mention of it. Since 1.5.14+cvs20070315-1 package, the manual now mentions and all other forgotten functions. Thanks to you Allan for the report, and thanks to Christoph for the automatic functions documenting patch applied upstream. :-) Package release announces: | The key binding documentation is now auto-generated, thereby | documenting some missing functions (Closes: #413144). Let's also close this #389405. Bye!Alain. -- How to Report Bugs Effectively http://www.chiark.greenend.org.uk/~sgtatham/bugs.html> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414828: mutt inserts attribution in wrong charset
On Monday, March 26, 2007 at 17:26:53 +0200, Christoph Berg wrote: > which parts are all affected. $locale impacts $date_format, and all $*_formats having date %expandos. Environment impacts the browser at startup (later browser becomes English, flea/1734), and some dates here and there (like the "PGP output follows (current time: ...)"). > $locale would change the language there [attributions], but not the > charset. Could we make these 2 parts independent? I think unfortunately not. Sure it would be very handy, for Mutt and outside, but it's just not the way locales and strftime() were defined to work. >> -a) Initialise $locale to current locale. >> -b) Initialise $locale to "", and make this get the current locale (a) would have the advantage that the output of "set ?locale" is more explicit (than an empty string). (b) would use the same semantics as setlocale() itself (where empty string picks environment, or regional options of the control panel on Win32, or whatever appropriate). > on which kinds of systems do we really need $charset and $locale > inside mutt? $charset is needed on platforms without nl_langinfo(CODESET), platforms where it gives wrong charset (or stupid names), setups without locales or with broken ones, everywhere to play some advanced tricks, to simulate $editor_charset, to enable //TRANSLITerations... Mandatory. $locale is needed for foreign language attributions. > let $locale only affect sent mail. Proposal (A): -1) change default $locale to follow env -2) change default $*_format to insert English ! (for now) -3) make time %expandos follow env by default -4) add a modifier char ":" to make time %expandos follow $locale -5) insert (4) in default $date_format (used in default $attribution) Alternative (B): -3) make time %expandos follow env for index (and friends) -4) make time %expandos follow $locale for attribution -5) add a modifier char to make time %expandos follow the other one One or the other, this will break much more existing muttrcs than the 1158 patch. However it's nicer design. Patch 1158 was voluntarily designed /oddly/, so to not break any config; it has not been accepted. Bye!Alain. -- Give your computer's unused idle processor cycles to a scientific goal: The [EMAIL PROTECTED] project at http://folding.stanford.edu/>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414828: mutt inserts attribution in wrong charset
Hello Kyle!
On Monday, March 26, 2007 at 9:47:04 -0600, Kyle Wheeler wrote:
> Should [$locale] then perhaps be renamed to $date_locale, just for
> more clarity?
Sure yes, good idea! Only if Rado agrees, of course. With a
compatibility synonym. $locale is a very imprecise and confusing name.
> doing a getlocale() every time [...] seems wasteful.
The current code already does 2 setlocale() around each strftime().
Both skipped in English configurations. We would not _add_ any waste.
>>> Add ! everywhere to reget English by default? Humm... OK, today is
>>> only a first step, right?
> NEW! One of the features of mutt 1.6 is more thorough support of
> locales!
Such second step will be much more difficult. Changing default value
of $locale is not enough. For index we'd need various localized default
values for $index_format. Today it contains "%{%b %d}". Month, then
date: English order. The browser has the same problem, not even (yet)
configurable. Attributions need localized default $attribution and
$date_format strings. Surely someone will come proposing some or such
"universal" but impersonal format, nobody will never agree.
But that's the hard way to go. ;-)
I don't even have any idea about how to have various localized
strings as default in a Mutt variable. If gettext comes in, it would
need to follow LC_TIME, not LC_MESSAGES (for people using different
values there). For attributions, a bash script like my "attributer"
could be used, but that's not default values anymore.
Bye!Alain.
--
This mail is confidential. Don't read it. Then after eat your screen.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402027: mutt: Display of GB2312 should be treated as GB18030 by default
Hello Christoph, On Tuesday, February 27, 2007 at 23:20:25 +0100, Christoph Berg wrote: > did you try the charset-hook suggested here? Does it work for you? I'm not Ambrose, but have no doubt it worked. ;-) > If so I'd be inclined to include it in /etc/Muttrc. Then I'll contribute another similar charset-hook, aliasing EUC-JP to EUC-JP-MS for Japanese. It deals with Microsoft mailers which use their own extended charset pretending it's straight EUC-JP. The result is nearly the same as the GB2312 hook: Only (small) benefit. No drawbacks. I still have to highlight one danger: Such hook has no drawbacks, provided iconv knows the target charset, here EUC-JP-MS. That's OK for Sarge and Etch. Not for Woody (beware of backports). | # Some GB18030 traditional Chinese mails are wrongly labelled GB2312. | # The first charset is a superset of the second. Let's alias it, so | # that Mutt displays such mails as if they were correctly labelled. | charset-hook ^gb2312$ gb18030 | | # Some mailers send EUC-JP-MS Japanese mails wrongly labelled EUC-JP. | # The first charset is a superset of the second. Let's also alias it | # (but comment this out if "iconv -l | grep EUC-JP-MS" finds nothing): | charset-hook ^euc-jp$ euc-jp-ms Bye!Alain. -- Mutt muttrc tip for mailing lists: set followup_to=yes and declare the list as - subscribe [EMAIL PROTECTED] if you are subscribed and don't want courtesy copy. - lists [EMAIL PROTECTED] if you are not subscribed or want a courtesy copy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#420598: mutt: segfaults in uxterm with > 254 columns if there are single byte 8-bit characters in index_format
Hello Axel, and thank you for reporting us this problem. On Monday, April 23, 2007 at 15:08:27 +0200, Axel Beckert wrote: >| set index_format="%4C %Z %[%a·%d·%b] %-16.16F [%-12.12L] (%4c %4l) %s%> %M" > It works fine since years and even inside uxterms with > LC_CTYPE=en_US.UTF-8, but no other locale environment variables set. I sowewhat doubt this can work fine alone in an UTF-8 environment, because the string contains Latin-1 chars. For me in PuTTY this results in garbage display (no crash). Of course it starts working fine in all locales when the muttrc charset is properly declared first: | set config_charset="iso-8859-1" | set index_format="%4C %Z %[%a·%d·%b] %-16.16F [%-12.12L] (%4c %4l) %s%> %M" Do these 2 lines still segfault for you? Bye!Alain. -- Mutt muttrc tip to send mails in best adapted first necessary and sufficient charset (version for Western Latin-1/Latin-9/CP-850/CP-1252 terminal users): set send_charset="us-ascii:iso-8859-1:iso-8859-15:windows-1252:utf-8"
Bug#384351: mutt: fails to correctly send a .doc file to OpenOffice
Hello Rene, On Sunday, August 27, 2006 at 18:38:42 +0200, Rene Engelhard wrote: >> On Sun, Aug 27, 2006 at 02:06:04PM +0200, Alain Bench wrote: >>>>| application/msword; oowriter '%s'; edit=oowriter '%s'; >>> there should not be single quotes around %s in mailcap. > Why? Because Mutt has to do, and already does, the appropriate quoting job. Single quotes in the mailcap entry are harmless but useless in normal easy cases, and could perturbate expansion and auto-quoting of more complex ones. Extract from the Mutt manual: | 3.2. Secure use of mailcap [...] | Keep the %-expandos away from shell quoting. Don't quote them with | single or double quotes. Mutt does this for you, the right way, as | should any other program which interprets mailcap. There is more there, and also see $mailcap_sanitize variable. Bye!Alain. -- How to Report Bugs Effectively http://www.chiark.greenend.org.uk/~sgtatham/bugs.html> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384351: mutt: fails to correctly send a .doc file to OpenOffice
On Sunday, August 27, 2006 at 16:54:12 +0100, Julian Gilbey wrote: > Unfortunately, mutt_bgrun doesn't work either: oowriter exits > immediately and so the temporary file gets deleted before the new > oowriter process which is called has time to read it. mutt_bgrun does the backgrounding; The viewer must not. Otherwise the early deletion problem continues. Perhaps is there an option to disable backgrounding in oowriter? Alternatively drop mutt_bgrun, and wait some seconds. Example: "oowriter %s \; sleep 42". That's less clean, but may just work. I think clean solutions are just 2: Either read file first then go background, or use mutt_bgrun with a blocking viewer. Bye!Alain. -- Give your computer's unused idle processor cycles to a scientific goal: The [EMAIL PROTECTED] project at http://folding.stanford.edu/>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386171: workaround buggy clients that send mail without Content-Type
Hello Robert, and thank you for this interesting suggestion. On Tuesday, September 5, 2006 at 20:37:36 +0200, Robert Millan wrote: > to work around buggy clients that send mail with a non-ascii charset > _but_ without any Content-Type. >| unset strict_mime >| set assumed_charset=iso-8859-1 Many such buggy mailers tend to send CP-1252. Most or all westerners will have better results in practice with $assumed_charset=cp1252. > make it a builtin default I do not decide, but MHO agrees. It is much better a default setting than the current "pass-thru" mode. Everywhere, and especially in UTF-8 locales. It gives good results in more cases, and is more conservative in bad cases. With $assumed_charset set: · If real charset is CP-1252 or Latin-1: The display is perfect. · If real charset is different: Display is "cleanly" wrong. While in current default pass-thru mode: · If real charset happens to match $charset: The display is perfect. · Otherwise: At best display is wrong, at worst screen layout is garbled, and may even happen to trigger libc bugs (segfaults). Another question is the choice of an appropriate charset. CP-1252 is the most adapted $as for westerners. But it may not suit other populations. There is another option, that would be both ultra-conservative and equally suboptimal for everybody: $assumed_charset=us-ascii. Question marks for all. I do not have a strong opinion about this choice: Would personally prefer the shiny 1252, but of course I'm right in the target audience. > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > (ignored: LC_ALL set to en_US.UTF-8) Do not set LC_ALL, unless you have a Good Reason. Bye!Alain. -- Everything about locales on Sven Mascheck's excellent site at new location http://www.in-ulm.de/~mascheck/locale/>. The little tester utility is at http://www.in-ulm.de/~mascheck/locale/checklocale.c>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372289: mutt: Detects wrong mime type on some .tar.gz, resulting in corrupt files
Hello Thomas, On Wednesday, August 16, 2006 at 23:00:30 +0200, Thomas Bleher wrote: >>| application/x-tar-gztgz tar.gz > I think that this line should be added to the mime.types file. Upstream Mutt mime.types has it. To add it to Debian or Ubuntu, please see the package owning mime.types. > I'd still like to keep this bug open, though, because mutt's > heuristics could be improved It could surely be improved, but it's a quite delicate mechanism, a carefully equilibrated compromise. Past experiences changing the text/binary balance always ended fixing one case while breaking others. Look at sendlib.c functions update_content_info() and mutt_make_file_attach(), or grep for "(hi|lo)bin". Very roughly, when control chars are below 10%, it's considered text. If you have an improvement idea with only positive effects, please speak. > in doubt it should send data as application/octet-stream to avoid > mangling them. When "in doubt" is the whole point; When doubtless, there is no problem. This would lead to send some texts as octet-stream, which is neither good. > In this case, looking for embedded NULLs would have been enough (4th > byte of the file in question). This would disallow NULs in text. Bye!Alain. -- « if you believe the Content-Type header, I've got a bridge to sell you. » -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384642: mutt: Editing mails in UTF-8 on a latin1 terminal.
package mutt severity 384642 wishlist close 384642 thanks Hello Kurt, and thanks for the report. On Friday, August 25, 2006 at 19:09:32 +0200, Kurt Roeckx wrote: > I'm using a latin1 terminal, but I've set up vim to use utf-8 files by > default, but fall back to latin1. Vim also shows latin1 on the screen. > But I can't seem to get mutt and vim to agree on the charset for the > file being used. That's not possible today. You need to setup the $editor to read and write files exclusively and dumbly in the current locale charset, when it is called by Mutt. What you ask would make sense in some situations (like Mutt in a L1 term calling gvim in UTF, and such), and is already on the upstream Mutt wishlist/1317: "Add config var edit_charset". I close this Debian bug as duplicate (in upstream BTS Gnats, we don't merge but close dupes), and will add you to the interested parties of /1317. > file_charset. I've tried setting that to various things like just > "utf-8", or "utf-8:iso-8859-1", but it doesn't seem to be changing > anything. Keep the later value. But $file_charset acts on text files you from the compose menu, not on the text you write. > It seems that mutt always considers the encoding of the filename to be > the same as for the terminal, and that's not really what I want. You're right. Why do you want another charset? Knowing your exact goal, we could perhaps suggest other means. Probably a topic more for mutt-users mailing list or comp.mail.mutt than for a BTS, though. Bye!Alain. -- Everything about locales on Sven Mascheck's excellent site at new location http://www.in-ulm.de/~mascheck/locale/>. The little tester utility is at http://www.in-ulm.de/~mascheck/locale/checklocale.c>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384642: mutt: Editing mails in UTF-8 on a latin1 terminal.
Hi Kyle, On Friday, August 25, 2006 at 20:28:46 -0400, Kyle Wheeler wrote: > Mutt degrades the charset to the weakest one necessary. In other > words, if the characters that you use in your file are all valid > iso-8859-1 characters, then mutt will treat the file as iso-8859-1. > This is generally considered a good thing That's fully right. But before degrading to one of $send_charset, Mutt must know which is the origin on-disk charset: - For text files you attach, it's the first good of $file_charset if defined. Otherwise it's $charset. - For text you compose and save, it's $charset. IINM Kurt doesn't question the $send_charset downgrading, but the Mutt <=> editor fixed interfacing. Bye!Alain. -- Mutt muttrc tip for mailing lists: set followup_to=yes and declare the list as - subscribe [EMAIL PROTECTED] if you are subscribed and don't want courtesy copy. - lists [EMAIL PROTECTED] if you are not subscribed or want a courtesy copy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384642: mutt: Editing mails in UTF-8 on a latin1 terminal.
On Saturday, August 26, 2006 at 12:54:01 +0200, Kurt Roeckx wrote: > On Sat, Aug 26, 2006 at 11:47:47AM +0200, Alain Bench wrote: >> I close this Debian bug as duplicate [of upstream/1317] > The proper way would be to set it as forwarded, since it's not > actually solved. Humm... Really forward it upstream is useless: Would soon be closed as dupe. Is it usefull to let an upstream wishlist also open in Debian? When there is no feature patch Debian could adopt first? > Basicly, I want to store files in UTF-8. I also want to be able to > edit files that are stored in UTF-8. And I want to do that regardless > of what the terminal is set up to. I don't want to use iconv on a file > to convert it from/to utf-8, I want my editor to do that. And I've set > up vim to do what I want. OK. You don't need $edit_charset for that. You can just setup or call Vim so that for Mutt auto-sensing is disabled and files are loaded and saved in current locale charset. I just tried this works in .vimrc: | set termencoding=latin1 | set encoding=utf-8 | set fileencodings=latin1 But a Vim guru could better advice how to set fileencodings only when called from Mutt, keeping "ucs-bom,utf-8,latin1" otherwise. And if possible get rid of the "latin1" hardcoding so it follows the locale. Bye!Alain. -- Give your computer's unused idle processor cycles to a scientific goal: The [EMAIL PROTECTED] project at http://folding.stanford.edu/>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384642: mutt: Editing mails in UTF-8 on a latin1 terminal.
On Saturday, August 26, 2006 at 11:02:55 +0200, Kurt Roeckx wrote: > vim is set up to try utf-8 first, and if it fails fall back to > iso-8859-1. This Vim smart charset auto-sensing is a great feature, outside of Mutt. For Mutt, by design, the $editor must be dumb, and use only the charset of the locale. People *can* run for years with auto-sensing enabled, it works OK most of the time. But in some scenarios it can fail, and happens to hide from user's eyes the symptoms of a real problem, in config, or in the replied mail. I generally recommend to disable auto-sensing in Vim when called by Mutt, by unsetting $fileencodings. But I don't know how it will interact with your specific $encoding and $termencoding settings. Perhaps will you be forced to hardcode $fileencodings=latin1. Feedback welcome please. Hardcoding any given charset is never very good, this should be let free to follow whatever is the current locale. But hey... > mutt would either auto detect that the file [saved by Vim] is in utf-8 No: Such auto-sensing is an heuristic, having a limited charsets palette, and possibility of wrong guess. In some other cases, it is very handy. In this case, a robust setting would be more adapted. > Setting my terminal really in utf-8 mode would solve all my problems, > the problem is that all the software I use currently does not support > that, so I keep my terminal in latin1 mode. Locale is an environment thing: Each process can have it's own. You can run Mutt in an UTF-8 terminal, other apps in a Latin-1 one. Set LANG depending on the terminal, or such, nothing complicated. You can even run 2 Mutts in 2 different terms simultaneously, if well configured. Bye!Alain. -- You know what I would like to do? COMPLY. I would LOVE to COMPLY. But, you know what, Pat? I don't know where the h_ll that frickin 2-dash stupid stinkin line is coming from, okay? Comply... Greg K. in « Scarface III -- The Return Of The Evil Sigdashes » -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384351: mutt: fails to correctly send a .doc file to OpenOffice
package mutt close 384351 thanks Hello Julian, and thank you for reporting us this problem. On Wednesday, August 23, 2006 at 18:21:21 +0100, Julian Gilbey wrote: >| application/msword; oowriter '%s'; edit=oowriter '%s'; BTW, there should not be single quotes around %s in mailcap. > when I select this file for viewing from the attachments window, > OpenOffice gives the error message: /tmp/People_list_060612.doc does > not exist Mutt deletes the temporary file when the called process returns. This is not a bug, but admitedly may not suit background running apps. Gary Johnson's excellent mutt_bgrun is the usual solution. Bye!Alain. -- Give your computer's unused idle processor cycles to a scientific goal: The [EMAIL PROTECTED] project at http://folding.stanford.edu/>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389405: mutt: Content-Disposition cannot be changed
Hello Allan, On Monday, September 25, 2006 at 10:55:44 -0400, Allan Wind wrote: > mutt remembers the Content-Disposition but does not allow me to easily > change it. What about the function: | Compose: | ^Dtoggle-disposition toggle disposition between inline/attachment Bye!Alain. -- Manuals? See the archives for more discussion on why this should, like hydrogen for dirigibles, be relegated to the past. PCC DTG on MU. © August 2004. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304718: mutt: write_bcc now set by default, privacy leak in default config
Hello again Lionel, On Saturday, May 26, 2007 at 18:19:40 +0200, Lionel Elie Mamane wrote: > change mutt to use "sendmail -t Danger: This is known to generate duplicate mails with some sorts of "sendmails". > a new configuration option write_bcc_fcc Probably useless: There is no much interest in not recording "Bcc:". It could as well be not configurable, always on. > the other way: *never* write the "BCC" header to sendmail There are perfectly good reasons to want to send a "Bcc:" header, and perfectly good reasons to the contrary. So this should better stay configurable. The only problem in Mutt's current behaviour is that $write_bcc=no impacts $record. It should not. Bye!Alain. -- Give your computer's unused idle processor cycles to a scientific goal: The [EMAIL PROTECTED] project at http://folding.stanford.edu/>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426148: mutt: "mailto:" URL parsing stops at "references" header
Hello Lionel, and much thanks for the analysis and solution. On Saturday, May 26, 2007 at 20:39:04 +0200, Lionel Elie Mamane wrote: > The attached patch changes all calls to strtok to the reentrant > strtok_r, fixing that problem. But strtok_r() doesn't exist on some platforms, so I fear this can't be a general solution. Bye!Alain. -- Mutt muttrc tip for mailing lists: set followup_to=yes and declare the list as - subscribe [EMAIL PROTECTED] if you are subscribed and don't want courtesy copy. - lists [EMAIL PROTECTED] if you are not subscribed or want a courtesy copy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304718: mutt: write_bcc now set by default, privacy leak in default config
On Wednesday, May 30, 2007 at 13:58:41 +0200, Lionel Elie Mamane wrote: > There is already a patch that does just that: make $write_bcc not > impact $record. Which patch? The Gmane link you gave unfortunately doesn't work for me. The only patch I tested doing that was posted to the mutt-users mailing list by Derek D. Martin some 2 years ago, in the "write_bcc and fcc" thread, and IIRC it worked well. Is it this one? Bye!Alain. -- How to Report Bugs Effectively http://www.chiark.greenend.org.uk/~sgtatham/bugs.html> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#422557: mutt: thread markers make index lines wrap incorrectly in UTF-8 locales
Hello John, and thank you for this report. On Sunday, May 6, 2007 at 17:50:29 -0400, John Morrissey wrote: > When displaying an index in threaded mode, the thread markers (for > messages nested in a thread) make lines wrap correctly. After some > movement of the highlight bar, the display becomes fairly unable > without an explicit refresh (^L). When looking at your UTF-8 screen copy, the primary problem seems to be broken thread markers. The incorrect wrapping seems to only be a secondary consequence. But why are semi-graphic chars broken? There could be a lot of reasons to explore, but I'd first guess that may look like an UTF-8 locale on a Latin-1 terminal. What happens in PuTTY when you set Window --> Translation --> UTF-8, in addition to LANG=en_US.UTF-8? Bye!Alain. -- Give your computer's unused idle processor cycles to a scientific goal: The [EMAIL PROTECTED] project at http://folding.stanford.edu/>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423162: [pkg-ntp-maintainers] Bug#423162: ntpd does not really replace ntpdate at startup
Bonjour Marc, On Thursday, May 10, 2007 at 19:55:34 +0200, Marc Glisse wrote: > even with the -g option, ntp refuses to step 4 years This is not normal. However it can happen in some situations, like with some reference clocks rejecting large offsets despite -g, or when a LOCAL() clock happens to become syspeer first at startup. A misused local clock can be a quite evil thing. Bye!Alain. -- Give your computer's unused idle processor cycles to a scientific goal: The [EMAIL PROTECTED] project at http://folding.stanford.edu/>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455742: Garbled terminal with a particular message
Hello Loïc, and thanks for the good report. On Tuesday, December 11, 2007 at 17:30:13 +0100, Loïc Minier wrote: > My terminal is completely garbled when I load up a particular message The only unusual thing in this message is that 4 lines begin by a character U+FEFF (the ZERO WIDTH NO-BREAK SPACE). Those chars should be invisible, like a space drawn on zero columns wide. But on your screenshot, they appear to move the second character, like the "H" of "Hi Kash", from the expected leftmost column #1 to the last column of the previous line. The same happens for the "h" of "http:", and for the "I" of "It's based on". Just like if something wrongly counted that the column width of U+FEFF was -1 instead of 0. The other garblings, like those parasite header lines, may be only secondary consequences of the above problem, and may perhaps disappear on (^L). Note that such U+FEFF has in UCS context the alternate function of a BOM (Byte Order Mark). However we're in UTF-8 context, always bigendian, where a BOM has no sense. I'm sorry I can't currently investigate more. This should be reproduced, and if confirmed then upstreamed. I attach a small test QP UTF-8 text with an U+FEFF prepending a line, and another in the middle of a word. Bye!Alain. -- « if you believe in Glibc wcwidth(), I've got a bridge to sell you. » UTF-8 test file. Line prepended by U+FEFF. U+FEFF in the middle of the two d.
Bug#339555: mutt: Segmentation fault when displaying a iso8859-1 mail header
package mutt retitle 339555 regexec(): Latin chars segfault in Chinese locales reassign 339555 libc6 thanks Hello, On Monday, December 5, 2005 at 22:33:34 +0800, WANG Xu wrote: > Thanks for your explanation and hope the informations helpful. And thank you again for the precise report. Ye Fei, another Chinese guy, confirmed your exact symptoms. I can't do any better than reassign to Glibc, in the hope for more ideas. Summary: In LC_CTYPE=zh_CN.GBK or -.GB2312 locale, Mutt displaying a mail with Latin characters (coded in ISO-8859-1 or UTF-8) triggers a segfault in regexec(). Note some of those Latin chars do exist in GBK or GB2312 charset, just coded differently, and with a double-wide glyph (wcwidth(0xe9) returns 2). Context can be found in this bug track, and in the mutt-users subthread beginning at: | Date: Mon, 12 Jun 2006 09:02:21 +0200 | From: Ye Fei <[EMAIL PROTECTED]> | To: Mutt | Subject: Re: index_format and vs , segment fault | Message-ID: <[EMAIL PROTECTED]> Bye!Alain. -- Give your computer's unused idle processor cycles to a scientific goal: The [EMAIL PROTECTED] project at http://folding.stanford.edu/>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376275: why mutt doesn't display html format mails?
Hello Joshua, and thank you for the suggestion. On Saturday, July 1, 2006 at 17:25:21 +0200, Joshua Dunamis wrote: > I home thet in the futur i possible to view the html format mail > directly form mutt, may be with integration with links2 or with a > frame buffer interface of mutt Mutt is already able to display HTML mails. At will auto-viewed inline in the pager, in a text browser in the same terminal, or in a graphical browser aside. The user is free to interface whatever is his preferred browser of the day. Explanations about auto_view, $implicit_autoview, alternative_order, and mailcap are in the manual (press ), and detailed examples are on the Mutt Wiki at http://wiki.mutt.org/?MuttFaq/Attachment>. Bye!Alain. -- Mutt compressed folders tip for stable archive timestamp: | open-hook \\.gz$ "gzip -cd '%f' > '%t' ; ret=$? ; touch --no-create --reference='%f' '%t' ; exit \$ret" | close-hook \\.gz$ "gzip -c '%t' > '%f' ; ret=$? ; touch --no-create --reference='%t' '%f' ; exit \$ret" | append-hook \\.gz$ "gzip -c '%t' >> '%f'" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#364941: mutt: rfc2047 bug
On Friday, April 28, 2006 at 10:54:17 +0400, Dmitry E. Oboukhov wrote: > On 12:24 Thu 27 Apr , Alain Bench wrote: >> The $rfc2047_parameters setting is relevant to attachment filename >> decoding, not to subject. > And why is it not relevant for subject? All hi-bit subjects are (or should be) RFC2047 encoded. So Mutt always decodes 2047 subjects: A setting to disable this wouldn't make much sense. > According to this RFC http://www.faqs.org/rfcs/rfc2047.html it can be > applied to any message header, isn't it? Not all: RFC 2047 itself explicitly prohibits RFC 2047 encoding in some headers or part of headers. See chapter #5. Example: The parameters of the "Content-Disposition:" field MUST NOT use encoded words. The "filename=blah.dat" of an attachment is such a parameter. > However Mutt shows the mails, which have in their bodies/attaches > print-quoted format with spaces, correctly. What do you mean exactly? Don't confuse body and header: Spaces are allowed in QP body parts. > I'll use Your patch, thank You. :-\ You're welcome. BTW something munged the format of your reply, especially quotes. What happened? Bye!Alain. -- set honor_followup_to=yes in muttrc is the default value, and makes your list replies go where the original author wanted them to go: Only to the list, or with a private copy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372289: mutt: Detects wrong mime type on some .tar.gz, resulting in corrupt files
Hello Thomas, and thank you for your reports. On Friday, June 9, 2006 at 11:38:33 +0200, Thomas Bleher wrote: > When trying to attach > http://www.cip.ifi.lmu.de/~bleher/mutt-mime-bug.tar.gz , mutt assigns > the file the type and encoding "text/plain, quoted, utf-8" The foolable heuristic Mutt uses to guess text or binary attachment type would not be used at all if there was a tar.gz entry in one of the mime.types files. Example I have this line in /usr/local/etc/mime.types (straight from Mutt tarball): | application/x-tar-gz tgz tar.gz And attaching your file shows [applica/x-tar-gz, base64, 1,4K]. > This is on an Ubuntu Dapper system, but with the Debian mutt package I have no idea who is responsible for the mime.types file(s). Perhaps the "mime-support" or such package? Please feel free to reassign or close where/if applicable. In the meantime you can add the said line to ~/.mime.types Bye!Alain. -- How to Report Bugs Effectively http://www.chiark.greenend.org.uk/~sgtatham/bugs.html> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#420854: bad GPG signature on messages with attachments
Hello John-Marc, and thanks for this report. On Tuesday, April 24, 2007 at 18:48:02 -0700, John-Marc Chandonia wrote: > When I send a test message to myself without any attachments, the > signature validates correctly. However, if I attach anything to the > message, my signature does not validate; instead, it gives me a BAD > signature message. Something on your mail path is doing subtle modifications to passing messages, instead of transporting them as they are. I'd suspect MTAs, anti-spam, or most probably your MDA. Last time I saw a similar problem, the culprit was a Perl MDA built around Mail::Audit. Here "badtest" first gave me BAD sig. Then I edited it, adding here and there some empty lines inside the MIME structures (as normally generated by Mutt): Good sig. You should be able to see differences between badtest and your original message in $record. So: Not a Mutt bug. We need to locate the culprit software, and reassign this report to the appropriate package. Do you agree? Bye!Alain. -- Mail::Audit users break PGP for everyone else on a mailing list! They should stop doing so immediately! « Perl considered HARMFUL » PCC CB on MU. © June 2002
Bug#420014: mutt: s/mime, openssl supresses a signed message body when verification fails
Hello Vaclav, and thank you for this interesting suggestion, On Thursday, April 19, 2007 at 15:26:44 +0200, Vaclav Ovsik wrote: > Openssl (OpenSSL 0.9.8c 05 Sep 2006) suppresses message body in case > of verifycation failure (e.g. not trusting CA) [...] nothing is > displayed, but openssl error. While we want to see the text, together with the clear sig failure report, right. > My dirty solution for this now: >| set smime_verify_opaque_command="\ >| openssl smime -verify -inform DER -in %s %C ||\ >| openssl smime -verify -inform DER -in %s %C -noverify 2>/dev/null" Why "dirty"? This seems to be a quite proper solution. I would just remove the second "%C" because -noverify doesn't check CA certificates. To me this seems appropriate, both for Debian /etc/Muttrc and upstream contrib/smime.rc Bye!Alain. -- How to Report Bugs Effectively http://www.chiark.greenend.org.uk/~sgtatham/bugs.html> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#420598: mutt: segfaults in uxterm with > 254 columns if there are single byte 8-bit characters in index_format
On Tuesday, April 24, 2007 at 14:56:45 +0200, Axel Beckert wrote: > my .mutt/muttrc indeed has that line: >| set charset="iso-8859-1" I assume you meant $config_charset? Otherwise you should better not set $charset, so it is free to automatically follow whatever is the current locale. > to prevent loading /etc/Muttrc -n Bye!Alain. -- Everything about locales on Sven Mascheck's excellent site at new location http://www.in-ulm.de/~mascheck/locale/>. The little tester utility is at http://www.in-ulm.de/~mascheck/locale/checklocale.c>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#420014: mutt: s/mime, openssl supresses a signed message body when verification fails
On Friday, April 27, 2007 at 9:40:27 +0200, Václav Ovsík wrote: > I didn't found anything about this behaviour in smime man page and > I didn't test of this with older openssl 0.9.7 (perhaps not > interesting for Debian). I hope this behaviour (supressing output on > failure) will be consistent from 0.9.8 and up. For other tests I had various OpenSSL versions installed, and just checked: The same output suppression happens with 0.9.6n-dev, 0.9.7m-dev, and 0.9.8e-dev (the latest CVS revisions of each number). And your ||solution fixes everything: Bravo. :-) Bye!Alain. -- How to Report Bugs Effectively http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
Bug#420014: mutt: s/mime, openssl supresses a signed message body when verification fails
On Thursday, April 26, 2007 at 14:10:08 +0200, Alain Bench wrote: > To me this seems appropriate, both for Debian /etc/Muttrc and upstream > contrib/smime.rc That's now fixed upstream. I don't set the fixed-upstream tag here, because of the different place (/etc/Muttrc) where the fix has to go. And my memory has grave holes: I forgot that someone I _very_ well know had reported the same problem last year, as bug/2428 upstream... I would need a replacement RAM board. ;-) Bye!Alain. -- PuTTY 0.60 is released. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441950: mutt wish: send_charset default "us-ascii:utf-8"
Hello Adrian, and thank you for this suggestion. On Wednesday, September 12, 2007 at 7:46:26 +0200, Adrian Bunk wrote: > In the third millenium, with virtually all software supporting UTF-8 > and most users using UTF-8 locales, it would be nice if this [default > $send_charset] could be changed to "us-ascii:utf-8". Some rare mailers do not support UTF-8. Some rare platforms do not have well working UTF-8 locales, if at all. Many users prefer non-UTF-8 locales (for whatever reason). Changing $send_charset so would partly defeat this Mutt nice feature to autoselect the best adapted minimal necessary and sufficient charset. Feature compliant with the letter and spirit of the relevant RFCs. Feature also compliant with the best current practice. This change would reduce your mail's chances to be correctly read everywhere. And it would send heavier mails. ;-) So this default change is not a good idea, neither for Debian nor upstream Mutt. IMHO it's not even a sensible custom ~/.muttrc setting for yourself. I advice against it, but you do as you want of course. > This would e.g. make the sent-mail folder containing only UTF-8 and > not a mixture of two incompatible charsets. Right, that would be an advantage, for treatment by grep, less, vim, and such. However one can't expect a mail folder to be exactly the same as a normal text file. Besides various charsets, it may contain QP, base64, and encrypted texts. When I want to search a mail folder, I usually choose Mutt tool, in $thorough_search=yes mode: It does decode/decrypt/transcode/whatever, and matches against the resulting clear text. The grep command can be used against a mail folder, but it is expected to miss some occurences anyway. Having an UTF-8 only sent-mail folder would still perhaps be an advantage, but IMHO this can in no way justify breaking the $send_charset feature. Bye!Alain. -- « Be liberal in what you accept, and conservative in what you send. » Jon Postel / Robustness Principle / RFC 1122
Bug#437402: "postpone this message?" unclear
Hello Dan, and thank you very much for your reports.
On Sunday, August 12, 2007 at 19:42:05 +0800, Dan Jacobson wrote:
> Upon encountering "postpone this message?", the user worries if "n"
> will 1. throw away the message, or 2. go ahead and send the message,
> or 3. let him continue to edit the message, etc.
However this prompt happens when the user was in the compose menu,
didn't , but triggered the function (to "exit this
menu"). Logically, replying "n" can't do (2) nor (3).
Another possible question is what does ^G (abort)? Logically, ^G
aborts the whole procedure, and does (3), back to compose menu.
Granted, what's "logical" for the accustomed Mutt user, is perhaps
less logical for the casual or new user. However in past discussions
there were several voices (of hardcore Mutters) to not change this
prompt, considering it sufficiently clear ("current behavior seems both
satisfactory and obvious" has been said). There were also voices for a
change, but no proposal reached anywhere near any form of consensus.
Take especially a look at mutt-dev archives thread "phrasing
suggestion" in January 2005, beginning at msgid
<[EMAIL PROTECTED]>.
> Therefore that prompt's wording should be made clearer.
But can anyone propose a better wording? That would use the
"postpone" word consistently with everywhere else in Mutt and manual,
would make clearer what the 3 yes/no/abort replies do, would not
destabilize long-time users, and most of all, would stay short?
Bye!Alain.
--
Give your computer's unused idle processor cycles to a scientific goal:
The [EMAIL PROTECTED] project at http://folding.stanford.edu/>.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436007: Support for clear-flag and set-flag functions in the pager map
Bonjour Loïc, Le samedi 4 août 2007 à 17:58:05 +0200, Loïc Minier écrivait: > I often want to set/clear some flags on a message I'm reading; for > example mark it as important. Try function to "toggle a message's 'important' flag", by default bound to the [F] key. > I wish the set-flag and clear-flag functions would be available in the > "pager" key bindings map. In some way, those functions are already available from the pager, via macros like that: | macro pager w "set a status flag on a message" | macro pager W "clear a status flag from a message" Bye!Alain. -- Everything about locales on Sven Mascheck's excellent site at new location http://www.in-ulm.de/~mascheck/locale/>. The little tester utility is at http://www.in-ulm.de/~mascheck/locale/checklocale.c>.
Bug#420854: bad GPG signature on messages with attachments
package mutt close 420854 thanks Hi John-Marc, On Thursday, April 26, 2007 at 14:21:16 -0700, John-Marc Chandonia wrote: > It turned out to be a bug in "textmail" (http://raf.org/textmail/), so > I'll report it to the author. There doesn't seem to be a Debian > package for the program. Thanks for tracking this down: Let's close the Mutt report now. I would personally be interested to hear about any followups from textmail author: Could you please CC or forward me? BTW: MIMEDefang, another detacher Perl script of the same kind, seems to corrupt mails in a similar way. Bye!Alain. -- How to Report Bugs Effectively http://www.chiark.greenend.org.uk/~sgtatham/bugs.html> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#422557: mutt: thread markers make index lines wrap incorrectly in UTF-8 locales
On Thursday, May 17, 2007 at 21:38:10 -0400, John Morrissey wrote: > I tried Mac OS X's Terminal again and the index lines are still > wrapping with LANG=en_US.UTF-8 and Terminal -> Window Settings... -> > Display -> Character Set Encoding set to "Unicode (UTF-8)". The ACS chars seem OK, but anormally wide. Just like if they were double-width. Have you in Terminal.app config anything around Japanese, Chinese, Korean, and width of CJK ambiguous characters? > Mac OS X's Terminal [...] with TERM=vt100. TERM=xterm-color Both settings aren't very well suited. The appropriate entry is: | nsterm-16colorAppKit Terminal.app v100.1.8 with MacOS X 10.3.9 Bye!Alain. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#422557: mutt: thread markers make index lines wrap incorrectly in UTF-8 locales
On Saturday, May 19, 2007 at 12:26:13 -0400, John Morrissey wrote: > there is [in Terminal.app] a setting called 'Wide glyphs for > Japanese/Chinese/etc.' Unchecking this made these characters appear > properly Fine! Otherwise Takashi Takizawa coded a patch-1.5.14.tt.wcwidth.3 for Mutt, providing the $cjk_width boolean. Setting $cjk_width=yes would suit this "wide glyphs" terminal setting. | cjk_width | | Type: boolean | Default: no | | When this option is set, characters in the East Asian Ambiguous (A) | category as defined in Unicode Technical Report #11 have a column | width of 2. Othrwise, they have a column width of 1. This variant | might be useful for users of CJK legacy encodings who want to migrate | to UCS without changing the traditional terminal character-width | behaviour. | | Note: this option only affects in UTF-8 encoding. This patch is currently under evaluation for upstream inclusion. Rather positive for me so far. > Hope I'm not being presumptuous in closing this bug since it turned > out to be terminal settings. Good. Unless Debian wants to experiment including tt.wcwidth.3 before upstream, there is nothing more to do. > Sorry for the bother and thanks for your help, Alain! You're very welcome. Thank you again for the report, John: As I always say, better a false alarm than a missed bug. And I'm grateful for some of the precise feedback infos you gave, thanks. Bye!Alain. -- When you want to reply to a mailing list, please avoid doing so from a digest. This often builds incorrect references and breaks threads. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441950: mutt wish: send_charset default "us-ascii:utf-8"
On Friday, September 21, 2007 at 1:02:40 +0200, Adrian Bunk wrote: > if you e.g. use the € sign in an email (not that uncommon in the areas > covered by iso-8859-1) or write in French and use the character œ mutt > already has to send it as UTF-8 with the current default. Very right. However, this is an excellent argument for inserting Latin-9 into the default $send_charset, between Latin-1 and UTF-8. I'm not against such change: Once granted Mutt already has a moderately western-centric default config, why not make it better? > On Thu, Sep 20, 2007 at 04:57:11PM +0200, Alain Bench wrote: >> this can in no way justify breaking the $send_charset feature. > "breaking" is really a hard word. Sorry: I unwrite it, and instead "prevent it to work optimally". > Consider your locale uses charset A, you create a patch for a source > file in charset B, include it using "insert-file" in your editor, and > let your MUA send it with charset C. Patches are indeed a special case among other texts. I'd generally attach them via compose: (a), then force their outgoing charset to B via compose: (^T), and reply negatively to the following "Convert to B upon sending? ([yes]/no):" prompt. Result sent is the straight B patch under the MIME charset=B label. If I "insert-file" a short patch in my editor, it's not to apply it, but to discuss it. I then want it to follow the normal $charset to $send_charset processing, as my own text, so that composed text and patch are readable together. But in fact I most frequently a patch.gz as application/x-gunzip. That's even a script that helps me doing it: Adds a PATCHES tag, GnuPG --clearsign --not-dash-escaped it, gzips it, and copies it to Mutt's directory ready to be d. Footnote: The conv/noconv hint gets displayed in the Attachments and Compose menus when $attach_format contains the %c expando. Bye!Alain. -- Mutt muttrc tip to send mails in best adapted first necessary and sufficient charset (version for East Europe Latin-2/CP-852/CP-1250 terminal users): set send_charset="us-ascii:iso-8859-1:iso-8859-15:windows-1252:iso-8859-2:windows-1250:utf-8"
Bug#444318: mutt: gpg verification requires ^L (redraw)
Hello Owen, and much thanks for the problem report. On Thursday, September 27, 2007 at 12:06:05 -0500, Owen Heisler wrote: > Every time a pgp signed message is viewed in mutt's pager, I have to > redraw the screen (^L) in order to read the message, as the gpg output > scrolls up the text on the screen. What happens after you unset $pgp_getkeys_command? Bye!Alain. -- Mutt muttrc tip for mailing lists: set followup_to=yes and declare the list as - subscribe [EMAIL PROTECTED] if you are subscribed and don't want courtesy copy. - lists [EMAIL PROTECTED] if you are not subscribed or want a courtesy copy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444318: mutt: gpg verification requires ^L (redraw)
package mutt # misconfiguration issue close 444318 thanks On Saturday, October 13, 2007 at 11:17:45 -0500, Owen Heisler wrote: > Thanks and sorry for the noise! No problem: Better a false alarm than a missed bug. ;-) Bye!Alain. -- Give your computer's unused idle processor cycles to a scientific goal: The [EMAIL PROTECTED] project at http://folding.stanford.edu/>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474506: decode-copy removes attachments
package mutt # works as designed close 474506 thanks Hello Martin, and thank you for the report. On Sunday, April 6, 2008 at 11:52:46 +0200, Martin F. Krafft wrote: > If I decode-save or decode-copy a mail [...] the attachment are > removed in the copy. The attachment should stay. The design is: Auto_viewed attachments stay. Or rather their text representation stays. Other attachments are removed, because they are not renderable as text, or just not rendered in current settings (auto_view/unauto_view, $implicit_autoview, mailcap, ...). Look at upstream closed bug #1072 for complete explanations. | make decoded (text/plain) copy | make decoded copy (text/plain) and delete I can foresee your next question, and the replies are and . Those keep all attachments in their original form. | make decrypted copy | make decrypted copy and delete Bye!Alain. -- Everything about locales on Sven Mascheck's excellent site at new location http://www.in-ulm.de/~mascheck/locale/>. The little tester utility is at http://www.in-ulm.de/~mascheck/locale/checklocale.c>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474539: mutt: Add MIME information for message/rfc822
Hello Jörg, and thanks for the suggestion. On Sunday, April 6, 2008 at 14:06:06 +0200, Jörg Sommer wrote: > message/rfc822; mutt -R -f '%s'; edit=mutt -f '%s'; needsterminal You should not put single-quotes around %s in mailcap. Mutt does this for you, the right way, as should any other program which interprets mailcap [manual.txt chapter 3.2. Secure use of mailcap]. Bye!Alain. -- When you want to reply to a mailing list, please avoid doing so with iPlanet Messenger Express 5.2. This lacks necessary references and breaks threads.
Bug#379107: Reasoning behind 'encoding'/'termencoding' differences
Hello Kurt, James, On Thursday, April 3, 2008 at 19:23:53 +0200, Kurt Roeckx wrote: > The termencoding should be based on the LCTYPE, and what "locale > charmap" or nl_langinfo(CODESET) returns. I see no reason why you ever > want this to be something else. Exactly. That should have been The proverbial Good Design. I don't even understand the logic behind Vim's current somewhat twisted scheme, and think that nothing can seriously justify it. The fact that one single vimrc line fixes the problem is of course an excellent thing, but it is not an excuse. My humble opinion on the best move here: -1) Adopt "let &termencoding = &encoding" in config. -2) Talk to upstream about the design. -3) I have no opinion about changing default encoding. Current default or forced utf-8, both make sense. > mutt and vim not agreeing on the encoding of the file. For this reason > I also have to use: >| au FileType mail setlocal fenc=latin1 This is hardcoding a given charset, which should be avoided when possible, because the Mutt+Vim couple would break in any other locale. The ideal setting should follow the charset of the current locale. If I correctly understood your settings, &fenc = &termencoding Bye!Alain. -- How to Report Bugs Effectively http://www.chiark.greenend.org.uk/~sgtatham/bugs.html> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436007: Support for clear-flag and set-flag functions in the pager map
Le mardi 28 août 2007 à 22:50:12 +0200, Loïc Minier écrivait: > unfortunately, [pager's ] only works for the > "important" flag The pager has functions for manipulating many flags: | flag key functionhelp |--- | ! F toggle a message's 'important' flag | N N toggle a message's 'new' flag | D d delete the current entry | D u undelete the current entry | * t tag the current entry |--- Only "O" and "r" flags seemingly lack (unless counts ;-). > and has the side effect of moving to the next message (I guess that's > a feature). Feature controlled by the $resolve switch, on by default. [] > Hmm that's not very practical; I simply want to toggle a flag, not > stop reading the message. :-/ Well, anyway $resolves to the next message, by default. So my macros and pager: would equally stop you from reading the current message. Granted, pager: would stay in pager, while my macros eject you to the index. Hum... what about: | macro pager O "mark message Old" | macro pager O"mark message read" Unfortunately it's not possible to prompt the user in the middle of a macro. The macro has to embed the response. > These are certainly helpful workarounds, but it seems to me it would > be very natural to have "clear-flag" and "set-flag" available Natural, I agree. OTOS this would mean more code. And a longer list of functions, when we already have so many that users may be lost. Adding code, , and $vars should be done primarily for interesting new features not doable otherwise. My opinion is not done yet: I'd need to hear more arguments, and think to it. Bye!Alain. -- How to Report Bugs Effectively http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
Bug#347375: mutt: Always show that there is new mail in all mailboxes
package mutt close 347375 thanks Hello Dmitry, and thanks for reporting this problem. On Tuesday, January 10, 2006 at 14:07:10 +0200, Dmitry Nezhevenko wrote: > mutt show N for _all_ mailboxes including mailboxes without new mail. You are most probably using mbox folders on a noatime partition. Mutt wants correct last access time in the filesystem. Bye!Alain. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347256: mutt doesn't show that mailbox contains new mail
package mutt close 347256 thanks Hello, thanks for this report. On Monday, January 9, 2006 at 19:57:20 +0100, A.M.P. Boelens wrote: > When I type "M" to see all my mailboxes, mutt not always indicates > that there is a new e-mail in a specific mailbox (by putting an "N" in > front of it) while, when I acces the mailbox, there is. I have not > been able to figure out when new mail is indicated or not. An mbox modified after last read access is considered New. This specific mailbox is probably accessed by another process. Hit for some basic infos about Mutt. I close this not-a-bug, but please feel free to request a reopen if you spot any Mutt malfunction. Bye!Alain. -- Everything about locales on Sven Mascheck's excellent site at new location http://www.in-ulm.de/~mascheck/locale/>. The little tester utility is at http://www.in-ulm.de/~mascheck/locale/checklocale.c>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351890: mutt: dangerous handling of attachment filenames
Hello Tobias, and thank you for the report. On Wednesday, February 8, 2006 at 10:47:32 +0100, Tobias Stefan Richter wrote: > I just saved an attachment by the name > =?ISO-8859-15?Q?=DCberraschung=2Ezip?= as it was received due to > (improper?) encoding. Illegal encoding, explicitly prohibited by RFC 2047. Attachment filenames have to use another encoding: RFC 2231. But you still can persuade Mutt to decode this, by setting $rfc2047_parameters. RFC violation should be reported to the sender software. What is it? Microsoft Outlook [Express]? > I'm not sure if the = -> $MAIL expansion is desired in the attachment > menu at all (I don't think so) I vaguely seem to recall from previous discussions that this is a desired expansion. > but it should for sure not be used with filenames supplied by remote > parties. Some sanitizing might be good, right. There is already bug #1719 opened upstream since a long time about "attachments with =names stored in $folder by default". Clearly said: Fixing this seems not to be seen as an absolute priority. Do you want me to add you to the Notify-List of #1719? Bye!Alain. -- Everything about locales on Sven Mascheck's excellent site at new location http://www.in-ulm.de/~mascheck/locale/>. The little tester utility is at http://www.in-ulm.de/~mascheck/locale/checklocale.c>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#364941: mutt: rfc2047 bug
package mutt
retitle 364941 mutt: wish less strict RFC 2047 header decoding
severity 364941 wishlist
tags 364941 patch
thanks
Hello Dmitry, and thank you for the report.
On Thursday, April 27, 2006 at 0:02:52 +0400, Dmitry E. Oboukhov wrote:
> in .muttrc: set rfc2047_parameters = yes
The $rfc2047_parameters setting is relevant to attachment filename
decoding, not to subject.
>| Subject: =?koi8-r?Q?iXBT BBS=3A =F2=C5=C7=C9=D3=D4=D2=C1=C3=C9=CF=CE=CE=C1=D1
>| =C9=CE=C6=CF=D2=CD=C1=C3=C9=D1 =C4=CC=D1 nobody=2C eet=40uvw=2Eru?=
> not correct showed in mutt (RFC-correct header)
This encoded word contains spaces, and that's prohibited. The mailer
sending such invalid RFC 2047 subject is at fault. Mutt is strict on
that: Feature, no bug.
Now, such invalid 2047 headers are unfortunately not rare in the
wild, and Mutt's strictness may be seen as an annoyance. See undecided
pros and cons discussion in upstream wish/1062. There are 2 alternatives
for this Bug#364941 here:
-1) Close Bug#364941 as not a Mutt bug.
-2) Apply the attached patch relaxing strictness to spaces and tabs. In
practice I never had a single drawback using it here in production since
years.
I vote for (2) but don't decide. What do you think?
Note: There are various similar patches floating around, relaxing yet
more Mutt's strictness, to question marks, or to spaces even in the
charset label. I'm not for that, because prevalence of such broken mails
is low, and so low would be the practical benefit. While possible
existence of drawbacks is not thoroughly checked.
Bye!Alain.
--
« Be liberal in what you accept, and conservative in what you send. »
Jon Postel / Robustness Principle / RFC 1122
diff -dur mutt-1.4/rfc2047.c mutt-1.4.mod/rfc2047.c
--- mutt-1.4/rfc2047.c Sat Apr 20 09:25:49 2002
+++ mutt-1.4.mod/rfc2047.c Mon Jun 10 19:01:55 2002
@@ -705,7 +707,7 @@
;
if (q[0] != '?' || !strchr ("BbQq", q[1]) || q[2] != '?')
continue;
-for (q = q + 3; 0x20 < *q && *q < 0x7f && *q != '?'; q++)
+for (q = q + 3; 0x20 <= *q && *q < 0x7f && *q != '?' || *q == 0x09; q++)
;
if (q[0] != '?' || q[1] != '=')
{
--- PATCHES Tue Nov 6 19:59:33 2001
+++ PATCHES Tue Nov 6 19:59:42 2001
@@ -1,0 +1 @@
+patch-1.4.ab.decode_2047_invalid.2
Bug#360912: mutt: temporary files deleted too fast ?
package mutt close 360912 thanks Hello Pascal, and thank you for reporting us this problem. On Wednesday, April 5, 2006 at 16:01:30 +0200, Pascal A. Dupuis wrote: > [mailcap] deletion of the temp file occurs too early, before galeon > get a chance to load it. Mutt deletes the temporary file when the called process returns. This is not a bug, but admitedly may not suit background running apps. Gary Johnson's excellent mutt_bgrun is the usual solution. Bye!Alain. -- When you want to reply to a mailing list, please avoid doing so with NetCourrier Webmail. This lacks necessary references and breaks threads. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
