Aidan Kehoe <kehoea(a)parhasard.net> writes:
This version of the patch doesnât load latin-unity or Mule-UCS. In
the event of some utf-8 coding system not being available, it still
falls back to iso-2022-jp. I think this is reasonable, if not ideal;
It's certainly reasonable in the current Mule, which can be assumed to
always support ISO 2022. Thanks for working on this.
It's a shame that loading latin-unity without calling
`latin-unity-install' silently changes behavior of this code. After
all, it could be loaded by a simple `require' placed to shut up
byte-compiler warnings in an unrelated package. I believe it is
generally agreed that loading a package should not change the
user-visible behavior of a running XEmacs. Maybe, in addition to
`featurep', you should be checking if latin-unity is actually
"installed"? For example:
(if (and (featurep 'latin-unity)
;; It would be nice if latin-unity provided a better way to
;; check whether it's installed by the user.
(assq 'latin-unity-sanity-check
(default-value 'write-region-pre-hook)))
... the user loaded and installed latin-unity; use it ...
... don't use latin-unity ...
(The above is not a veto, just a remark. If you don't consider it
appropriate to check for latin-unity's installation in this case, I
respect your judgment.)
An unrelated note on style: it's slightly better to use mapc in
preference to mapcar when you don't need to collect the return values
of the mapper function. dolist is an even better candidate for
iteration over simple lists.