Easy way to test is to change screen) to screen*) in the file and logout
and in again but I suspect you are right and it's something else.
On Thu, Feb 20, 2014 at 08:44:38PM -0500, Tim Visher wrote:
On Thu, Feb 20, 2014 at 6:40 PM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
On Thu, Feb 20, 2014 at 07:25:31PM -0500, Tim Visher wrote:
On Thu, Feb 20, 2014 at 6:40 PM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
Did you try modifying a copy of screen terminfo from the running system
instead of copying it from another? You only really need colors, setaf
The 1.9 changelog suggests to rebind keys to get back the old default-path
behavior doesn't it?
# grep default-path ~/.tmux.conf
set -g default-path -
It looks like I'll have to redefine and rebind keys to maybe get back that old
behavior but I'm not sure how and if that's the right solution.
On 21 February 2014 08:35, Carsten Mattner carstenmatt...@gmail.com wrote:
What's the status of implementing flow control to prevent tmux from
getting unresponsive of a wall of text is quickly printed?
See:
c0-change-{,trigger,interval}
-- Thomas Adam
On Fri, Feb 21, 2014 at 9:40 AM, Thomas Adam tho...@xteddy.org wrote:
On 21 February 2014 08:35, Carsten Mattner carstenmatt...@gmail.com wrote:
What's the status of implementing flow control to prevent tmux from
getting unresponsive of a wall of text is quickly printed?
See:
on osx, iterm2 has a nifty feature (oddly named semantic history) that
allows one to configure what happens when use command+clicks on a piece of
text(eg: open file name) by allowing one to run arbitrary shell command
with arguments such as string before click, string after click etc.
Is that
On 21 February 2014 09:27, Carsten Mattner carstenmatt...@gmail.com wrote:
On Fri, Feb 21, 2014 at 9:40 AM, Thomas Adam tho...@xteddy.org wrote:
On 21 February 2014 08:35, Carsten Mattner carstenmatt...@gmail.com wrote:
What's the status of implementing flow control to prevent tmux from
Many people complain about the all or nothing behavior of tmux mouse mode,
as it interferes with the usual mouse operations (eg see workarounds [1])
The workarounds are not good (eg, require to get in and out of mouse mode
etc)
Can we have an option to enable this:
* when user holds ALT button
epoll on Linux doesn't support /dev/null, you are probably hitting that. Do
export EVENT_NOEPOLL=1
Before starting tmux. Or use 1.9 which does this automatically.
Original message
From: Trevor Suarez ric...@gmail.com
Date: 19/02/2014 15:47 (GMT+00:00)
To:
No, terminal mouse support does not allow this.
Original message
From: Timothee Cour timothee.cour2+t...@gmail.com
Date: 20/02/2014 07:26 (GMT+00:00)
To: tmux-users@lists.sourceforge.net
Subject: allow ALT+mouse to control tmux to avoid overloading mouse
Many people
In theory it's possible to do this kind of thing (but not with command key
because terminal doesn't give us that) and it would be nice to have better
mouse support, but it needs someone who cares about mouse to write it and I am
too busy so I wouldn't hold your breath :-).
Original
Yes rebind the keys you use for neww and splitw.
Original message
From: Carsten Mattner carstenmatt...@gmail.com
Date: 21/02/2014 08:33 (GMT+00:00)
To: tmux-users@lists.sourceforge.net
Subject: 1.9 default-path
The 1.9 changelog suggests to rebind keys to get back the
Hi Thomas,
Am 20.02.2014 um 22:50 schrieb Thomas Adam tho...@xteddy.org:
I've released tmux 1.9, please see the CHANGES file for a list of more
detailed changes. This time, I've tried to make things a little clearer
about some of the more important changes users will need to be aware of.
On Wednesday 19 Feb 2014 23:26:03 Timothee Cour wrote:
Many people complain about the all or nothing behavior of tmux mouse mode,
as it interferes with the usual mouse operations (eg see workarounds [1])
The workarounds are not good (eg, require to get in and out of mouse mode
etc)
Can we
On Thu, Feb 20, 2014 at 09:50:40PM +, Thomas Adam wrote:
talk to an older tmux server. The fix for this is usually to restart the
tmux server; I'm hoping this is clear enough, and that this is propagated to
the user. Debian allows for this with changelogs, for example. I'm
assuming
On Fri, Feb 21, 2014 at 10:31 AM, Thomas Adam tho...@xteddy.org wrote:
On 21 February 2014 09:27, Carsten Mattner carstenmatt...@gmail.com wrote:
On Fri, Feb 21, 2014 at 9:40 AM, Thomas Adam tho...@xteddy.org wrote:
On 21 February 2014 08:35, Carsten Mattner carstenmatt...@gmail.com wrote:
ok I won't try this today so if anyone posts the configuration for
that I'll try it sooner and report success/fail. else I'll have first
have to figure out the configuration.
On Fri, Feb 21, 2014 at 10:48 AM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
Yes rebind the keys you use for
On 21 February 2014 12:15, hubert depesz lubaczewski dep...@depesz.com wrote:
2. is there a way to upgrade tmux without killing programs that run
under it?
No, a protocol bump is a protocol bump and something we try and avoid
doing, but when we do, we batch together functionality so that it
On 21 February 2014 12:56, Carsten Mattner carstenmatt...@gmail.com wrote:
ok I won't try this today so if anyone posts the configuration for
that I'll try it sooner and report success/fail. else I'll have first
have to figure out the configuration.
I did add examples of this to the CHANGES
On Fri, Feb 21, 2014 at 3:01 AM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
On Thu, Feb 20, 2014 at 07:25:31PM -0500, Tim Visher wrote:
On Thu, Feb 20, 2014 at 6:40 PM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
Did you try modifying a copy of screen terminfo from the
On Fri, Feb 21, 2014 at 3:01 AM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
On Thu, Feb 20, 2014 at 07:25:31PM -0500, Tim Visher wrote:
On Thu, Feb 20, 2014 at 6:40 PM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
Did you try modifying a copy of screen terminfo from the
On Fri, Feb 21, 2014 at 10:33 AM, Nicholas Marriott
nicholas.marri...@gmail.com wrote:
You can just copy setaf and setab, the idea is to leave everything except
them and colors alone
# infocmp -x screen screen-256color
comparing screen to screen-256color.
comparing booleans.
comparing
When you increase the height of the pane and you have some history then
the last lines of it will be pulled into the visible screen's content.
This is quite annoying for me and would like to have the option of just
filling the bottom with blanks. Do you also think this is a good idea?
I'm
Hi,
I'm actually thinking this is a niche option. I wouldn't think it's
needed.
Thomas Adam
On 21 Feb 2014 19:53, Balazs Kezes rlblas...@gmail.com wrote:
When you increase the height of the pane and you have some history then
the last lines of it will be pulled into the visible screen's
Commit [1] has broken tmux 1.9 so that it leads to crash. You can
reproduce the crash the following way. Let's assume we have a tmux with
an empty configuration. Start up a new session and enter the following
commands via Ctrlbcolon:
split-window
split-window
split-window
On Fri, Feb 21, 2014 at 01:45:39PM -0800, Suraj Kurapati wrote:
On Thu, Feb 20, 2014 at 1:50 PM, Thomas Adam tho...@xteddy.org wrote:
I've released tmux 1.9, please see the CHANGES file for a list of more
detailed changes. This time, I've tried to make things a little clearer
about some of
On Feb 21, 2014 2:33 PM, Thomas Adam tho...@xteddy.org wrote:
I don't list everything under the sun, I take a view to list those things
I
think are more interesting generally.
Fair enough. Thanks for your consideration.
Oops, must have been on crack for this one:
Index: window.c
===
RCS file: /cvs/src/usr.bin/tmux/window.c,v
retrieving revision 1.101
diff -u -p -r1.101 window.c
--- window.c28 Jan 2014 23:07:09 - 1.101
+++ window.c22
28 matches
Mail list logo
