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 18:40:48 +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 1421516505 5982 80.91.229.3 (17 Jan 2015 17:41:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Jan 2015 17:41:45 +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 18:41:42 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 1YCXNV-0003DW-K8 for ged-emacs-devel@m.gmane.org; Sat, 17 Jan 2015 18:41:41 +0100 Original-Received: from localhost ([::1]:59874 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCXNT-0003gk-UB for ged-emacs-devel@m.gmane.org; Sat, 17 Jan 2015 12:41:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCXNG-0003gQ-BO for emacs-devel@gnu.org; Sat, 17 Jan 2015 12:41:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YCXNE-0005MZ-SD for emacs-devel@gnu.org; Sat, 17 Jan 2015 12:41:26 -0500 Original-Received: from mx1.bahnhof.se ([213.80.101.11]:40204) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCXN9-0005M5-3Q; Sat, 17 Jan 2015 12:41:19 -0500 Original-Received: from localhost (mf.bahnhof.se [213.80.101.20]) by mx1-reinject (Postfix) with ESMTP id 352E140D04; Sat, 17 Jan 2015 18:41:17 +0100 (CET) X-Virus-Scanned: by amavisd-new using ClamAV at bahnhof.se (MF3) Original-Received: from mf3.bahnhof.se ([127.0.0.1]) by localhost (mf3.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3f9uKa6ws4sB; Sat, 17 Jan 2015 18:41:11 +0100 (CET) Original-Received: from mta.verona.se (h-235-62.a149.priv.bahnhof.se [85.24.235.62]) by mf3.bahnhof.se (Postfix) with ESMTP id 914E73E8CC9; Sat, 17 Jan 2015 18:41:08 +0100 (CET) Original-Received: from localhost (unknown [127.0.0.1]) by mta.verona.se (Postfix) with ESMTP id 3FE93529C8A; Sat, 17 Jan 2015 17:41:08 +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 pUJ4RrOv7f85; Sat, 17 Jan 2015 18:40:48 +0100 (CET) Original-Received: from exodia.verona.se (www.verona.se [192.168.200.15]) by mta.verona.se (Postfix) with ESMTP id 81EC2529C89; Sat, 17 Jan 2015 18:40:48 +0100 (CET) In-Reply-To: (joakim@verona.se's message of "Sat, 17 Jan 2015 16:21:42 +0100") 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:181376 Archived-At: joakim@verona.se writes: > 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. Now I tried the same test, but with an image. It behaves the same way! So this would seem to indicate a number of possibilities: - My test is somewhow flawed. Perhaps (set (make-local-variable 'bidi-paragraph-direction) 'right-to-left) isnt supposed to affect images and xwidgets etc. - my xwidget code is so flawed that it affects the image code where it shouldnt. (the code paths are supposed to be separate though) - this is how its supposed to work, and everything is allright. > 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