Re: problems with ISO8859-2 filenames

[Richard Stallman]

    After emacs -q, C-x C-f /tmp/ì¹èø¾ýáíé.txt:

    buffer-file-name's value is 
    "/tmp/ì¹èø¾ýáíé.txt"
    Local in buffer ì¹èø¾ýáíé.txt; global value is nil

    When the file name is specified on the cmdline, it is:

    buffer-file-name's value is 
    "/tmp/\354\271\350\370\276\375\341\355\351.txt"

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?

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?