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

[joakim@verona.se]

Eli Zaretskii <eliz@gnu.org> 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 <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.

-- 
Joakim Verona