emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changes in frame/window code


From: Eli Zaretskii
Subject: Re: Changes in frame/window code
Date: Mon, 18 Aug 2014 18:00:56 +0300

> Date: Mon, 18 Aug 2014 10:31:38 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden
> 
>  >> (1) When dragging I cannot move the slider entirely to the right and
>  >>       make the first column of R2L lines visible until I release the mouse
>  >>       button.  I suppose this is due to some off-by-one failure here but
>  >>       there might be more to it.
>  >
>  > I'm not sure this is at all related to R2L lines.  I wrote a trivial
>  > function which just displays the mouse event, and bound it to clicks
>  > on the horizontal scroll bar.  When I drag the scroll bar, even in an
>  > entirely L2R buffer, I see some strange phenomena: e.g., more often
>  > than not, when I drag the bar all the way to the right, releasing the
>  > mouse button without moving the mouse reports slightly different
>  > coordinates than the ones reported before releasing the mouse.
>  > Moreover, many time the 2nd coordinate reported after releasing the
>  > mouse is -1.  Try it.  Maybe it's Windows-specific, I don't know.
> 
> I suppose the -1 is due to the
> 
>        si.nPage = min (portion, si.nMax) + 1;
> 
> you mention below and that's likely the culprit for the effect described
> in (1).

Perhaps, but it's still unclear to me why this problem is not visible
in L2R buffers.

>  > Btw, it looks like the information returned by mouse events on the
>  > horizontal scroll bar is not described anywhere, not even in NEWS.
>  > Your use of (cdr (nth 2 start-position)) in
>  > scroll-bar-horizontal-drag-1 got my jaw dropped for a few seconds,
>  > before I realized it was not the Y coordinate...
> 
> I'm not sure yet where to eventually put this and whether it's the right
> solution at all.  IIUC the scroll bar area on the right of the thumb stands
> for w->hscroll in R2L text and this was the easiest way to pass on that
> value from what GetScrollInfo returns without consing.  If you have any
> suggestion how to handle this cleanly I'd be all ears.

I don't think your solution is unclean (the Y coordinate makes no
sense for horizontal scroll bar events), I just wish it were
documented, at least in NEWS.  It doesn't take more than a few lines.

>  >> (2) Sometimes during dragging the slider starts moving for-/backward in
>  >>       some erratic fashion.  I'm not yet sure whether this is caused by an
>  >>       hmargin issue or something else.
>  >
>  > I could only see this in the very first line of the tutorial.  There
>  > was an old and very subtle bug in xdisp.c, revealed by
>  > set_horizontal_scroll_bar, which caused broken cursor motion in that
>  > line.  This is now fixed in r117711 on the trunk.  If you still see
>  > something like that, and it's not related to the few L2R lines in the
>  > tutorial, please report a bug with the recipe.
> 
> I can see it only with my personal setup here.  With emacs -Q I can
> reproduce it by setting
> 
> (set-frame-parameter nil 'right-divider-width 7)
> 
> and scrolling the tutorial in the left window of a C-x 3 split frame.

On Windows XP, I cannot see this at all.  On Windows 7, I always see
this on the 1st line of the tutorial, even without setting
right-divider-width, and I see it when point is on most (but not all,
see below) lines if I do set right-divider-width.

Alas, I'm not your guy in these matters, as I'm clueless as to GUI
programming in general and Windows GUI in particular.  So I just
sprinkled fprintf lines in suspect places and watched them while
exercising the erratic behavior of the scroll bar.  Here are some
observations that might help you figure this out:

  . The erratic behavior seems to be due to our own code resetting the
    thumb position right after I drag the thumb to some new position.
    The code which causes this seems to be -- surprise, surprise --
    set_horizontal_scroll_bar that calls
    set_horizontal_scroll_bar_hook passing it the previous position.
    I didn't yet figure out why this affects only R2L lines.

  . If point is on an empty line, the problem doesn't happen.
    Likewise, if I drag the scroll bar of a non-selected window, the
    problem doesn't happen, either.  Maybe we call the scroll-bar hook
    too early, without giving redisplay the chance to hscroll all the
    windows?

(Btw, note that I needed a small change to be able to scroll correctly
non-selected windows; see r117712 on the trunk.)

(Btw2, when is x_horizontal_scroll_bar_report_motion called?  I
couldn't see it being called when the scroll bar is used.)

HTH



reply via email to

[Prev in Thread] Current Thread [Next in Thread]