[PATCH] Pay more attention to the the locale's coding systems on startup

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: 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. 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. 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