"Stefan Monnier" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > 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. _______________________________________________ Help-gnu-emacs mailing list Help-gnu-emacs@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
