<Multi_key> is undefined

<Multi_key> is undefined

[David Kastrup]

After upgrading to Ubuntu 14.04 (and using Cinnamon), I can no longer
use <Multi_key>.  Emacs flashes at me and displays "<Multi_key> is
undefined".  This happened with a binary compiled before the upgrade,
and it also happens after I bootstrapped and built Emacs from a clean
directory right now.

The toolkit used is GTK3 (without toolkit scroll-bars, but I should be
surprised if that made a difference).

Any pointers?  Using input modes is quite less convenient than relying
on Multi_key for me.  What should I be testing?  What info might help
further pinpointing this?

I think it's important to get this fixed before the next release.  Many
programmers use an American keyboard layout rather than a local one
(because of characters like []{}|) and rely on Multi_key for their
non-English correspondence and text processing.

Now this is clearly related to upgrading the base system, but things
like the terminal window continue working with Multi_key just fine.

-- 
David Kastrup

Re: <Multi_key> is undefined

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> After upgrading to Ubuntu 14.04 (and using Cinnamon), I can no longer
> use <Multi_key>.  Emacs flashes at me and displays "<Multi_key> is
> undefined".

That means compose handling is broken on your system.  One workaround is
to remove ibus, so compose is properly handled again by the X server.

Nothing Emacs can do about.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: <Multi_key> is undefined

[David Kastrup]

Andreas Schwab <schwab@linux-m68k.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> After upgrading to Ubuntu 14.04 (and using Cinnamon), I can no longer
>> use <Multi_key>.  Emacs flashes at me and displays "<Multi_key> is
>> undefined".
>
> That means compose handling is broken on your system.

It's likely not just "my system" but in a month of time the most widely
deployed GNU/Linux system.

> One workaround is to remove ibus, so compose is properly handled again
> by the X server.
>
> Nothing Emacs can do about.

If this is nothing Emacs can do about, why is it working with
Gnome-terminal, Firefox, Gedit, the search box of Evince, even the GTK
file selector called from Emacs (when using the mouse in the File/Open
menu) and basically every other application on my system?

Can you name a single _other_ application rather than Emacs that should
have a non-working Multi_key if "compose handling [was] broken on my
system"?

If it is only Emacs showing that problem, shouldn't there be a
workaround even if you insist that Emacs is "correct" according to some
spec nobody else appears to be using?

-- 
David Kastrup

Re: <Multi_key> is undefined

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

On 03/23/2014 02:17 AM, David Kastrup wrote:
> Andreas Schwab <schwab@linux-m68k.org> writes:
> 
>> David Kastrup <dak@gnu.org> writes:
>>
>>> After upgrading to Ubuntu 14.04 (and using Cinnamon), I can no longer
>>> use <Multi_key>.  Emacs flashes at me and displays "<Multi_key> is
>>> undefined".
>>
>> That means compose handling is broken on your system.
> 
> It's likely not just "my system" but in a month of time the most widely
> deployed GNU/Linux system.

FWIW, it's broken on 13.10 for me too.  Nulling out XMODIFIERS fixes it
for me; that environment variable normally contains something about
ibus; making that change ourselves probably breaks other functionality
though.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: <Multi_key> is undefined

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> After upgrading to Ubuntu 14.04 (and using Cinnamon), I can no longer
>>> use <Multi_key>.  Emacs flashes at me and displays "<Multi_key> is
>>> undefined".
>>
>> That means compose handling is broken on your system.
>
> It's likely not just "my system" but in a month of time the most widely
> deployed GNU/Linux system.
>
>> One workaround is to remove ibus, so compose is properly handled again
>> by the X server.
>>
>> Nothing Emacs can do about.
>
> If this is nothing Emacs can do about, why is it working with
> Gnome-terminal, Firefox, Gedit, the search box of Evince, even the GTK
> file selector called from Emacs (when using the mouse in the File/Open
> menu) and basically every other application on my system?
>
> Can you name a single _other_ application rather than Emacs that should
> have a non-working Multi_key if "compose handling [was] broken on my
> system"?
>
> If it is only Emacs showing that problem, shouldn't there be a
> workaround even if you insist that Emacs is "correct" according to some
> spec nobody else appears to be using?

And even if we insist that all of this is "somebody else's problem", it
won't go away by itself if it is only visible with Emacs and we don't
bother getting to the bottom of it and reporting it to whoever else is
somebody else.

-- 
David Kastrup

Re: <Multi_key> is undefined

[David Kastrup]

Daniel Colascione <dancol@dancol.org> writes:

> On 03/23/2014 02:17 AM, David Kastrup wrote:
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>> 
>>> David Kastrup <dak@gnu.org> writes:
>>>
>>>> After upgrading to Ubuntu 14.04 (and using Cinnamon), I can no longer
>>>> use <Multi_key>.  Emacs flashes at me and displays "<Multi_key> is
>>>> undefined".
>>>
>>> That means compose handling is broken on your system.
>> 
>> It's likely not just "my system" but in a month of time the most widely
>> deployed GNU/Linux system.
>
> FWIW, it's broken on 13.10 for me too.

Interesting.  Possibly my use of Cinnamon put me behind the time.

> Nulling out XMODIFIERS fixes it for me; that environment variable
> normally contains something about ibus; making that change ourselves
> probably breaks other functionality though.

dak@lola:/usr/local/tmp/emacs-build$ echo $XMODIFIERS 
@im=ibus

Huh.

Starting Emacs from the command line, I get
emacs

** (emacs:14442): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-hJwGKKvPZH: Connection refused

There is nothing remotely like that file.  However, that seems to be a
red herring regarding _this_ problem since with

XMODIFIERS="" emacs

I get the same error message (including the same file name), but indeed
the compose character starts working.

-- 
David Kastrup

Re: <Multi_key> is undefined

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> It's likely not just "my system" but in a month of time the most widely
> deployed GNU/Linux system.

Any system using ibus (ie. not mine :-) ).

> Can you name a single _other_ application rather than Emacs that should
> have a non-working Multi_key if "compose handling [was] broken on my
> system"?

Anything Qt-based.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: <Multi_key> is undefined

[David Kastrup]

Andreas Schwab <schwab@linux-m68k.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> It's likely not just "my system" but in a month of time the most widely
>> deployed GNU/Linux system.
>
> Any system using ibus (ie. not mine :-) ).
>
>> Can you name a single _other_ application rather than Emacs that should
>> have a non-working Multi_key if "compose handling [was] broken on my
>> system"?
>
> Anything Qt-based.

Nope.  Bitcoin-Qt accepts multi_key just fine in its text input boxes.

-- 
David Kastrup

Re: <Multi_key> is undefined

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Nope.  Bitcoin-Qt accepts multi_key just fine in its text input boxes.

Does it use Qt for its input box?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: <Multi_key> is undefined

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

On 03/23/2014 02:56 AM, Andreas Schwab wrote:
> David Kastrup <dak@gnu.org> writes:
> 
>> Nope.  Bitcoin-Qt accepts multi_key just fine in its text input boxes.
> 
> Does it use Qt for its input box?

Works fine for me with qgit in a normal Qt input box. nedit breaks the
same way Emacs does, though.

I did a bit of debugging. xterm works fine; it's using
Xutf8LookupString/XmbLookupString, depending on wide character mode.
Emacs has code to call XmbLookupString, but it's not being run because
FRAME_XIC ends up being NULL. No idea why yet.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: <Multi_key> is undefined

[Werner LEMBERG]

 
> After upgrading to Ubuntu 14.04 (and using Cinnamon), I can no
> longer use <Multi_key>.  Emacs flashes at me and displays
> "<Multi_key> is undefined".  This happened with a binary compiled
> before the upgrade, and it also happens after I bootstrapped and
> built Emacs from a clean directory right now.  [...]

On my openSuSE KDE environment, I always start emacs as

  env XMODIFIERS="@im=none" emacs

and my .Xcompose file is honoured again in Emacs.


    Werner

Re: <Multi_key> is undefined

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

On 03/23/2014 03:08 AM, Daniel Colascione wrote:
> On 03/23/2014 02:56 AM, Andreas Schwab wrote:
>> David Kastrup <dak@gnu.org> writes:
>>
>>> Nope.  Bitcoin-Qt accepts multi_key just fine in its text input boxes.
>>
>> Does it use Qt for its input box?
> 
> Works fine for me with qgit in a normal Qt input box. nedit breaks the
> same way Emacs does, though.
> 
> I did a bit of debugging. xterm works fine; it's using
> Xutf8LookupString/XmbLookupString, depending on wide character mode.
> Emacs has code to call XmbLookupString, but it's not being run because
> FRAME_XIC ends up being NULL. No idea why yet.

Found it. Emacs' XCreateIC is failing because we pass an
XNStatusAttributes; omitting this parameter makes the compose system
work fine. Let me see whether omitting this parameter has any side
effects; if it doesn't, I'll check in a patch to retry XCreateIC without
XNStatusAttributes if the first call fails.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: <Multi_key> is undefined

[Eric Abrahamsen]

Daniel Colascione <dancol@dancol.org> writes:

> On 03/23/2014 02:17 AM, David Kastrup wrote:
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>> 
>>> David Kastrup <dak@gnu.org> writes:
>>>
>>>> After upgrading to Ubuntu 14.04 (and using Cinnamon), I can no longer
>>>> use <Multi_key>.  Emacs flashes at me and displays "<Multi_key> is
>>>> undefined".
>>>
>>> That means compose handling is broken on your system.
>> 
>> It's likely not just "my system" but in a month of time the most widely
>> deployed GNU/Linux system.
>
> FWIW, it's broken on 13.10 for me too.  Nulling out XMODIFIERS fixes it
> for me; that environment variable normally contains something about
> ibus; making that change ourselves probably breaks other functionality
> though.

I'm on arch linux, and have had to start emacs as "/usr/bin/env -u
XMODIFIERS emacs" for as long as I can remember.

Re: <Multi_key> is undefined

[Werner LEMBERG]

>> I did a bit of debugging. xterm works fine;

This surprises me.  I wasn't able yet to make xterm work with both
ibus and the `.Xcompose' file (alternatively, I mean).  As soon as
ibus is loaded (but deactivated), .Xcompose gets ignored, and some
hard-coded composing data gets used...  Maybe the ibus-xkb extension
helps, but I haven't tried it yet.

  https://github.com/fujiwarat/ibus-xkb


     Werner

Re: <Multi_key> is undefined

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

On 03/23/2014 03:16 AM, Daniel Colascione wrote:
> On 03/23/2014 03:08 AM, Daniel Colascione wrote:
>> On 03/23/2014 02:56 AM, Andreas Schwab wrote:
>>> David Kastrup <dak@gnu.org> writes:
>>>
>>>> Nope.  Bitcoin-Qt accepts multi_key just fine in its text input boxes.
>>>
>>> Does it use Qt for its input box?
>>
>> Works fine for me with qgit in a normal Qt input box. nedit breaks the
>> same way Emacs does, though.
>>
>> I did a bit of debugging. xterm works fine; it's using
>> Xutf8LookupString/XmbLookupString, depending on wide character mode.
>> Emacs has code to call XmbLookupString, but it's not being run because
>> FRAME_XIC ends up being NULL. No idea why yet.
> 
> Found it. Emacs' XCreateIC is failing because we pass an
> XNStatusAttributes; omitting this parameter makes the compose system
> work fine. Let me see whether omitting this parameter has any side
> effects; if it doesn't, I'll check in a patch to retry XCreateIC without
> XNStatusAttributes if the first call fails.

I pushed a fix to trunk. Can you please try it now? Compose works for me
without having to muck with XMODIFIERS.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: <Multi_key> is undefined

[Werner LEMBERG]

>> Found it. Emacs' XCreateIC is failing because we pass an
>> XNStatusAttributes; omitting this parameter makes the compose
>> system work fine. Let me see whether omitting this parameter has
>> any side effects; if it doesn't, I'll check in a patch to retry
>> XCreateIC without XNStatusAttributes if the first call fails.
> 
> I pushed a fix to trunk. Can you please try it now?  Compose works
> for me without having to muck with XMODIFIERS.

For me it fails.  My openSuSE 12.3 GNU/Linux box uses gtk+ 2.24.18 and
XOrg 1.13.2, in case this matters.


    Werner

Re: <Multi_key> is undefined

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

On 03/23/2014 04:37 AM, Werner LEMBERG wrote:
> 
>>> Found it. Emacs' XCreateIC is failing because we pass an
>>> XNStatusAttributes; omitting this parameter makes the compose
>>> system work fine. Let me see whether omitting this parameter has
>>> any side effects; if it doesn't, I'll check in a patch to retry
>>> XCreateIC without XNStatusAttributes if the first call fails.
>>
>> I pushed a fix to trunk. Can you please try it now?  Compose works
>> for me without having to muck with XMODIFIERS.
> 
> For me it fails.  My openSuSE 12.3 GNU/Linux box uses gtk+ 2.24.18 and
> XOrg 1.13.2, in case this matters.

Break on XCreateIC. Does it return NULL?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: <Multi_key> is undefined

[Werner LEMBERG]

> Break on XCreateIC. Does it return NULL?

  (gdb) b XCreateIC
  Breakpoint 1 at 0x8057f80
  (gdb) r
  Starting program: /usr/local/home/wl/bzr/emacs.compiled/src/emacs -Q
  Breakpoint 1, 0xb72bb260 in XCreateIC () from /usr/lib/libX11.so.6
  (gdb) fin
  Run till exit from #0  0xb72bb260 in XCreateIC () from /usr/lib/libX11.so.6
  0x081085c7 in create_frame_xic (f=f@entry=0x86de480) at xfns.c:2037
  2037              xic = XCreateIC (xim,
  (gdb) p xic
  $1 = (struct _XIC *) 0x853d630

Obviously no.


    Werner

Re: <Multi_key> is undefined

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

On 03/23/2014 04:44 AM, Werner LEMBERG wrote:
> 
>> Break on XCreateIC. Does it return NULL?
> 
>   (gdb) b XCreateIC
>   Breakpoint 1 at 0x8057f80
>   (gdb) r
>   Starting program: /usr/local/home/wl/bzr/emacs.compiled/src/emacs -Q
>   Breakpoint 1, 0xb72bb260 in XCreateIC () from /usr/lib/libX11.so.6
>   (gdb) fin
>   Run till exit from #0  0xb72bb260 in XCreateIC () from /usr/lib/libX11.so.6
>   0x081085c7 in create_frame_xic (f=f@entry=0x86de480) at xfns.c:2037
>   2037              xic = XCreateIC (xim,
>   (gdb) p xic
>   $1 = (struct _XIC *) 0x853d630
> 
> Obviously no.

Hrm. And Emacs gets around to calling XmbLookupString?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: <Multi_key> is undefined

[Werner LEMBERG]

> Hrm. And Emacs gets around to calling XmbLookupString?

Yes.  While pressing the compose key, the breakpoint gets triggered:

  (gdb) b XmbLookupString
  Breakpoint 1 at 0x8057620
  (gdb) r
  Breakpoint 1, 0xb72bb530 in XmbLookupString () from /usr/lib/libX11.so.6
  (gdb) fin
  Run till exit from #0  0xb72bb530 in XmbLookupString () from /usr/lib/libX11.so.6
  handle_one_xevent (dpyinfo=0xffffffa0, dpyinfo@entry=0x84de470,
                     event=event@entry=0xbfffdf1c, finish=0xbfffd940,
                     finish@entry=0x842bcbc <current_finish>,
                     hold_quit=0xbfffe12c) at xterm.c:6242
  6242              unsigned char *copy_bufptr = copy_buffer;


    Werner

Re: <Multi_key> is undefined

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 495 bytes --]

On 03/23/2014 04:57 AM, Werner LEMBERG wrote:
> 
>> Hrm. And Emacs gets around to calling XmbLookupString?
> 
> Yes.  While pressing the compose key, the breakpoint gets triggered:

It looks like that version of OpenSUSE comes with ibus 1.4.3 [1]. I'm
running 1.5.3; according to [2], the ibus changes something in 1.5 that
made compose work.

[1] http://en.opensuse.org/Archive:Package_list_12.3

[2]
http://lists.alioth.debian.org/pipermail/pkg-ime-devel/2013-June/003073.html


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: <Multi_key> is undefined

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

David Kastrup [2014-03-23 09:33:09 +01:00] wrote:

> After upgrading to Ubuntu 14.04 (and using Cinnamon), I can no longer
> use <Multi_key>.

I've been setting the following variables about forever:

    export XMODIFIERS=@im=none
    export GTK_IM_MODULE=xim
    export QT_IM_MODULE=xim

I'm using Debian GNU/Linux 7.4 and i3 window manager, so the problem you
are seeing probably doesn't appear here. However, I do believe that
those variables solve your problem too.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: <Multi_key> is undefined

[David Kastrup]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Daniel Colascione <dancol@dancol.org> writes:
>
>> On 03/23/2014 02:17 AM, David Kastrup wrote:
>>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>> 
>>>> David Kastrup <dak@gnu.org> writes:
>>>>
>>>>> After upgrading to Ubuntu 14.04 (and using Cinnamon), I can no longer
>>>>> use <Multi_key>.  Emacs flashes at me and displays "<Multi_key> is
>>>>> undefined".
>>>>
>>>> That means compose handling is broken on your system.
>>> 
>>> It's likely not just "my system" but in a month of time the most widely
>>> deployed GNU/Linux system.
>>
>> FWIW, it's broken on 13.10 for me too.  Nulling out XMODIFIERS fixes it
>> for me; that environment variable normally contains something about
>> ibus; making that change ourselves probably breaks other functionality
>> though.
>
> I'm on arch linux, and have had to start emacs as "/usr/bin/env -u
> XMODIFIERS emacs" for as long as I can remember.

We are not exactly going to attain world domination of Emacs when
everybody keeps his necessary fixes private.

Recompiling right now.

-- 
David Kastrup

Re: <Multi_key> is undefined

[David Kastrup]

Daniel Colascione <dancol@dancol.org> writes:

> On 03/23/2014 03:16 AM, Daniel Colascione wrote:
>> On 03/23/2014 03:08 AM, Daniel Colascione wrote:
>>> On 03/23/2014 02:56 AM, Andreas Schwab wrote:
>>>> David Kastrup <dak@gnu.org> writes:
>>>>
>>>>> Nope.  Bitcoin-Qt accepts multi_key just fine in its text input boxes.
>>>>
>>>> Does it use Qt for its input box?
>>>
>>> Works fine for me with qgit in a normal Qt input box. nedit breaks the
>>> same way Emacs does, though.
>>>
>>> I did a bit of debugging. xterm works fine; it's using
>>> Xutf8LookupString/XmbLookupString, depending on wide character mode.
>>> Emacs has code to call XmbLookupString, but it's not being run because
>>> FRAME_XIC ends up being NULL. No idea why yet.
>> 
>> Found it. Emacs' XCreateIC is failing because we pass an
>> XNStatusAttributes; omitting this parameter makes the compose system
>> work fine. Let me see whether omitting this parameter has any side
>> effects; if it doesn't, I'll check in a patch to retry XCreateIC without
>> XNStatusAttributes if the first call fails.
>
> I pushed a fix to trunk. Can you please try it now? Compose works for me
> without having to muck with XMODIFIERS.

There is a short bug fix branch merged into trunk twice (first merge
integrating two commits, second merge integrating another two).  For me,
the Compose key problem is already fixed with the first of those merge
commits.  I have verified that the problem is still present immediately
before the first merge commit.

Thanks!

-- 
David Kastrup

Re: <Multi_key> is undefined

[Barry Fishman]

On 2014-03-23 06:16:08 EDT, Werner LEMBERG wrote:
>  
>> After upgrading to Ubuntu 14.04 (and using Cinnamon), I can no
>> longer use <Multi_key>.  Emacs flashes at me and displays
>> "<Multi_key> is undefined".  This happened with a binary compiled
>> before the upgrade, and it also happens after I bootstrapped and
>> built Emacs from a clean directory right now.  [...]
>
> On my openSuSE KDE environment, I always start emacs as
>
>   env XMODIFIERS="@im=none" emacs
>
> and my .Xcompose file is honoured again in Emacs.

The other approach is to define the Multi_key mappings you want inside
of Emacs.

(define-key global-map [(Multi_key) (s) (s)] (lambda ()
					       (interactive)
					       (insert 223)))
--
Barry Fishman

Re: <Multi_key> is undefined

[Barry Fishman]

On 2014-03-23 08:10:11 EDT, Daniel Colascione wrote:
> On 03/23/2014 04:57 AM, Werner LEMBERG wrote:
>> 
>>> Hrm. And Emacs gets around to calling XmbLookupString?
>> 
>> Yes.  While pressing the compose key, the breakpoint gets triggered:
>
> It looks like that version of OpenSUSE comes with ibus 1.4.3 [1]. I'm
> running 1.5.3; according to [2], the ibus changes something in 1.5 that
> made compose work.
>
> [1] http://en.opensuse.org/Archive:Package_list_12.3
>
> [2]
> http://lists.alioth.debian.org/pipermail/pkg-ime-devel/2013-June/003073.html

Wouldn't it be better to just add Multi_key bindings to Emacs.  This
will also give control of these bindings to the end user (when possible)
to extend and modify as they wish.

--
Barry Fishman

Re: <Multi_key> is undefined

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

On 03/23/2014 07:33 AM, Barry Fishman wrote:
> 
> On 2014-03-23 08:10:11 EDT, Daniel Colascione wrote:
>> On 03/23/2014 04:57 AM, Werner LEMBERG wrote:
>>>
>>>> Hrm. And Emacs gets around to calling XmbLookupString?
>>>
>>> Yes.  While pressing the compose key, the breakpoint gets triggered:
>>
>> It looks like that version of OpenSUSE comes with ibus 1.4.3 [1]. I'm
>> running 1.5.3; according to [2], the ibus changes something in 1.5 that
>> made compose work.
>>
>> [1] http://en.opensuse.org/Archive:Package_list_12.3
>>
>> [2]
>> http://lists.alioth.debian.org/pipermail/pkg-ime-devel/2013-June/003073.html
> 
> Wouldn't it be better to just add Multi_key bindings to Emacs.  This
> will also give control of these bindings to the end user (when possible)
> to extend and modify as they wish.

Emacs is not, despite appearances, an operating system. We shouldn't
reinvent every wheel. Centralizing input method infrastructure is very
useful because it provides consistency across an entire environment.

If you want a pure-Emacs implementation of the compose concept, you can
load iso-transl and either use C-x 8 or bind Multi_key to
iso-transl-ctl-x-8-map. It's no substitute for proper IME integration.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: <Multi_key> is undefined

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sun, 23 Mar 2014 10:29:12 +0100
> Cc: Andreas Schwab <schwab@linux-m68k.org>, emacs-devel@gnu.org
> 
> > Nulling out XMODIFIERS fixes it for me; that environment variable
> > normally contains something about ibus; making that change ourselves
> > probably breaks other functionality though.
> 
> dak@lola:/usr/local/tmp/emacs-build$ echo $XMODIFIERS 
> @im=ibus
> 
> Huh.
> 
> Starting Emacs from the command line, I get
> emacs
> 
> ** (emacs:14442): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-hJwGKKvPZH: Connection refused
> 
> There is nothing remotely like that file.  However, that seems to be a
> red herring regarding _this_ problem since with
> 
> XMODIFIERS="" emacs
> 
> I get the same error message (including the same file name), but indeed
> the compose character starts working.

I suggest to add this (and other) solutions to etc/PROBLEMS.

Re: <Multi_key> is undefined

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Sun, 23 Mar 2014 10:29:12 +0100
>> Cc: Andreas Schwab <schwab@linux-m68k.org>, emacs-devel@gnu.org
>> 
>> > Nulling out XMODIFIERS fixes it for me; that environment variable
>> > normally contains something about ibus; making that change ourselves
>> > probably breaks other functionality though.
>> 
>> dak@lola:/usr/local/tmp/emacs-build$ echo $XMODIFIERS 
>> @im=ibus
>> 
>> Huh.
>> 
>> Starting Emacs from the command line, I get
>> emacs
>> 
>> ** (emacs:14442): WARNING **: Couldn't connect to accessibility bus:
>> Failed to connect to socket /tmp/dbus-hJwGKKvPZH: Connection refused
>> 
>> There is nothing remotely like that file.  However, that seems to be a
>> red herring regarding _this_ problem since with
>> 
>> XMODIFIERS="" emacs
>> 
>> I get the same error message (including the same file name), but indeed
>> the compose character starts working.
>
> I suggest to add this (and other) solutions to etc/PROBLEMS.

From my point of view, it would currently make more sense cherry-picking
the fixes of Daniel to the release branch unless we get reports that
they don't do the trick in cases where nulling XMODIFIERS does.

-- 
David Kastrup

Re: <Multi_key> is undefined

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: dancol@dancol.org,  schwab@linux-m68k.org,  emacs-devel@gnu.org
> Date: Sun, 23 Mar 2014 17:22:19 +0100
> 
> > I suggest to add this (and other) solutions to etc/PROBLEMS.
> 
> >From my point of view, it would currently make more sense cherry-picking
> the fixes of Daniel to the release branch unless we get reports that
> they don't do the trick in cases where nulling XMODIFIERS does.

Maybe I'm confused, but didn't Werner already provide such a report?

Re: <Multi_key> is undefined

[Werner LEMBERG]

>> I suggest to add this (and other) solutions to etc/PROBLEMS.
>
> From my point of view, it would currently make more sense
> cherry-picking the fixes of Daniel to the release branch unless we
> get reports that they don't do the trick in cases where nulling
> XMODIFIERS does.

Probably both, since older ibus versions still need the XMODIFIERS
trick, as Daniel has mentioned in another e-mail.


    Werner

Re: <Multi_key> is undefined

[David Kastrup]

Werner LEMBERG <wl@gnu.org> writes:

>>> I suggest to add this (and other) solutions to etc/PROBLEMS.
>>
>> From my point of view, it would currently make more sense
>> cherry-picking the fixes of Daniel to the release branch unless we
>> get reports that they don't do the trick in cases where nulling
>> XMODIFIERS does.
>
> Probably both, since older ibus versions still need the XMODIFIERS
> trick, as Daniel has mentioned in another e-mail.

Anybody have an idea why I never encountered this particular problem
before in my history of using Ubuntu (though avoiding Unity)?  While
I do remember various problems with Multi_key, I think the last time
must be at least something like 6 years ago.  So either they adopted
ibus only recently, or they had some other workarounds in place?  Since
I only got this problem after updating to 14.04 (probably the report for
13.10 is for using Unity?), this is sort of puzzling.

-- 
David Kastrup

Re: <Multi_key> is undefined

[Barry Fishman]

On 2014-03-23 10:46:32 EDT, Daniel Colascione wrote:
> On 03/23/2014 07:33 AM, Barry Fishman wrote:
>> Wouldn't it be better to just add Multi_key bindings to Emacs.  This
>> will also give control of these bindings to the end user (when possible)
>> to extend and modify as they wish.
>
> Emacs is not, despite appearances, an operating system. We shouldn't
> reinvent every wheel. Centralizing input method infrastructure is very
> useful because it provides consistency across an entire environment.

But that environment does not work.  If the choice is to figure out how to
modify your environment variables before entering Emacs, or have Emacs
just work, I choose the latter.  Either way it is a gross hack.

> If you want a pure-Emacs implementation of the compose concept, you can
> load iso-transl and either use C-x 8 or bind Multi_key to
> iso-transl-ctl-x-8-map.

I use "C-x 8" and "C-\".

Re: <Multi_key> is undefined

[Stephen J. Turnbull]

Barry Fishman writes:

 > But that environment does not work.

True, for the moment.

 > If the choice is to figure out how to modify your environment
 > variables before entering Emacs, or have Emacs just work, I choose
 > the latter.

Unfortunately, that is not the choice.  We have no choice but to
prepare to defend ourselves for some time: we are under attack by the
slings and arrows of outrageous IM developers.

For reasons I don't understand, the Linux[1], X11, and generic-IM
communities have chosen to repeatedly change keyboard handling in
backward-incompatible ways.  From what I hear from Ubuntu users, at
least generic-IM still doesn't have it right.  So we may suffer
another such attack in the not so distant future (due to what Jamie
calls the "CADT syndrome" <URL:http://www.jwz.org/doc/cadt.html>).

 > Either way it is a gross hack.

Precisely.  If you have an up-to-date environment, a patched Emacs
will work without the hack.  This *should* remain true indefinitely,
modulo the aforementioned slings and arrows.  There's no guarantee
with the hack, and the hack *will* break something else for some
people.

Footnotes: 
[1]  If you're Gibozing, Richard, indeed I do mean the kernel
development community.