From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] xwidget updated (1d8b8a2 -> 5f46725) Date: Sat, 17 Jan 2015 16:21:42 +0100 Message-ID: References: <20141226164113.11620.38682@vcs.savannah.gnu.org> <831tnjlpts.fsf@gnu.org> <83k31ajvdz.fsf@gnu.org> <83wq4v4rr9.fsf@gnu.org> <838uh21ly4.fsf@gnu.org> <83wq4lzp3j.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1421508147 24550 80.91.229.3 (17 Jan 2015 15:22:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Jan 2015 15:22:27 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 17 16:22:26 2015 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 1YCVCj-0003BW-Q9 for ged-emacs-devel@m.gmane.org; Sat, 17 Jan 2015 16:22:26 +0100 Original-Received: from localhost ([::1]:59474 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCVCj-0000tS-0Q for ged-emacs-devel@m.gmane.org; Sat, 17 Jan 2015 10:22:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43873) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCVCf-0000sv-BS for emacs-devel@gnu.org; Sat, 17 Jan 2015 10:22:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YCVCe-0004zb-5R for emacs-devel@gnu.org; Sat, 17 Jan 2015 10:22:21 -0500 Original-Received: from mx1.bahnhof.se ([213.80.101.11]:38469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCVCU-0004y1-6e; Sat, 17 Jan 2015 10:22:10 -0500 Original-Received: from localhost (mf.bahnhof.se [213.80.101.20]) by mx1-reinject (Postfix) with ESMTP id C411F40C9B; Sat, 17 Jan 2015 16:22:08 +0100 (CET) X-Virus-Scanned: by amavisd-new using ClamAV at bahnhof.se (MF1) Original-Received: from mf1.bahnhof.se ([127.0.0.1]) by localhost (mf1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAKl-XckDpxG; Sat, 17 Jan 2015 16:22:03 +0100 (CET) Original-Received: from mta.verona.se (h-235-62.a149.priv.bahnhof.se [85.24.235.62]) by mf1.bahnhof.se (Postfix) with ESMTP id 99B0B330AF6; Sat, 17 Jan 2015 16:22:02 +0100 (CET) Original-Received: from localhost (unknown [127.0.0.1]) by mta.verona.se (Postfix) with ESMTP id 3389A529C6A; Sat, 17 Jan 2015 15:22:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at verona.se Original-Received: from mta.verona.se ([127.0.0.1]) by localhost (exodia.verona.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjqL9Cgi85_5; Sat, 17 Jan 2015 16:21:42 +0100 (CET) Original-Received: from exodia.verona.se (www.verona.se [192.168.200.15]) by mta.verona.se (Postfix) with ESMTP id 74B2D529C65; Sat, 17 Jan 2015 16:21:42 +0100 (CET) In-Reply-To: <83wq4lzp3j.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 17 Jan 2015 12:19:28 +0200") User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 213.80.101.11 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:181375 Archived-At: Eli Zaretskii writes: >> From: joakim@verona.se >> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org >> Date: Fri, 16 Jan 2015 22:16:57 +0100 >> >> Here in the L2R case, I insert a button in the middle of the text. If I >> type more text, the buttone moves along with the text towards the right >> edge. This is the expected behaviour. >> (xwidget-demo "a-button" >> (xwidget-insert (+ 15 (point-min)) 'Button "button" 60 50) >> (define-key (current-local-map) [xwidget-event] 'xwidget-handler-demo-basic)) >> >> In the next case the button is also in the middle of the text at >> first. However, when the direction is changed to right-to-left, the text >> sticks to the right edge as expected, but the button jumps to the edge >> rather than staying within the text. If I type some text, the text move >> right to left, but the button just stays there at the right edge. > > That's indeed a sign of some problem. The code that places the widget > on the screen on the Xlib level is something specific to your changes, > am I right? I believe that's where the problem is: somehow that code > doesn't work correctly in right-to-left display lines (a.k.a. "glyph > rows"). Can you show the code which computes the coordinates where to > place the widget? The code is supposed to work like it does for images. The display engine calculates coordinates. Then the xwidget code further tweaks the coordinates, and place the gtk components on-screen. AFAICS in this particular case the (xwidget modified) display engine isnt calculating the coordinates properly, because text is flowing around the gtk button. It is not being placed above text. I think the xwidget code is basically older than the merge of bidi to trunk, and I never did the modifications necessary for bidi, and I think I'm missing some important bidi bits. Anyway, I will try your method below and see if I can figure something out. > To make sure this code is indeed the problem, I suggest to look at the > glyph row generated by the device-independent part of the display > engine, and make sure the glyph row is correct. Here's how: > > $ cd src > $ gdb ./emacs > (gdb) break Fredraw_display > (gdb) r -Q > > Now recreate the problem with button display in R2L line, make sure > the cursor is in that line, and type "M-x redraw-display RET". This > will cause GDB to kick in. Then do: > > (gdb) break set_cursor_from_row > (gdb) continue > > Usually, the first time the breakpoint in set_cursor_from_row is hit, > it's because Emacs redisplays the echo area, which is not where we > want to look. Type "bt" to see if that's the case: if it is, you > should see display_echo_area in the backtrace, in which case type > "continue" and wait for the next time the breakpoint breaks. This > time, "bt" should show something like this: > > 14252 struct glyph *glyph = row->glyphs[TEXT_AREA]; > (gdb) bt 10 > #0 set_cursor_from_row (w=0x17e4918 , row=0xfc46e8, > matrix=0xfbd418, delta=0, delta_bytes=0, dy=0, dvpos=0) at xdisp.c:14252 > #1 0x010663b0 in display_line (it=0x82beb0) at xdisp.c:20828 > #2 0x0105720f in try_window (window=25053469, pos=..., flags=1) > at xdisp.c:16928 > #3 0x01053f90 in redisplay_window (window=25053469, just_this_one_p=false) > at xdisp.c:16401 > #4 0x0104c567 in redisplay_window_0 (window=25053469) at xdisp.c:14226 > > Now issue this command: > > (gdb) pgrow > > and post the full output. > > The command "pgrow" is defined by src/.gdbinit. Latest versions of > GDB will refuse to read that file unless you tell GDB that it's "safe" > to read it. If you didn't make such an arrangement, the easiest thing > to do is simply read the file manually: > > (gdb) source .gdbinit > > You'll have to do that in case GDB says "pgrow" is not a known > command. > > Finally, it could be that "pgrow" doesn't yet know how to display the > xwidget glyph, in which case you will have to modify the pgx function > in .gdbinit to do that. -- Joakim Verona