non-Windows definitions of {EN,DE}CODE_SYSTEM

[Dave Love]

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.