Re: Cant type unicode in emacs any more

[Rusi]

On Tuesday, April 29, 2014 6:14:45 PM UTC+5:30, Eric Abrahamsen wrote:
> Rusi  writes:

> > For some time now I have this in my X startup programs:
> > $ setxkbmap -option compose:menu
> > After this I can type (in mostly any window) for example:
> > (with MN being the windows-menu key)
> > MN.. gives ...  ie an ellipses
> > MN--. gives - ie an en dash
> > MN--- gives -- ie an em dash
> > Not to mention all the e" giving ë
> > etc etc - all the unicode goodies at
> > /usr/share/X11/locale/$LANG/Compose
> > Now suddenly its stopped working.
> > ie it works in most other X apps but not in emacs
> > I thought there may be a race-condition between the setxkb and emacs
> > which are both in my startup programs.
> > So I ran the setxkb command by hand from a shell and (re)started emacs
> > from the shell
> > No luck:
> > The compose works outside emacs
> > Doesn't work inside
> > Any clues?
> > Its the same for emacs 23 and 24

> Many of us have had to start emacs with the XMODIFIERS environment
> variable *unset* for quite some time, to make this work:

> /usr/bin/env -u XMODIFIERS /usr/bin/emacs

> If I recall correctly, the emacs developers have caught this and fixed
> it (?) in the development trunk, but I wouldn't be surprised if that
> hasn't made its way to any releases yet. Why you've only bumped into
> this recently I can't say, though again I have a feeling that one of the
> linux distros updated not too long ago in a way that exposed this bug.
> Anyhow, try unsetting the environment variable and see if that's it...

No that did not work

However Ive found what made it stop working:
I had created a .XCompose file containing the one line
<Multi_key> <less> <bar>        : "↵" U21B5

No I am not very addicted to the ↵ character -- just trying out how easy
it is to add one's own compose-sequences

Removing the .XCompose file makes it work again.

This of course raises more questions than it answers:
Minor: If its a bug/inconsistency then in whom
Significant: I thought X was one (or more) levels below emacs.
Why is emacs (effectively) looking into .XCompose?
Because currently the behavior I am seeing is:

- Other apps *add* contents of .XCompose to the builtin composeables
- Emacs *replaces* builtins with .XCompose