--- Begin Message ---
Subject: |
23.0.60; [Regression] Implicit utf-8 no longer correctly decoded in gnus |
Date: |
Sun, 22 Jun 2008 02:37:34 -0400 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux) |
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the address@hidden mailing list.
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
For the last few weeks gnus no longer correctly displays utf-8 data in
articles or mime-parts which do not explicitly declare themselves to be
utf-8. Before, this just worked.
It is very common with commit messages that the mime block for the
message has no local headers, or they don’t use mime at all, and also do
not specify a charset in the main headers. This used to display
correctly, but no longer does so.
As an example, ‘ and ’ display as ^X and ^Y (in the escape-glyph face).
Using C-ug shows that the correct octets are there.
Saving the article or mime block saves the incorrect data, whereas
caching the article (with *) saves the correct octet-stream. Viewing
the cached article outside of gnus works (at least, of course, in a
UTF-8 locale...).
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/share/emacs/23.0.60/etc/DEBUG for instructions.
In GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2008-06-21 on lugabout
Windowing system distributor `The X.Org Foundation', version 11.0.10599001
configured using `configure '--prefix=/usr' '--host=i686-pc-linux-gnu'
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share'
'--sysconfdir=/etc' '--localstatedir=/var/lib' '--program-suffix=-emacs-23'
'--infodir=/usr/share/info/emacs-23' '--without-carbon' '--with-sound'
'--with-x' '--with-toolkit-scroll-bars' '--with-gif' '--with-jpeg' '--with-png'
'--with-rsvg' '--with-tiff' '--with-xpm' '--enable-font-backend'
'--with-freetype' '--with-xft' '--with-libotf' '--with-m17n-flt'
'--with-x-toolkit=athena' '--without-hesiod' '--with-kerberos'
'--with-kerberos5' '--with-gpm' '--with-dbus' '--build=i686-pc-linux-gnu'
'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu'
'CC=i686-pc-linux-gnu-gcc' 'CFLAGS=-march=pentium3 -O2' 'LDFLAGS=
-Wl,--as-needed ''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: C
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: C
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default-enable-multibyte-characters: t
Major mode: Group
Minor modes in effect:
gnus-undo-mode: t
show-paren-mode: t
display-time-mode: t
tooltip-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
Recent messages:
Auto-saving...done
Making completion list... [2 times]
Quit
Type C-x 1 to remove help window.
Making completion list...
--- End Message ---
--- Begin Message ---
Subject: |
Re: bug#464: 23.0.60; [Regression] Implicit utf-8 no longer correctly decoded in gnus |
Date: |
Thu, 30 Sep 2010 19:36:24 +0200 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) |
James Cloos <address@hidden> writes:
> So it is in fact only mail with Content-Transfer-Encoding: 8bit which
> now fail, but which used to work as of four to eight weeks ago, or so.
I'm unable to reproduce this bug with Emacs 24 -- utf-8, 8bit
Content-Transfer-Encoding and no charset= works for me.
--
(domestic pets only, the antidote for overdose, milk.)
address@hidden * Lars Magne Ingebrigtsen
--- End Message ---