[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
- Re: Changes in frame/window code, (continued)
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/15
- Re: Changes in frame/window code, martin rudalics, 2014/08/16
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/16
- Re: Changes in frame/window code, martin rudalics, 2014/08/16
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/16
- Re: Changes in frame/window code, martin rudalics, 2014/08/16
- Re: Changes in frame/window code, martin rudalics, 2014/08/16
- Re: Changes in frame/window code, martin rudalics, 2014/08/16
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/17
- Re: Changes in frame/window code, martin rudalics, 2014/08/18
- Re: Changes in frame/window code,
Eli Zaretskii <=
- Re: Changes in frame/window code, martin rudalics, 2014/08/18
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/18
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/19
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/20
- Re: Changes in frame/window code, martin rudalics, 2014/08/20
- Re: Changes in frame/window code, martin rudalics, 2014/08/20
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/20
- Re: Changes in frame/window code, martin rudalics, 2014/08/28
- Re: Changes in frame/window code, Eli Zaretskii, 2014/08/28
- Re: Changes in frame/window code, martin rudalics, 2014/08/28