[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
user-full/login-name not coding-system decoded
From: |
Göran Uddeborg |
Subject: |
user-full/login-name not coding-system decoded |
Date: |
Sat, 14 Sep 2002 00:53:20 +0200 |
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]
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- user-full/login-name not coding-system decoded,
Göran Uddeborg <=