This would be one application for a generic region layout. Panes and status
lines and parts thereof could be discernable areas with custom styles and mouse
click actions. Sort of what curses already allows, IIRC.
On May 25, 2015 2:27:26 AM CEST, Daniel Cotton
wrote:
>I've been toying with the
> I have a user defined bash function which takes one string parameter
> and does some operation on that string. i want to be able to call this
> function from with-in tmux and also pass the parameter from tmux
> itself. how can i achieve that ?
You can invoke bash with a command s
> Applied, but without the shift part.
Thx!
The shift part however is necessary in those cases mentioned where the
program has broken mouse support..
>> Because it gives all CLI programs (even bash history) "intuitive" mouse>>
>> support without updating/fixing every single one of them. There are
> I am still not convinced by this, I don't need more tests, I need good
> reasons why we should do this - what is it useful for apart from
> scrolling in less? Why shouldn't this be done in less itself? It can't
> be that hard to make less support the mouse.
Because it gives all CLI programs (even
Unless you have a "big" list and a "small" pane.
#Regards.
>From ce524403411ca19f50cb6af65c0994cd7e762776 Mon Sep 17 00:00:00 2001
From: Marcel Partap
Date: Sun, 13 Apr 2014 00:14:07 +0200
Subject: [PATCH 2/7] Re: m->scroll in choose-*: set to 1 by default?
---
window-choo
> Went with this, I think line-at-a-time is fine for choose mode, most of
> our lists are pretty short.
Objection: please take the patch I sent for this (13/04/2014 00:56) as
this one looses flexibility of using CTRL to speed up.
The assumption that choose-lists are small may be true for YOUR usage
f choices. Correction
attached.
#Regards.
>From 419a8102b6308477f62c54278eab77d034c8e8d3 Mon Sep 17 00:00:00 2001
From: Marcel Partap
Date: Sun, 13 Apr 2014 00:31:10 +0200
Subject: [PATCH 1/2] Don't wrap mouse scrolling in choice-mode lists v2
Feels somewhat more natural. Objecti
Feels somewhat more natural. Objections?
---
window-choose.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/window-choose.c b/window-choose.c
index 9406b9c..8f1ab5c 100644
--- a/window-choose.c
+++ b/window-choose.c
@@ -726,10 +726,13 @@ window_choose_mouse(
i
---
window-choose.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/window-choose.c b/window-choose.c
index e75858e..9406b9c 100644
--- a/window-choose.c
+++ b/window-choose.c
@@ -724,7 +724,8 @@ window_choose_mouse(
u_inti, idx;
This breaks consistency between different modes; does SHIFT+scrolling
not suit you well enough? That does single-line-scrolling but is not
documented yet, so you may have missed it.
#Regards/MPartap
--
Put Bad Developers
No issues found in weeks of heavy use, please test anyway.
---
input-keys.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/input-keys.c b/input-keys.c
index f092f97..1df8e98 100644
--- a/input-keys.c
+++ b/input-keys.c
@@ -204,6 +204,20 @@ input_mouse(struct window_pane *wp, s
Rationale:
· remove _MASK_ from SHIFT/META/CTRL for consistency with "Key modifier bits"
KEYC_ESCAPE/KEYC_CTRL/KEYC_SHIFT
· rename MOUSE_MASK_BUTTONS to MOUSE_MASK_BUTTON: only receiving single button
events
· comment rename button masks => event masks: drag and wheel are more events
than they a
(+ some other changes regarding mouse implementation)
- is u_int for i ok?
- was there a valid reason to use bit shifts for MOUSE_EVENT_*
constants?
- ...
---
input-keys.c| 18 +-
server-fn.c | 1 +
tmux.h | 23 +--
tty-keys.c | 27 +
Thx, found already out by using clang (make --debug was not useful)..
> It does when you realise has #define lines
which is quite a naughty name choice imho.
#Regards.
--
Flow-based real-time traffic analytics software. C
> I usually find it helpful to compile with clang in these situations
> (CC=/usr/bin/clang and CXX=/usr/bin/clang++). The error messages are
> usually much more helpful.
Sheesh that was helpful indeed THANKS :)
> # CC=clang ./configure --enable-debug
> ...
> depbase=`echo tty-term.o | sed 's|[^/]*$
> It fails to compile
more exactly:
> depbase=`echo tty-term.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> gcc -DPACKAGE_NAME=\"tmux\" -DPACKAGE_TARNAME=\"tmux\"
> -DPACKAGE_VERSION=\"1.10\" -DPACKAGE_STRING=\"tmux\ 1.10\"
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"tmux\"
> -DVERSION=\"1
> Hmm was working for me.
Nah I meant the revised version I sent in reply.. here's the latest. It
fails to compile however (help?).
>From 2e3633271798d9052953d23e5317812bdc32c015 Mon Sep 17 00:00:00 2001
From: Nicholas Marriott
Date: Wed, 26 Feb 2014 23:04:23 +
Subject: [PATCH] Implement simpl
Actually, it doesn't need a server_ function.
Then again, it doesn't compile for some obscure reason.
Huh?
>From 92a2e3db2cd2e8fabb01762bec678c3868a46e11 Mon Sep 17 00:00:00 2001
From: Nicholas Marriott
Date: Wed, 26 Feb 2014 23:04:23 +
Subject: [PATCH] Implement simple mouse wheel emulation,
> Not wild about returning +/- lines from the func
one could instead switch(m->wheel) and just return unsigned lines count?
> trying to avoid adding more functions to server-fn.c...
I don't quite grok the seperation logic between
server-fn.c/server-client.c/client.c ..
> Looks like gnome eats shi
> Can the duplicated code not be refactored into a shared function? It
> looks like you could pass in "m" and return an integer representing the
> number of key events to send?
Definitely, but I'm not quite sure where to put it...
---
[ Now why did git send-email munge my memo? .. anyway...]
Here's the 3rd iteration, including a wee man page section.
The code duplication sucks.
Comments welcome.
#Regards.
--
Flow-based real-time traffic analytics softwa
---
input-keys.c| 17 +
options-table.c | 7 +++
tmux.1 | 23 +++
tmux.h | 5 +
window-choose.c | 19 ++-
window-copy.c | 12 +---
6 files changed, 79 insertions(+), 4 deletions(-)
diff --git a/input-key
---
mode-key.c | 6 ++
tmux.h | 2 ++
window-choose.c | 13 +
3 files changed, 21 insertions(+)
diff --git a/mode-key.c b/mode-key.c
index 95fad28..668a6a2 100644
--- a/mode-key.c
+++ b/mode-key.c
@@ -76,6 +76,7 @@ const struct mode_key_cmdstr mode_key_cmdstr_edit[
> Gaaah! I just freaked myself out [..] guess I must have done something wrong
Happens :D
> Final quirk: I'm not seeing any altered behaviour when I hold down the
> shift, meta, or alt keys: from what I see in the code, aren't they
> supposed to alter the scroll rate?
In which state? copy-mode, al
>> > * With mouse-mode=on, vim scrolls as expected with the mouse wheel, but
>> > "less" does not: it enters copy mode.
>> show any special flag settings?
> LESS=-g -i -M -R -S -w -z-4
Still can't reproduce. What is your less version? #less -V
Also, does tmux command
# display-message "#{alternate_
> * With mouse-mode=on, vim scrolls as expected with the mouse wheel, but
> "less" does not: it enters copy mode.
Can only reproduce with less --no-init (no alternate screen).. does
# env|grep LESS
show any special flag settings?
> * With mouse-mode=off, vim and "less" both scroll as expected.
What
Thanks for your quick review & good catch, please try again with
attached revision. c;
#Regards!
P.S.: [some patch NIH broke the command history in alternate screen..]
>From 48c5d8b8bf332b3f67f77154561a36027e013198 Mon Sep 17 00:00:00 2001
From: Marcel Partap
Date: Mon, 17 Feb 2014 2
p 17 00:00:00 2001
From: Marcel Partap
Date: Mon, 17 Feb 2014 22:02:14 +0100
Subject: [PATCH] Implement simple mouse wheel emulation.
---
input-keys.c | 15 +++
tmux.h | 5 +
2 files changed, 20 insertions(+)
diff --git a/input-keys.c b/input-keys.c
index 7582a63..5c5e105
Hi,
>> On 1.7 when I had 2 panes the whole pane line was colored but now with
>> 1.8 only the half, this difference made be to believe that 1.8
>> introduced a bug. But after your mail I realized that this is actual a
>> very useful feature.
>
> Interesting... I was a bit confused by this as well
Rename
screen_redraw_cell_border1() => screen_redraw_get_border_rel()
screen_redraw_cell_border() => screen_redraw_cell_is_border()
screen_redraw_check_cell() => screen_redraw_get_cell_type()
screen_redraw_check_active() => screen_redraw_check_active_pane_indicator()
---
screen-redraw.c | 6
---
examples/tmux.vim | 2 +-
options-table.c | 9 +
screen-redraw.c | 27 ++-
tmux.1| 5 +
tty-term.c| 2 +-
5 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/examples/tmux.vim b/examples/tmux.vim
index e85f8ff..7547e35
---
screen-redraw.c | 2 ++
tty-acs.c | 64 -
2 files changed, 34 insertions(+), 32 deletions(-)
diff --git a/screen-redraw.c b/screen-redraw.c
index 1af1bb1..9e387c3 100644
--- a/screen-redraw.c
+++ b/screen-redraw.c
@@ -44,6 +44,7 @
---
screen-redraw.c | 77 -
1 file changed, 27 insertions(+), 50 deletions(-)
diff --git a/screen-redraw.c b/screen-redraw.c
index 6131907..1af1bb1 100644
--- a/screen-redraw.c
+++ b/screen-redraw.c
@@ -26,8 +26,6 @@ int screen_redraw_get_
> I can explain how everything fits together if anyone wants to have a go.
Lol I so would like to because I have a lot of use cases right there in
my mind but am simply not adept enough of a coder to get it done in a
justifiable amount of time c;
---
An overlay layer above the current window/pane/border/status line layer.
To display information overlays, option/selection dialogs, popup
menus (f.e. mouse right click on a window => split, kill, make
sticky, rename...)
One very use case is a character selection dialog for send keys,
allowing f
about.. UI overlays / windows?
Date: Sun, 14 Jul 2013 15:33:50 +0200
From: Marcel Partap
To: tmux-users@lists.sourceforge.net
On 14/07/13 15:33, Marcel Partap wrote:
> Salut,
> recently it occurred to me several times (f.e. when looking up list-keys
> or choose-tree, also while using aut
> I've had this problem before. Sometimes 'reset' doesn't fix it because
> the binary data includes the magic tmux escape code to set the window
> name. I have to go in and explicitly change the window name back, and
> then it works fine.
Splitting the window, breaking off the f0obared pane and kil
> The statusline indeed changes, when i start xterm it
> shows - for a moment then hides for several seconds...
> then starts this again forever.
..very likely that this is because it takes powerline longer to generate its
output than what your status interval is set to. You can test that by runn
>> tmux -L $(USER)
Uhhm 'tmux -L ${USER}' that is. Or simply '-L $USER'. Or '-L $RANDOM'...
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
--
See everything from the browser to the dat
> We all have root permission. How can I dissable
> others attach to my session?
Use a socket-name other than default. F.e. :
> tmux -L $(USER)
That'd prevent "accidental" session take-over.
#regards
--
See everything from
Salut,
recently it occurred to me several times (f.e. when looking up list-keys
or choose-tree, also while using autocomplete for these commands): how
useful would it be to have a floating tmux overlay window framework of
some sort... hey wait, it has. Curses is a hard dependency anyways,
right
Dear Jason,
you are still not far enough away from the keyboard.
On 27/04/13 00:08, Jason Timrod wrote:
> I am voicing [...] shit, [...] and it's not good enough.
--
Try New Relic Now & We'll Send You this Cool Shirt
New
[...]
> Thomas, you're [...]
Ok you crossed a thick red line right there. Would you bloody please
stop insulting ANYONE on ANY public opinion forum EVER AGAIN?
Please take some time far off a keyboard and reflect your demeanour. How
you dare spewing rants of disrespect at people whose hard labour
> You might want to disable ALL mouse support and that has to be
> possible. In fact, it has to be the default.
Ok if so, then it needs at least one more option in addition to
"mouse-copy-mode".. "mouse-choose" or something.
>>> We could split it up into a few options but what?
What? Clarity and
...
> isn't going to happen now, since I'm about
> to cut a release for 1.8.
Uhm ok.
> But adding in your changes now -- even by delaying 1.8 by a few days --
> simply is not an option.
Because?
> We would need much more time to ensure new code
> isn't going to introduce bugs
Much more time? The
..ok that was meant to be a reply to
<20130326160843.ga22...@yelena.nicm.ath.cx> sorry^^
--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for rec
s, noone gets
to scroll in his less pager. Because mouse scrolling is for wimps only
anyways. Huh?
#Regards.
>From 0a05c60331c99b87cef31ea4117f8a0144cb0422 Mon Sep 17 00:00:00 2001
From: Marcel Partap
Date: Sun, 24 Jun 2012 23:17:06 +0200
Subject: [PATCH 3/7] Rename mode-mouse option to mouse-
> Oh and the recent merge does look ugly indeed - cherry-picking is a much
> better way to deal with situations like that
...further diving into the git history, I dismiss my previous
statement.. cherry-picking from obsd-master is obviously not a real
option.. but is there no way to merge without
> On Tuesday evening -- I'm planning to release tmux 1.8.
> Any questions, please let me know.
Yes, would you be so kind and delay the release a couple of hours. Only
just took notice of it and imho some of the patches I sent in a year ago
and then again couple of months back should really really
> I don't have a scroll wheel here but
> I'm happy without an option and just to hardcode 3 lines
Nah, that's so not good enough.
And having used various incarnations of my patch for a considerable
amount of time, the flexibility of a variable setting and the modifier
keys really is a true asset fo
---
screen-redraw.c |4 ++--
tty-acs.c | 64 +++
2 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/screen-redraw.c b/screen-redraw.c
index 75f7238..7ffad30 100644
--- a/screen-redraw.c
+++ b/screen-redraw.c
@@ -41,8 +41
Scrolling mouse wheel while shift modifier key is held generates
fake cursor key events. With ctrl modifier added, speed is multi-
plied by the value of "mouse-scroll-speedup" variable (default 3).
---
examples/tmux.vim |2 +-
input-keys.c | 18 --
options-table.c |
---
examples/tmux.vim |2 +-
options-table.c |5 +
screen-redraw.c | 38 +++---
tmux.1|4
tty-term.c|2 +-
5 files changed, 38 insertions(+), 13 deletions(-)
diff --git a/examples/tmux.vim b/examples/tmux.vim
index
by picking up the process group leader from the terminal fd
via tcgetpgrp() instead of using the direct pane child process.
This correctly picks up the working directory for nested subshells.
(works on linux, other platforms untested)
---
cmd.c |2 +-
format.c |2 +-
---
window-copy.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/window-copy.c b/window-copy.c
index ca4c97b..bd78f30 100644
--- a/window-copy.c
+++ b/window-copy.c
@@ -836,7 +836,8 @@ window_copy_mouse(
} else if ((m->b & MOUSE_BUTTON) == MOUSE_2) {
and remove condition to enable mouse in choose mode.
This time, no backwards compatible mercy. RTFM!
---
input-keys.c|2 +-
options-table.c |8
server-client.c |2 +-
tmux.1 | 11 +--
window-choose.c |3 +--
window-copy.c |2 +-
window.c
>> by picking up the process group leader from the terminal fd
>> via tcgetpgrp() instead of using the direct pane child process.
>
> Why? I mean, what problem is this solving? You don't mention it in your
> commit message.
Nested subshells and su invocations. Consider this:
> # root key binding
>> +#define CELL_BORDERS " xqlkmjwvtun~" /* " │─┌┐└┘┬┴├┤┼·" */
>> +#define CELL_MARKERS " +, . -" /* " →← ↑ ↓" */
>
> And if I don't have a font capable of displaying the characters in the
> comments?
Then you should upgrade your text editing system of choice to be able to
handle 21st cent
>> First usage instance is the renaming of the mode-mouse option.
> Hmm. I am not sure I'm too keen on this approach.
a) Please elaborate.
b) Do you have a better idea to warrant config file backwards compability?
c) More opinions needed!
> What happens when/if
> mode-copy-mouse also needs renami
---
trunk/input-keys.c|2 +-
trunk/options-table.c |8
trunk/server-client.c |2 +-
trunk/tmux.1 | 11 +--
trunk/window-choose.c |3 +--
trunk/window-copy.c |2 +-
trunk/window.c|2 +-
7 files changed, 14 insertions(+), 16 deletions
by picking up the process group leader from the terminal fd
via tcgetpgrp() instead of using the direct pane child process.
(works on linux, other platforms untested)
---
trunk/cmd.c |2 +-
trunk/format.c |2 +-
trunk/osdep-aix.c |2 +-
trunk/osdep-darwin.c
---
trunk/window-copy.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/trunk/window-copy.c b/trunk/window-copy.c
index ca4c97b..bd78f30 100644
--- a/trunk/window-copy.c
+++ b/trunk/window-copy.c
@@ -836,7 +836,8 @@ window_copy_mouse(
} else if ((m->b & MOU
---
trunk/screen-redraw.c |4 ++--
trunk/tty-acs.c | 64 -
2 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/trunk/screen-redraw.c b/trunk/screen-redraw.c
index 75f7238..4d4899d 100644
--- a/trunk/screen-redraw.c
+++ b/trun
---
trunk/examples/tmux.vim |2 +-
trunk/options-table.c |5 +
trunk/screen-redraw.c | 38 +++---
trunk/tmux.1|4
trunk/tty-term.c|2 +-
5 files changed, 38 insertions(+), 13 deletions(-)
diff --git a/trunk/example
First usage instance is the renaming of the mode-mouse option.
---
trunk/cmd-set-option.c |3 ++-
trunk/options-table.c | 55
trunk/tmux.h |1 +
3 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/trunk/cmd-set-option
Scrolling mouse wheel while shift modifier key is held generates
fake cursor key events. With ctrl modifier added, speed is multi-
plied by the value of "mouse-scroll-speedup" variable (default 3).
---
trunk/examples/tmux.vim |2 +-
trunk/input-keys.c | 15 +--
trunk/options
..
Ok then how about supporting both in code, while changing the man page
to 'mouse-copy-mode' ?
#regards...
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat lan
> But I'm not clear what is what - can you send me any diffs that are
> finished and working with an explanation of what they do?
Yes sure, will rebase and polish my queue... The mouse behaviour patches
touch lines containing the 'mode-mouse' variable for which I posted a
patch to rename it:
> - mo
> So Tmux always forwards mouse input then?
Meaning, it doesn't interfere with it, yes.
#regards c:
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape ha
> but I thought mouse-mode enabled the copy behavior you describe, and also
> enables sending mouse events to apps, like Emacs or Vim for example. Allowing
> cursor positioning, buffer selection, scrolling, dragging and such which
> those apps.
Well try setting mode-mouse = off.
See, the current
couldn't find any previous case of variable rename in
tmux history..
?
#Regards\Marcel.
>From 8c2919547ad673832b5ce957d55e7c2b63265de8 Mon Sep 17 00:00:00 2001
From: Marcel Partap
Date: Sun, 24 Jun 2012 23:17:06 +0200
Subject: [PATCH] Rename mode-mouse option to mouse-copy-mode, always enabl
>> server to crash. :)
> uncrashed.
..mmh but dammit. Now only global session option "mouse-scroll-lines"
will be checked, no per-session override. huh.
also the code in window-copy.c would need to became an exact duplicate
of the mouse-fake-scrolling code for consistency.
Now what, masters of th
> server to crash. :)
uncrashed.
>From 7f588c64242b3c1d8a31d3bc6aaa1b590027b776 Mon Sep 17 00:00:00 2001
From: Marcel Partap
Date: Thu, 21 Jun 2012 12:01:55 +0200
Subject: [PATCH 4/4] Cleaned up implementation of mouse wheel scrolling
emulation.
---
trunk/examples/tmux.vim |2 +-
> You need to check the logic for "lines" in input_mouse() -- holding down
> ctrl and scrolling down all the way to the bottom of the window causes the
> server to crash. :)
ANY scrolling caused crashing. Because fatalx("missing option");
Well I put the option inbetween the other mouse-* options
G, what the rush^^
have been working on this and here's what i have in tree right now.
These are somewhat untested, will test and report back later... C:
>From a824632d2fb794fbc0e64d47fc15ef6e9e219b47 Mon Sep 17 00:00:00 2001
From: Marcel Partap
Date: Wed, 20 Jun 2012 15:48:27 +0200
Be as it may, what went in is rather only fixing odd behaviour..
What exactly is the functionality you are missing Fabio?
--
#regards/marcel
--
Live Security Virtual Conference
Exclusive live event will cover all the ways
Hi there fellow h4x0rz ;)
just wanted to have a comment on these, will finalize them after my exam
end of the month...
tmux-quiet-set-option.patch:
still useful, my use case is setting option window-status-fg when
splitting a window with su -l [different user]
tmux-recalculate-window-size-on-mous
Hi Nic,
> Is this finished or are you still working on it?
Finished. The last patch i posted is what i use at the moment.
#regardz | marcel C;
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive
> Does anyone have this working and can offer advice? Or anyone can
> think of something else to try?
Please try the patch i posted yesterday.
#regards.
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
On 24/12/11 09:27, Nicholas Marriott wrote:
Yes, not intended. Fix applied, thanks!
Uhhm.. well. Rerolled my previous patch (and converted the time_diff
function into a #MACRO). Another one here, don't exit mouse-mode for
mode-mouse=copy-mode when reaching bottom.
#regards/marcel.
--- input-ke
Fellow tmuxers,
at LAAAST! It is completed! ^^
There might be a few touch ups here and there that could be done but all
in all, my mouse overhauling effort has concluded with attached patch.
Changes:
- For panes not in xterm mouse tracking mode, 'emulate' wheel scrolling
by sending cursor up/do
On 06/12/11 09:06, Nicholas Marriott wrote:
I guess ncurses just do this with a queue and consuming them into to
build a mask which you could probably do too, but I'd have to go poke
around in the ncurses code to see for sure.
that's a good idea btw. Here.. will look later. #best
/**
> Thanks for your replies, I'll wait to see if a version of this patch will be
> included in tmux, otherwise, I'll patch myself.
The patch as posted works fine as is, have not had any problems. It has
some debug code still in that i will rip out ASAP, but please test if it
works for you.
#regards
phew, mind twisting TAILQ_* macros..but it works now. The problem
you described is gone with this, and also this patch allows for complex
mouse click patterns (like kill window on triple middle button click
then shift left click within one second).. that needs a config syntax
though. and ye
> Disabling "mode-mouse" fix the issue(s), but is there a way to keep
> mode-mouse enabled and not have this clicks issues, is that PuTTY related ?
It's an issue with the curses lib sometimes sending bogus mouse events.
Problem is that these can be filtered and i beliebe tmux tries to, but
it on
..just for reference, from konsole/src/ProcessInfo.cpp, includes omitted:
> virtual bool LinuxProcessInfo::readCurrentDir(int pid)
> {
> QFileInfo info( QString("/proc/%1/cwd").arg(pid) );
>
> const bool readable = info.isReadable();
>
> if ( readable && info.isSymL
> Don't shell out to date here -- the status lines get run via
> strftime() -- so just use the format specifiers for that directly and
> your load-average will go away, hopefully.
Yes, BUT i've had the problem disappear for other programs forked from
the status bar aswell. There's something wrong
This is weird
indeed ^^
Can you send "tmux info" output?
Yes we can C:
tmux 1.6, pid 8196, started Sat Sep 17 04:32:41 2011
socket path /tmp/tmux-0/default, debug level 0
system is Linux 3.1.0-rc4-00131-g9e79e3e #27 SMP PREEMPT Thu Sep 1 12:05:51
CEST 2011 x86_64
configuration file is /root/.t
Hi there :)
This is a strange thing, sometimes tmux totally pwns one CPU, just
noticed it has been consuming bloody 30hours of precious 2.8GHz
processor time that should have been going to BOINC *grrr* ^^
anyways, a crude statistical analysis after detaching all clients
> sleep 10s && killall -v
> I don't wanna show tmux split lines,how?
set-option pane-border-fg black
set-option pane-active-border-fg black
--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_
this is a great idea. i've been interested in making tmux "tablet" friendly
Heh well totally (:
in various ways, and my current solution (dwm + xdotool + shell scripts that
call tmux) is totally hack. i'd like to see this even expanded a bit so that
one could in their .tmux.conf bind functions
Thx, already had been looking at the received event without sign of
modifier:
int k;
for (k=1; k<512; k*=2)
log_debug("%s %d: (mouse.b & %d)=%d, (last_mouse.b & %d)=%d", __func__, __LINE__, k,
(mouse->b & k), k, (c->last_mouse.b & k));
http://invisible-island.net/xterm/ctlseqs/ctlseqs.html
Well but what IS the
[...] way to receive mouse button AND modifier [...]
?
> Eh?
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application perfo
..
> - I think the big bit added to server_client_handle_key would be better
>in a separate function.
That kinda depends on if it there is...
>> [...] a way to receive mouse button AND modifier [...]
.. (:
--
All of th
...With this, a double click on the status line (any part not belonging
to the window list) creates a new window.
Tricky stuff. Now i know much more about tmux debugging ^^
As i couldn't find a way to receive mouse button AND modifier, window
closing on CTRL+double click is yet missing.
#n8/reg
> haven't got time to look into this really, but it is on the pile in my
> inbox so if nobody else does I'll get to it after this week
Ok i have wasted couple of hours investigating this and conclusion is as
follows.
If any mouse-interactivity feature (f.e. mouse-select-pane) is turned on
(and, i
>/src/bulk/console/tmux/repo-cvs/github.com-ThomasAdam-tmux/tty.c:1006:
> undefined reference to `__b64_ntop'
just hit the same, apparently there's a -lresolv missing in makefile LIBS...
--
vRanger cuts backup tim
Salut :)
umm... while you have merged my patch for window scrolling (thaanx :D), the
issue with wheel events being not correctly passed when
either mouse-select-window or mouse-select-pane is turned on persists. Can you
reproduce that?
> 1) open less with text +1 page, scroll mouse.
> 2) toggle
> I don't follow, what is the problem? If you turn on mouse-select-pane it
> eats the scroll wheel button events?
no, it seems to alter them. ncmpcpp reacts on wheel events, less not.
> I think it would be better for scroll wheel to select panes not
> windows.
The patch only enables mouse wheel wi
Hi Nicholas et al.,
seeing that the previous issue (excessive redraws) seems to be solved (have not tested but patch seems clear), i want to bring up
another minor issue. Mouse scroll wheel events are only correctly passed if mouse-select-* is off.. while ncmpcpp can handle mouse
wheel input reg
1 - 100 of 109 matches
Mail list logo
