nano-devel
[Top][All Lists]
Advanced

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

Re: what to call the option for the "scroll bar"?


From: Marco Diego Aurélio Mesquita
Subject: Re: what to call the option for the "scroll bar"?
Date: Thu, 21 May 2020 23:05:32 -0300

On 5/21/20, Benno Schulenberg <address@hidden> wrote:
>
> Op 18-05-2020 om 23:54 schreef Marco Diego Aurélio Mesquita:
>> IIRC, ncurses does send mouse move, down and up events. I even
>> remember some successful experiments modifying nano to select with
>> click and drag. It probably doesn't work on every terminal; I got it
>> to work on gnome-terminal and xterm while it did not work on Eterm.
>> Had to use printf("\033[?1003h\n") though. But it is definitely
>> possible to capture drag using ncurses.
>
> What does 1003h do?  Do you have a reference URL?
>

The 1003h enables "Any-event tracking". You can read about it here:
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html and
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Any-event-tracking
. Nevertheless, in my current I'm now using 1002h instead of 1003h.

>> Consider the attached diff. I think it is easy to enable events
>> related to mouse drag in nano (select, move selection, move
>> scrollbar...).
>>
>> Do you want me to implement a proof of concept to select text using
>> click and drag?
>
> Currently I'm not interested in selecting text with the mouse.
> I'm interested in dragging the indicator.
>
> (Personally, I wouldn't be tempted to click and drag the indicator,
> but people who use 'set mouse' probably will.  So it would be good
> if that actually worked.)
>

I can already detect drag events on the scrollbar paddle but we have
to decide some details about its behaviour.

What should be done when moving the scrollbar paddle puts the cursor
outside of the current edit window? I can see 3 options: leave the
cursor where it is, move the cursor together, move the cursor to the
first line (when scrolling down) or last line (when scrolling up) of
the current window.

Most gui apps simply leave the cursor where it is. Then, when a key is
pressed, the window is moved where the cursor is. I do not like this
behaviour and implementing this would need some more intrusive
changes.

Moving the cursor together with the window seem simpler to implement,
but seems less intuitive behaviour since we'll have one behaviour when
the scroll moves the cursor and another when the cursor is kept where
it is.

Moving the cursor to the first line (when scrolling down) or last line
(when scrolling up) is my preferred option and seems more intuitive
although that's is different from how most gui programs work.

So, what behaviour is the most likely to be accepted?



reply via email to

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