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

[B.T. Raven]

"Stefan Monnier" <monnier@iro.umontreal.ca> wrote in message
87sm2viir2.fsf-monnier+gnu.emacs.help@gnu.org">news:87sm2viir2.fsf-monnier+gnu.emacs.help@gnu.org...
> > Thanks again, monsieur Monnier. I posted a note about my problem to
> > gnu.emacs.bug.
>
> I doubt you'll get much help this way: there have been various changes
in
> the way unify-on-decoding works, but I don't think anyone knows of
> a particular change that would explain your problem.  Maybe your
problem is
> actually unrelated, or not fixed in Emacs-CVS.  Unify on decoding does
work,
> but the details matter (e.g. does unification take place only when
reading
> files or also when inputting chars via quail.  What about when
inputting
> chars via XIM, ...).
>
> Now that I think about it, I don't know why I didn't think of telling
you to
> try one of the precompiled NTEmacs binaries that wander around on the
net.
> I don't know where to find them, but I know they exist.
>
>
>         Stefan

That is in fact what I use. It's from headquarters at:

http://ftp.gnu.org/gnu/windows/emacs/

It looks like what C-x = reports is not the code-point (e.g. U+0100) but
some transformation or offset from that. Now that I've made .emacs a
utf-8 file instead of an emacs-mule one, even the freshly input
characters (via Latin-4-postfix) now show yet another byte value. I
guess this could be anywhere from 2 to 4 bytes long.
Do you, Stefan, or does anyone out there have any idea when the 21.4
Windows binaries will be inserted into the ftp tree at the above cited
URL?

Ed.