Re: [code] [textadept] Curses scrollbars

From: Mitchell <>
Date: Mon, 26 Feb 2018 21:24:39 -0500 (EST)


Another late e-mail, but I didn't see a follow-up to my proposed patch. I've committed it anyway[1]. More information in the thread below.



On Wed, 11 Mar 2015, Mitchell wrote:

> Hi Chris,
> On Wed, 11 Mar 2015, Chris Emerson wrote:
>> Hi Mitchell,
>> On Fri, Dec 05, 2014 at 11:53:49AM -0500, Mitchell wrote:
>>> On Thu, 4 Dec 2014, Chris Emerson wrote:
>>>> One little annoyance: you can't drag the scroll bar in a non-focused
>>>> view;
>>>> the first click instead focuses that view, and then dragging works.
>>>> I note that selecting text in an unfocused view also behaves slightly
>>>> differently to the GUI version - as above the first time acts as the
>>>> focus-moving click, and then you can select. (In the GUI it selects and
>>>> focuses at the same time).
>>> When the mouse is pressed, the mouse event is sent to the currently
>>> focused view. If the view determines the mouse event happened
>>> outside of it (which is the case for what you've been reporting),
>>> then the view discards the event, and Lua gets a chance to handle it
>>> (which it does, by focusing the view clicked on). Subsequent mouse
>>> events are then sent to the newly focused view, and scrolls and
>>> selections will occur normally.
>>> In order to match GUI behavior completely, Textadept's C core must
>>> determine where the click occurred and focus the proper view (if
>>> necessary) before sending the mouse click to the view. This
>>> duplicates the Lua mouse handling code already in place, so I'm not
>>> sure how I feel about it. (The Lua mouse handling is based on your
>>> code and is required for split view dragging at least.)
>>> Do you have any thoughts on this?
>> I have some not very timely thoughts:
>> How about:
>> * Adding a Lua API to pass a mouse event into a view
>> * Pass all mouse events to Lua rather than trying the current view first
>> I think that would mean that a Lua handler could emulate the "right"
>> behaviour with a combination of goto_view and forwarding the events.
>> Even if the handler you ship doesn't go to the trouble of checking
>> view.buffer.[hv]_scroll_bar and (click on appropriate edge), it means
>> users can have their own handler which does exactly what they want.
> Thanks for your feedback. It helped me come up with an idea that seems to
> work. It involves utilizing a return value from an `events.MOUSE` handler --
> if non-`true`, try again on the current view (which may have been switched to
> by a handler!)
> Patch attached. If you agree with it, then I'll commit it.
> Cheers,
> Mitchell


You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Mon 26 Feb 2018 - 21:24:39 EST

This archive was generated by hypermail 2.2.0 : Tue 27 Feb 2018 - 06:44:26 EST