From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] xwidget updated (1d8b8a2 -> 5f46725) Date: Sat, 17 Jan 2015 12:19:28 +0200 Message-ID: <83wq4lzp3j.fsf@gnu.org> References: <20141226164113.11620.38682@vcs.savannah.gnu.org> <831tnjlpts.fsf@gnu.org> <83k31ajvdz.fsf@gnu.org> <83wq4v4rr9.fsf@gnu.org> <838uh21ly4.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1421489992 4705 80.91.229.3 (17 Jan 2015 10:19:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Jan 2015 10:19:52 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 17 11:19:52 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 1YCQTv-0008T3-LB for ged-emacs-devel@m.gmane.org; Sat, 17 Jan 2015 11:19:51 +0100 Original-Received: from localhost ([::1]:58772 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCQTu-0004ko-UV for ged-emacs-devel@m.gmane.org; Sat, 17 Jan 2015 05:19:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59613) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCQTN-0004Nf-1Y for emacs-devel@gnu.org; Sat, 17 Jan 2015 05:19:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YCQTJ-0002dV-S0 for emacs-devel@gnu.org; Sat, 17 Jan 2015 05:19:16 -0500 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:60821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCQTJ-0002dM-D7 for emacs-devel@gnu.org; Sat, 17 Jan 2015 05:19:13 -0500 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NIB00800G2EUV00@mtaout27.012.net.il> for emacs-devel@gnu.org; Sat, 17 Jan 2015 12:11:47 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NIB002VQGBN2Z60@mtaout27.012.net.il>; Sat, 17 Jan 2015 12:11:47 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.183 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:181370 Archived-At: > 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? 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.