Re: <Multi_key> is undefined

[David Kastrup]

Daniel Colascione <address@hidden> 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 <address@hidden> 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