user-full/login-name not coding-system decoded

[Göran Uddeborg]

In GNU Emacs 21.2.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-06-27 on astest
configured using `configure  i386-redhat-linux --prefix=/usr --exec-prefix=/usr 
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share 
--includedir=/ussr/include --libdir=/usr/lib --libexecdir=/usr/libexec 
--localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man 
--infodir=/usr/share/info --with-gcc --with-pop --with-sound'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: sv_SE
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Unless I'm mistaken, there is no way to specify what coding system to
use for strings taken from "the system", such as user-login-name and
user-full-name.  To me, that seems like a bug.

This machine is running in a Latin-1 environment.  For file contents,
emacs handles this perfectly.  My login name is "g o-diaeresis r a n",
where o-diaeresis is also encoded using Latin-1, i.e. 0xF6.

In the user-login-name string this o-dieaeresis is also encoded 0xF6.
That seems to cause a number of issues.

To give a concrete example of something which fails: VC mode on RCS
controlled files:

- Create a RCS controlled file:
    uebn> echo apa > apa
    uebn> ci -l apa
    apa,v  <--  apa
    enter description, terminated with single '.' or end of file:
    NOTE: This is NOT the log message!
    >> apa
    >> .
    initial revision: 1.1
    done

- Then, start emacs on this file:
    uebn> emacs -q apa

- Modify the file:
    RET

- Try to check in the modified file
    C-x v v

- First I get a question if I want to save the file.  I answer yes:
    y

- Then I get the question
    Steal the lock on /tmp/apa:1.1 from göran? (yes or no) 
  (In case this get's mangled in the mail, it says: "... f r o m SPC g
    o-deaeresis r a n ? ...")

Well, that is me already!  If I answer yes I get the chance to send
myself a letter and tell me I stole my lock.  But then when I try to
check the file in I get the same question again.

The critical part in this case, I believe, is
vc-rcs-fetch-master-state in vc-rcs.el.  It fetches the name of the
user who has locked the file with an expression

             (vc-parse-buffer (concat "^locks[ \t\n]+[^;]*[ \t\n]+\\([^:]+\\):"
                                      (regexp-quote workfile-version)
                                      "[^0-9.]")
                              1)))

This expression will return a coding-system decoded string:
"g\x8f6ran".  Then it compares this with my login name

         ((and (stringp locking-user)
               (string= locking-user (vc-user-login-name)))

But vc-user-login-name, using user-login-name, returns a non-decoded
string: "g\xf6ran".  And these two strings of course does not compare
equal.

(Debugging this is made more challenging by the fact that both those
strings are shown using o-diaeresis in various contexts.  But I guess
it would be too easy otherwise. :-)

Recent input:
<return> C-x v v y n o <return> M-x r e p o r t <tab> 
<return>

Recent messages:
Loading /usr/share/emacs/site-lisp/site-start.d/lang.emacs.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/php-mode-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/po-mode-init.el (source)...done
For information about the GNU Project and its goals, type C-h C-p.
Loading vc...done
Wrote /tmp/apa
vc-steal-lock: Steal canceled
Loading emacsbug...done
call-interactively: Text is read-only
call-interactively: End of buffer [3 times]