[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
non-Windows definitions of {EN,DE}CODE_SYSTEM
From: |
Dave Love |
Subject: |
non-Windows definitions of {EN,DE}CODE_SYSTEM |
Date: |
Mon, 29 Sep 2003 18:18:15 +0100 |
User-agent: |
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux) |
Is there a good reason for the current definition of these things on
non-Doze systems? As far as I can tell, this would be better,
following the WINDOWSNT case:
*** coding.h.~1.68.~ Wed Sep 3 16:00:05 2003
--- coding.h Tue Sep 16 18:46:17 2003
***************
*** 609,616 ****
#else /* WINDOWSNT */
! #define ENCODE_SYSTEM(str) string_make_unibyte(str)
! #define DECODE_SYSTEM(name) name
#endif /* !WINDOWSNT */
--- 609,626 ----
#else /* WINDOWSNT */
! #define ENCODE_SYSTEM(str) \
! (! NILP (Vlocale_coding_system) \
! ? code_convert_string_norecord (str, Vlocale_coding_system, 1) \
! : str)
! #define DECODE_SYSTEM(name) \
! (! NILP (Vlocale_coding_system) \
! ? code_convert_string_norecord (str, Vlocale_coding_system, 0) \
! : str)
! /* The following (original) definitions cause considerable confusion
! if you try to display inappropiately-encoded text in menus. */
! /* #define ENCODE_SYSTEM(str) string_make_unibyte(str) */
! /* #define DECODE_SYSTEM(name) name */
#endif /* !WINDOWSNT */
I think it would typically give less misleading results if you try to
put non-ASCII text in a non-gtk menu. local-coding-system seems to be
the appropriate coding system, at least for X with the server and
client running in the same locale.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- non-Windows definitions of {EN,DE}CODE_SYSTEM,
Dave Love <=