non-Windows definitions of {EN,DE}CODE_SYSTEM

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.