Re: i18n search/replace with input methods latin-4-postfix and rfc1345

[B.T. Raven]

"Stefan Monnier" <monnier@iro.umontreal.ca> wrote in message
87ll8omz87.fsf-monnier+gnu.emacs.help@gnu.org">news:87ll8omz87.fsf-monnier+gnu.emacs.help@gnu.org...
> > (unify-8859-on-decoding-mode 1)
>
> Good.
>
> >  '(unify-8859-on-encoding-mode t nil (ucs-tables))
>
> Good as well.  Except that the two do the same thing redundantly, so
it's
> better to get rid of one of them.  I.e. if you like to configure your
system
> with Custom, then keep the second, else keep the first.

They shouldn't do the same thing since one is for decoding and the other
for encoding. Anyway I think I'll stick with Custom since it's probably
the less error prone method. Apparently unify on encoding is safe but
the other one can cause information loss.

>
> If this doesn't work for you, maybe it's a bug in Emacs-21.[34].
> Try it with Emacs-CVS where it *should* work,
>
>
>         Stefan

I am using the NT build and am not comfortable compiling from source. I
have cygwin running under MS win but have never tried to build anything
with gcc. In my case it might be wiser just to wait for the 21.4 (22.0?)
NT binaries. I would like to install the rfc1345 input method but that
probably requires a rebuild also. I put this in my leim-list.el:

;;(register-input-method
;; "rfc1345" "UTF-8" 'quail-use-package <- is this right activate
function???
;; "&utf<" "Utf-8 characters input method &prefix with postfix
modifiers"  <- is title to go in mode line arbitrary?
;; "quail/rfc1345")

but I don't dare to uncomment it because its dependencies seem to ramify
usque ad infinitum and I can't afford to break the functionality I have
now.  I haven't run into any  related files that aren't compiled lisp
functions, though. Does that mean that they are just *.elc or are some
of them built-ins written in C?

Again, thanks anyway.

Ed.