Re: [PATCH, RFC] mouse tracking support
On 2007-05-23, Christoph Berg <cb@xxxxxxxx> wrote:
> Re: Gary Johnson 2007-05-22 <20070522002157.GA19969@xxxxxxxxxxxxxxxxxxxxxxxx>
> > I've encountered a few issues with using this patch. None of these
> > are bugs, just areas where I think the behavior could be improved.
> > The next issue is probably just a matter of learning new habits, but
> > with this patch it is no longer possible to select text in a message
> > using just the mouse--you have to hold the shift key while selecting
> > text.
>
> That's a xterm/ncurses issue. The only way around is probably vim-like
> internal mouse handling. I admit that's the reason I don't use vim's
> mouse handling, but I might get used to it for mutt.
Now that I've thought about it more, I'm not sure that adding
vim-like internal selections is worth the effort. Besides, I
sometimes select text from the index, in which case I might have to
hold the shift key anyway. I just read that gaim-text (now Finch)
has this issue when their mouse feature is enabled, and their FAQ
says to use the shift key. In w3m, you can use the mouse for
scrolling, and if "we" ever wanted to add such a feature to mutt,
we'd have to give up internally handling selections anyway. To
select text in w3m, one has to use the shift key, too.
So, I think I can get used to holding the shift key for selections.
> > The last issue is becoming quite an annoyance and I think the
> > behavior should be changed. When the index fills only the top of
> > the screen, clicking anywhere in the empty space below the last
> > message selects the last message. This is a problem when you have
> > overlapping windows, mutt is running in a partially-hidden window,
> > and you click in an empty area of the window in order to bring it to
> > the foreground. If the indicator is already on the last message,
> > clicking in that empty area will also open the message.
>
> Easy to fix, should be:
>
> +void menu_mouse_click (MUTTMENU *menu, int op)
> +{
> + int click = LastY + menu->top - menu->offset;
> + if (click < 0)
> + click = 0; <-- return;
> + if (click >= menu->max)
> + click = menu->max -1; <-- return;
> + if (click == menu->current) {
> + mutt_ungetch(0, op);
> + } else {
> + menu->current = click;
> + menu->redraw = REDRAW_MOTION;
> + }
> +}
That works nicely. Thank you.
> > I think
> > this should be changed so that clicking in that area has no effect,
> > or scrolls the index down as '<' would, but does not open any
> > message.
>
> Btw, one cool side-effect of using menu_context with mouse tracking is
> that clicking into the "context" area will cause the screen to scroll.
Yes, I discovered that.
> One idea I had was to have more jump-and-$something features, e.g.
> using right-clicks in the index for tagging. I thought about a generic
> "mouse-" prefix for all operations that would cause them to do
> reasonable actions but it seemed too intrusive for the first version
> of the patch.
W3m has a menu of commonly-used functions that pops up with a
right-click. Having such a menu, especially if users could
configure the contents, would avoid users having to choose only
function to bind to the right mouse button.
I agree that just having the mouse working at all is enough for now.
Thanks again for doing this. I wish I had more time to help.
Regards,
Gary
--
Gary Johnson | Agilent Technologies
garyjohn@xxxxxxxxxxxxxxx | Mobile Broadband Division
http://www.spocom.com/users/gjohnson/mutt/ | Spokane, Washington, USA