emacs-devel
[Top][All Lists]
Advanced

[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





reply via email to

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