Re: [code] [textadept] Curses scrollbars

From: Mitchell <>
Date: Wed, 11 Mar 2015 14:31:07 -0400 (EDT)

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.


You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Wed 11 Mar 2015 - 14:31:07 EDT

This archive was generated by hypermail 2.2.0 : Thu 12 Mar 2015 - 06:35:43 EDT