Hi,
thanks for the comments.
Re: Gary Johnson 2007-05-21 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> 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
