Hi,
maybe you can make use of some notes of how mouse mode could work, I
never got to the code part though.
* use a timer to time-out/ close the copy-mode after release of
mouse button
* remember the last active selection in copy mode per pane, even
after closing it dow
Hi
I'm partway through rewriting mouse support to allow mouse events to be
bound as keys, which should allow us to get rid of a bunch of special
cases.
Currently I haven't included double clicks, but they will have to work
differently anyway.
Probably best to leave this until I'm finished, which
On 2014-06-23 11:21 +0100, Nicholas Marriott wrote:
> Er, this time with pb != NULL. Doh. This is instead of "[PATCH 2/5]
> Refactor input_mouse()" of course.
I've rewritten my patches and I'm not modifying this file anymore. I
refactored because I needed one of the new variables in one of the
sub
[+Michael (OP)] in case he has some opinions.
On 2014-06-23 10:59 +0100, Nicholas Marriott wrote:
> I like copy-on-release and it is how xterm works (it preserves the
> selection too, but we don't really have an option of doing that).
Right, I shouldn't be changing behavior.
> Maybe instead you
Er, this time with pb != NULL. Doh. This is instead of "[PATCH 2/5]
Refactor input_mouse()" of course.
Index: cmd-paste-buffer.c
===
RCS file: /cvs/src/usr.bin/tmux/cmd-paste-buffer.c,v
retrieving revision 1.25
diff -u -p -r1.25 cmd-p
How about this instead (not tested)?
Index: cmd-paste-buffer.c
===
RCS file: /cvs/src/usr.bin/tmux/cmd-paste-buffer.c,v
retrieving revision 1.25
diff -u -p -r1.25 cmd-paste-buffer.c
--- cmd-paste-buffer.c 13 May 2014 07:34:35 -
I like copy-on-release and it is how xterm works (it preserves the
selection too, but we don't really have an option of doing that).
Maybe instead you could make a right- or middle-button drag select but
not exit copy mode?
On Sat, Jun 21, 2014 at 04:30:18PM +0100, Balazs Kezes wrote:
> From 18c
On 2014-06-20 14:11 +0100, Nicholas Marriott wrote:
> Can you do these separately? Ie the double/triple click bit separate
> from the right drag bit.
OK, I've managed to cut the patch into 5 pieces.
Note: In order this to look correctly in vi mode, it needs my changes
from [1]. Can you look into
Can you do these separately? Ie the double/triple click bit separate
from the right drag bit.
Cheers
On Sat, May 24, 2014 at 04:36:04PM +0100, Balazs Kezes wrote:
> So I used tmux with my mouse changes for a week. There are two
> annoyances with the previous patch. When you single click in pane
So I used tmux with my mouse changes for a week. There are two
annoyances with the previous patch. When you single click in pane which
is not listening for mouse events it automatically enters the copy mode.
This is very annoying because I often use mouse to select a pane. So
I've made modification
On 2014-05-09 14:19 +0100, Nicholas Marriott wrote:
> Well, in practice we need to have both copy mode and mouse support for
> it, and if that is the case we might as well have mouse support work
> well. IIRC xtmux already has code to do this, I looked at it before
> but never got round to applying
Well, in practice we need to have both copy mode and mouse support for
it, and if that is the case we might as well have mouse support work
well. IIRC xtmux already has code to do this, I looked at it before but
never got round to applying it.
On Fri, May 09, 2014 at 02:07:50PM +0100, Thomas Ada
On 9 May 2014 14:00, Michael Garrett wrote:
> All,
>
> Is there a way to enable xterm like “character class” mouse selection in
> tmux’s mode-mouse?
No, and it's already on the TODO list. You could just hold down
shift, and let the underlying terminal perform the same function,
should that be
All,
Is there a way to enable xterm like “character class” mouse selection in
tmux’s mode-mouse?
Just in case that sentence sounded like gibberish, to some, let me explain
what some of it means to help make sense of it. Stop reading if you already
know what character classes are in xterm.
14 matches
Mail list logo
