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

[joakim]

address@hidden writes:

> Eli Zaretskii <address@hidden> writes:
>
>>> From: address@hidden
>>> Cc: address@hidden,  address@hidden
>>> 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 <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