From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: is undefined Date: Sun, 23 Mar 2014 14:44:14 +0100 Organization: Organization?!? Message-ID: <874n2pyqq9.fsf@fencepost.gnu.org> References: <8761n5z54q.fsf@fencepost.gnu.org> <87y501xoj1.fsf@fencepost.gnu.org> <87zjkhjl7c.fsf@fencepost.gnu.org> <532EB28C.9020303@dancol.org> <532EB484.9060707@dancol.org> <532EB6AE.8050803@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1395582272 15502 80.91.229.3 (23 Mar 2014 13:44:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Mar 2014 13:44:32 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 23 14:44:41 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WRihc-0000yH-Q5 for ged-emacs-devel@m.gmane.org; Sun, 23 Mar 2014 14:44:40 +0100 Original-Received: from localhost ([::1]:60206 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRihc-0002oP-FG for ged-emacs-devel@m.gmane.org; Sun, 23 Mar 2014 09:44:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43163) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRihU-0002o5-D9 for emacs-devel@gnu.org; Sun, 23 Mar 2014 09:44:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WRihP-0005SE-0C for emacs-devel@gnu.org; Sun, 23 Mar 2014 09:44:32 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:52235) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRihO-0005S2-Pw for emacs-devel@gnu.org; Sun, 23 Mar 2014 09:44:26 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WRihM-0000kB-Ka for emacs-devel@gnu.org; Sun, 23 Mar 2014 14:44:24 +0100 Original-Received: from x2f422c0.dyn.telefonica.de ([2.244.34.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Mar 2014 14:44:24 +0100 Original-Received: from dak by x2f422c0.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Mar 2014 14:44:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 38 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f422c0.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) Cancel-Lock: sha1:yZepyxfKPmGa84S+WrSJmSaagcc= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:170860 Archived-At: Daniel Colascione 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 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