[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6974: Emacs doesn't like Swedish ä (on w32)

From: Andreas Röhler
Subject: bug#6974: Emacs doesn't like Swedish ä (on w32)
Date: Fri, 03 Sep 2010 10:03:32 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv: Gecko/20100711 Thunderbird/3.0.6

Am 02.09.2010 23:58, schrieb Lennart Borgman:
I have a file whose name contains the Swedish char ä (a with two dots
above, 228 in latin-1).

I have seen several strange things with this. Here are some I remember:

I start from "emacs -Q". In an org-mode file I try to insert a link to
this file with "C-c C-l file FILENAME".

* After M-x set-language-environment RET RET (i.e. "English") and then
opening a new org file.

Works nicely. Examining the char "ä" in the link in the org buffer
gives as expected.

         character: ä (228, #o344, #xe4)
preferred charset: unicode-bmp
                   (Unicode Basic Multilingual Plane (U+0000..U+FFFF))
        code point: 0xE4
            syntax: w   which means: word
          category: .:Base, j:Japanese, l:Latin
       buffer code: #xC3 #xA4
         file code: #xE4 (encoded by coding system iso-latin-1-dos)
           display: by this font (glyph code)
New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x6C)

In this case I can save the file as usual.

* After M-x set-language-environment RET utf-8 RET and then opening a
new org file.

When choosing the file the char "ä" is shown as \344. It looks the
same when inserted in the buffer as an org link to the file.

         character:   (4194276, #o17777744, #x3fffe4)
preferred charset: eight-bit (Raw bytes 128-255)
        code point: 0xE4
            syntax: w   which means: word
       buffer code: #xE4
         file code: not encodable by coding system utf-8-dos
           display: no font available

After this I can not save the file (or rather Emacs prompts me for a
coding system).

I also saw that pasting the file name in some circumstances converts
the char "ä" (or was it \344) to a space. Unfortunately I do not
remember how that happened and I can not reproduce it now. (But I am
very sure it happened this morning.)

In GNU Emacs (i386-mingw-nt5.1.2600)
  of 2010-08-10
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags
-Ic:/g/include -fno-crossjumping'


seeing the similar:

when opening a file containing non-ascii chars, german
umlauts for example, in some case these aren't shown
as glyphs but as numbers.

See screenshot attached how the following code looks

  '(("Infinity" "∞" nil 0)
    ("alpha" "α" nil 2)
    ("beta" "β" nil 1)
    ("gamma" "γ" nil 1)
    ("theta" "θ" nil 0)))

As the only thing I remember since, is the use of

GNU Emacs (i686-pc-linux-gnu, GTK+ Version 2.12.0) of 2010-08-28

assume the bug is there.

BTW if I paste the wrongly shown text into this mail for example,
glyphs are shown correctly.



Attachment: zeichen.png
Description: PNG image

reply via email to

[Prev in Thread] Current Thread [Next in Thread]