Re: [PATCH, RFC] mouse tracking support

[Christoph Berg <cb@xxxxxxxx>]

Hi,

thanks for the comments.

Re: Gary Johnson 2007-05-21 <20070521183710.GA6722@xxxxxxxxxxxxxxxxxxxxxxxx>
> I just built the ncurses-5.5 library with --enable-ext-mouse and 
> built mutt-1.5.15 with this library and your patch on a machine 
> running SunOS 5.8.  With the minimal use I've given it so far, it 
> seems to work fine.

Thanks.

> I know mutt is intended to be driven from the keyboard, and I much 
> prefer using the keyboard to the mouse for almost everything, but I 
> run mutt in an xterm window right alongside Firefox (dual-monitor 
> display) and with the mouse already in my hand from using Firefox, 
> it's just natural to want to click on any new message that arrives 
> in mutt.

Same here.


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 first is an enhancement request.  Having gotten used to being 
> able to click on a message to open it, I tried clicking in the pager 
> mini-index to open one of the messages shown there, but it didn't 
> work.  It would be nice if the mouse worked there, too.

Should be possible, though harder than the current "mouse keys are
just normal keybindings" approach. (Which only adds one extra
jump-to-message-or-open-if-already-there binding aka <mouse-select>.)

> 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.

> 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;
+  }
+}

> 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.


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.

Christoph