<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.

<Multi_key> is undefined

[jonetsu]

Hello,

The use case is being able to type pinyin characters.  The actual
pinyin characters, whit the punctuation marks.  Two of them are
easy to have using a German keyboard.  The two others are
accessible using the so-called 'compose key'.

Using Linux Mint 17 (Ubuntu based), KDE's System Settings are
used to assign the compose key to Scroll Lock.  Using this to
write 'ă' in kconsole terminal works fine.  It also works well in
the Claws-mail email client, as well as firefox.

But not in emacs 24.4.1 (and previous versions for that matter)
where the following is displayed as soon as the Scroll Lock
compose key is pressed:

<Multi_key> is undefined

How can this be made to work in emacs ?  This would be very practical.

Thanks.

Re: <Multi_key> is undefined

[Emanuel Berg]

jonetsu <jonetsu@teksavvy.com> writes:

> The use case is being able to type pinyin
> characters.  The actual pinyin characters, whit the
> punctuation marks.  Two of them are easy to have
> using a German keyboard.  The two others are
> accessible using the so-called 'compose key'.
>
> Using Linux Mint 17 (Ubuntu based), KDE's System
> Settings are used to assign the compose key to
> Scroll Lock.  Using this to write 'ă' in kconsole
> terminal works fine.  It also works well in the
> Claws-mail email client, as well as firefox.
>
> But not in emacs 24.4.1 (and previous versions for
> that matter) where the following is displayed as
> soon as the Scroll Lock compose key is pressed:
>
> <Multi_key> is undefined

We had this question or a version of it not long ago -
see if you can grep the web for gnu.emacs.help and
'<Multi_key> is undefined', then follow the white
rabbit from there.

FTR, I have the compose key up and running and
configurable both in the Linux VTs and in X, including
Emacs both cases, but I don't use the Scroll Lock key
for this (thanks heaven) so I can't help you with
details, but it should definitely be possible, so
keep digging!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: <Multi_key> is undefined

[Stefan Monnier]

> OK, found the thread.  Will go through it...  Any short 
> answer that will not disable ibus which I also use ?

All I can say is that any answer which involves mentioning Multi_key in
the .emacs file is fundamentally wrong (it might provide a crutch, tho,
of course).


        Stefan

Re: <Multi_key> is undefined

[Eric Abrahamsen]

jonetsu <jonetsu@teksavvy.com> writes:

>> From: Rusi <rustompmody@gmail.com> 
>> Date: 04/08/15 23:00 
>> Subject: Re: Re[2]: <Multi_key> is undefined 
>   
>> 1. Try starting emacs with unset XMODIFIERS and see if the problem goes away
>
> I have tried:
>
> XMODIFIERS="" emacs
>
> and:
>
> /usr/bin/env -u XMODIFIERS emacs 
>
> And both of them get rid of the '<Multi_key> is undefined' emacs
> message, but that's it.  The letter with the accent, as it appears at
> the (k)console, firefox, sylpheed-claws client, etc... is not shown in
> emacs.
>
>> 2. Why/what do you use ibus for?
>
> Chinese.  Well, I try, as it seems to be quite broken in Linux Mint
> 17.  Either it is broken, or the OS input method has seen some
> changes.  emacs does have a Chinese input mode these days although it
> is really not nice to use.  I'm used to ibus and emacs and have
> written a lot of text easily that way, on a previous OS (Linux Mint
> 14, which I still boot when I have specifically Chinese text to
> write).  Now I would like to use a more recent OS, and add actual
> pinyin notation alongside Chinese hanzi.

I can't help with the compose key problem, as unsetting XMODIFIERS does
work for me, but I found ibus eventually unusable in Emacs. I've
switched to fcitx for system input, which works okay, but it doesn't
work in Emacs either! The Emacs package manager has an input method
called chinese-pyim which I'm finding quite good -- it takes a bit to
train, but after that it's very nice to use. Or do as I'm trying to do,
and learn the Wubi input method...

Sorry, no actual solution to your problem, but some alternatives...

Eric

Re: <Multi_key> is undefined

[Stefan Monnier]

> I would say if half a dozen random apps respect an input method and emacs
> doesn't, thats probably worth a bug-report.

Violent agreement.  FWIW, this looks similar to
http://debbugs.gnu.org/17928, which was supposedly fixed in 24.4, so if
your Emacs is older, try a more recent version, and if it's newer, then
try to hysterically hit M-x report-emacs-bug and then calmly fill the
report with as many details as you can.


        Stefan