6:13 p.m.
Problems with this patch:
1. It doesn’t deal with the ＠modifier syntax in Unix locale specifications,
which are structured like so:
language[_territory][.codeset][＠modifier]
2. It’s relatively complex code to be called so early on startup.
Advantages to this patch:
1. More stuff just works under Unix; in particular, the coding system
reflects the user’s environment much more consistently--it adds some support
for ISO-8859-15 locales, which previously were treated identically to
iso-8859-1.
2. It’s possible for me to start up in, for example, the directory
"/tmp/aidan/за родину!" with a LC_CTYPE setting of en_US.UTF-8, and have
XEmacs treat the current directory’s name as being encoded in UTF-8.
lisp/ChangeLog addition:
2006-11-12 Aidan Kehoe <kehoea(a)parhasard.net>
* mule/mule-cmds.el (get-language-environment-from-locale):
If the Unix locale matches, and the language environment doesn't
use the coding system specified in that locale, create a new one
on the fly that does, and return that language environment.
XEmacs Trunk source patch:
Diff command: cvs -q diff -Nu
Files affected: lisp/mule/mule-cmds.el
===================================================================
RCS
Index: lisp/mule/mule-cmds.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/lisp/mule/mule-cmds.el,v
retrieving revision 1.27
diff -u -u -r1.27 mule-cmds.el
--- lisp/mule/mule-cmds.el 2005/12/24 21:59:21 1.27
+++ lisp/mule/mule-cmds.el 2006/11/12 17:59:40
＠＠ -1018,23 +1018,64 ＠＠
"Convert LOCALE into a language environment.
LOCALE is a C library locale string, as returned by `current-locale'.
Uses the `locale' property of the language environment."
- (or (gethash locale langenv-to-locale-hash)
- (let ((retval
- (block langenv
- (dolist (langcons language-info-alist)
- (let* ((lang (car langcons))
- (locs (get-language-info lang 'locale))
- (case-fold-search t))
- (dolist (loc (if (listp locs) locs (list locs)))
- (if (cond ((functionp loc)
- (funcall loc locale))
- ((stringp loc)
- (string-match
- (concat "^" loc "\\([^A-Za-z0-9]\\|$\\)")
- locale)))
- (return-from langenv lang))))))))
- (puthash locale retval langenv-to-locale-hash)
- retval)))
+ (or
+ (gethash locale langenv-to-locale-hash)
+ (let ((retval
+ (block langenv
+ (dolist (langcons language-info-alist)
+ (let* ((lang (car langcons))
+ (locs (get-language-info lang 'locale))
+ (case-fold-search t)
+ (coding-system-name ""))
+ (dolist (loc (if (listp locs) locs (list locs)))
+ (if (cond ((functionp loc)
+ (funcall loc locale))
+ ((stringp loc)
+ (when (string-match
+ (concat "^" loc
+ "\\([^A-Za-z0-9]\\|$\\)")
+ locale)
+ ; (debug-print "Dealing with language %s"
+ ; loc)
+ (setq coding-system-name
+ (replace-in-string
+ (replace-in-string
+ (or
+ (downcase
+ (or (car-safe
+ (nreverse
+ (split-string locale "\\."
+ t)))
+ locale)) locale)
+ "iso8859" "iso-8859" t)
+ "euc\\([^-]\\)" "euc-\\1"))
+ ; (debug-print "coding system name is %s"
+ ; coding-system-name)
+ (if (eq (find-coding-system
+ (intern coding-system-name))
+ (get-language-info
+ lang 'native-coding-system))
+ lang
+ (set-language-info-alist
+ (setq lang (concat
+ lang " ("
+ coding-system-name ")"))
+ (destructive-plist-to-alist
+ (plist-put
+ (plist-put
+ (alist-to-plist (cdr langcons))
+ 'native-coding-system
+ (intern coding-system-name))
+ 'coding-system
+ (cons
+ (intern coding-system-name)
+ (cdr
+ (assoc 'coding-system
+ (cdr langcons))))))))
+ t)))
+ (return-from langenv lang))))))))
+ (puthash locale retval langenv-to-locale-hash)
+ retval)))
(defun mswindows-get-language-environment-from-locale (ms-locale)
"Convert MS-LOCALE (an MS Windows locale) into a language environment.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
3:50 a.m.
VETO
Correctness before convenience, please. I agree with you that the
language environment stuff is broken with regards to understanding
about various environments, especially those using UTF-8, but this is
patching an inconvenience without fixing the real problem.
Aidan Kehoe writes:
1. It doesn’t deal with the ＠modifier syntax in Unix locale
specifications,
which are structured like so:
To deal with the ＠modifier syntax you'll need to provide a hook. At
least in POSIX.1 the ＠modifier stuff was basically implementation
and/or site-specific. There are common ones, you can provide a
default implementation if you like.
2. It’s possible for me to start up in, for example, the directory
"/tmp/aidan/за родину!" with a LC_CTYPE setting of
en_US.UTF-8, and have
XEmacs treat the current directory’s name as being encoded in UTF-8.
LC_CTYPE is a user preference on a multilingual system, but the file
system encoding is typically a site-wide parameter, sometimes enforced
by (some subsystem of) the OS. As I understand it, under Mac OS X
with HFS+ file names are UTF-8 with the maximally decomposed
canonicalization. Period. IIRC Japanese VFAT file systems are always
Shift JIS. If file-name-coding-system is reset to something else,
these systems will generate very confusing errors. On other systems
I've used, the file system is EUC-JP even though I used ja_JP.UTF8 or
en_US.ISO8859-1 for the default content encoding. Depending on what
I'm doing, it's often convenient to change locales. If XEmacs were to
pay attention to the locale for this parameter, hilarity (not to
mention annoyance) would ensue.
This should be handled by setting file-name-coding-system in the
site-start.el file, not by paying attention to user locale settings.
2006-11-12 Aidan Kehoe <kehoea(a)parhasard.net>
* mule/mule-cmds.el (get-language-environment-from-locale):
If the Unix locale matches, and the language environment doesn't
use the coding system specified in that locale, create a new one
on the fly that does, and return that language environment.
<== #### NOTE NOTE NOTE bogus trailing whitespace
I wish you'd not do this. Some of my private tools expect the regexp
"\n\n\d{4}-\d{2}-\d{2} " to match start-of-log-entry, and for "\n\n"
to separate stanzas in a log entry.
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
8:56 a.m.
Ar an triú lá déag de mí na Samhain, scríobh stephen(a)xemacs.org:
VETO
Correctness before convenience, please. I agree with you that the
language environment stuff is broken with regards to understanding
about various environments, especially those using UTF-8, but this is
patching an inconvenience without fixing the real problem.
I don’t think “correct” is possible for this problem. “Better” is
possible, but the POSIX locale format lacks standardisation, and the various
platforms have taken full advantage of that to create needlessly
incompatible locale names. I mean, there’s an en_IE.iso885915＠euro locale on
this Debian box; what have they got against dashes?
Aidan Kehoe writes:
> 1. It doesn’t deal with the ＠modifier syntax in Unix locale specifications,
> which are structured like so:
To deal with the ＠modifier syntax you'll need to provide a hook. At
least in POSIX.1 the ＠modifier stuff was basically implementation
and/or site-specific. There are common ones, you can provide a
default implementation if you like.
> 2. It’s possible for me to start up in, for example, the directory
> "/tmp/aidan/за родину!" with a LC_CTYPE setting of en_US.UTF-8, and have
> XEmacs treat the current directory’s name as being encoded in UTF-8.
LC_CTYPE is a user preference on a multilingual system, but the file
system encoding is typically a site-wide parameter, sometimes enforced
by (some subsystem of) the OS. As I understand it, under Mac OS X
with HFS+ file names are UTF-8 with the maximally decomposed
canonicalization. Period. IIRC Japanese VFAT file systems are always
Shift JIS. If file-name-coding-system is reset to something else,
these systems will generate very confusing errors. On other systems
I've used, the file system is EUC-JP even though I used ja_JP.UTF8 or
en_US.ISO8859-1 for the default content encoding. Depending on what
I'm doing, it's often convenient to change locales. If XEmacs were to
pay attention to the locale for this parameter, hilarity (not to
mention annoyance) would ensue.
Hilarity ensues as-is. When I start up in "/tmp/aidan/за родину!" , I can’t
open the current directory, even though my init files set the file name
coding systems appropriately, and even when I have
XEMACSDEBUG="(define-coding-system-alias 'native 'utf-8)" in my
environment.
This should be handled by setting file-name-coding-system in the
site-start.el file, not by paying attention to user locale settings.
?!?! There should be code to work it out for each platform. In these days of
personal Linux distributions, and Mac OS X, the system administrator implied
in the site-start.el concept is becoming rarer and rarer.
> 2006-11-12 Aidan Kehoe <kehoea(a)parhasard.net>
>
> * mule/mule-cmds.el (get-language-environment-from-locale):
> If the Unix locale matches, and the language environment doesn't
> use the coding system specified in that locale, create a new one
> on the fly that does, and return that language environment.
> <== #### NOTE NOTE NOTE bogus trailing whitespace
I wish you'd not do this. Some of my private tools expect the regexp
"\n\n\d{4}-\d{2}-\d{2} " to match start-of-log-entry, and for
"\n\n"
to separate stanzas in a log entry.
Okay, noted.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
6381
days inactive
6382
days old
2 comments
2 participants
participants (2)
-
Aidan Kehoe -
Stephen J. Turnbull