[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems with ISO8859-2 filenames
From: |
Kenichi Handa |
Subject: |
Re: problems with ISO8859-2 filenames |
Date: |
Mon, 10 Dec 2001 12:56:40 +0900 (JST) |
User-agent: |
SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.1.30 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) |
Richard Stallman <address@hidden> writes:
> It's clear that that problem is inherited from
> command-line-args, which is also similarly unibyte.
> Here's the code that constructs the value
> for (i = argc - 1; i >= 0; i--)
> {
> if (i == 0 || i > skip_args)
> Vcommand_line_args
> = Fcons (build_string (argv[i]), Vcommand_line_args);
> }
> It makes no attempt to decode any coding system. startup.el where the
> arguments are processed likewise does not do this. Perhaps it should.
> Handa, what do you think?
Long ago, I wrote that we should decode them by
locale-coding-system (see the attached mail).
I think the best place to do that is just after:
(set-locale-environment nil)
in the function command-line.
> As for these problems
>> 2. The same name is shown with ISO-8859-1 font in the buffer menu (after
>> C-down-mouse-1).
>>
>> 3. The same name is shown with ISO-8859-1 font in the menu Buffers in the
>> menu-bar.
> I've been able to determine that Emacs's menu data structures
> contain the same Latin-2 characters that appear in buffer-file-name.
> So this seems to be a bug in the display of the actual menus.
> Since the menus are displayed by toolkits rather than by Emacs,
> it is not susprising they have problems. Would you like to investigate
> what happens inside lwlib.c and lwlib-X*.c for that string?
> Also, what's an app supposed to do to make these toolkits display
> Latin-2 in the menu strings?
For this also, I wrote that:
(1) At first, we must encode the menu string by
locale-coding-system.
(2) Then, ask internationalized toolkits to handled it
correctly.
I've just checked codes under `lwlib' subdir. They are not
internationalized. They should use XmbDrawString or
XwcDrawString instead of current XDrawString.
---
Ken'ichi HANDA
address@hidden
----------------------------------------------------------------------
Date: Mon, 5 Nov 2001 20:39:18 +0900 (JST)
From: Kenichi Handa <address@hidden>
To: address@hidden
CC: address@hidden
In-reply-to: "address@hidden"'s message of Mon, 05 Nov 2001 11:11:56 +0100
Subject: Re: problems with ISO8859-2 filenames
address@hidden (Pavel Janík) writes:
> One of my friends discovered this problem:
> LANG=cs_CZ emacs -q /tmp/ěščřžýáíé.txt
> It will open the real file /tmp/ěščřžýáíé.txt, but in the mode-line, the
> filename will be shown with ISO-8859-1
> fonts. See http://www.janik.cz/tmp/emacs-iso-filenames.png When you kill
> the buffer and visit the file again, its name is displayed correctly in the
> mode-line. Hmm, should we treat argv fields as strings in user's preferred
> coding-system?
I think the argv fields should be decoded by
locale-coding-system.
> Another problem is that the name of this file is displayed with ISO-8859-1
> fonts in the Buffers menu and Buffer pop-up menu even when it is visited
> with C-x C-f ie. not from the command line.
Currently, on Windows-NT, they are encoded by
Vw32_system_coding_system, but on the other systems, we just
make them unibyte by string_make_unibyte. These are done by
the macro ENCODE_SYSTEM defined in coding.h.
See this code in xmenu.c:
#ifndef HAVE_MULTILINGUAL_MENU
if (STRINGP (pane_name) && STRING_MULTIBYTE (pane_name))
{
pane_name = ENCODE_SYSTEM (pane_name);
AREF (menu_items, i + MENU_ITEMS_PANE_NAME) = pane_name;
}
#endif
On X, nowadays, we can use an internationalized tool kit.
With it, at least, we can display those file names on menu,
etc, correctly. I don't know how menu, etc are implemented
in Emacs, but, at least, to utilize the international
facility of the tool kit, we must encode PANE_NAME and etc
by locale-coding-system
BTW, I don't know how Vw32_system_coding_system is decided.
Is it different from locale-coding-system?
---
Ken'ichi HANDA
address@hidden