Re: [Emacs-diffs] xwidget updated (1d8b8a2 -> 5f46725)

[Eli Zaretskii <eliz@gnu.org>]

> 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 <dumped_data+2497336>, 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.