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
On Feb 21, 2014 2:33 PM, "Thomas Adam" 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.
--
Managing t
On Fri, Feb 21, 2014 at 01:45:39PM -0800, Suraj Kurapati wrote:
> On Thu, Feb 20, 2014 at 1:50 PM, Thomas Adam 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 the more i
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 b:
split-window
split-window
split-window
se
On Fri, Feb 21, 2014 at 1:59 AM, Paul Gideon Dann wrote:
> 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])
>
> In Konsole, I can hold do
On Thu, Feb 20, 2014 at 1:50 PM, Thomas Adam 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 the more important changes users will need to be aware of.
Hurray! But this new
On 21 February 2014 20:20, Balazs Kezes wrote:
> Do you have any central repo where we can drop extraneous, officially
> unsupported patches to tmux? I have some others as well. I'm thinking
"Officially unsupported" seems like a contradiction in terms. No,
there exists no such reository. You're
On 2014-02-21 19:59, Thomas Adam wrote:
> I'm actually thinking this is a niche option. I wouldn't think it's
> needed.
Yeah, I have an OCD to keep my terminals mostly clear by pressing ^L.
But after a resize (e.g. reattach from a bigger screen which happens a
lot of time for me) all my panes are
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" 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 content.
> This is
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 thinking
On Fri, Feb 21, 2014 at 10:33 AM, Nicholas Marriott
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 numbers.
colors: 8,
You can just copy setaf and setab, the idea is to leave everything except them
and colors alone
Original message
From: Tim Visher
Date: 21/02/2014 15:00 (GMT+00:00)
To: Nicholas Marriott
Cc: tmux-users@lists.sourceforge.net
Subject: Re: PS1 Not Wrapping
On Fri, Feb 21
On Fri, Feb 21, 2014 at 08:31:41AM -0500, Aaron Schrab wrote:
> At 13:15 +0100 21 Feb 2014, hubert depesz lubaczewski
> wrote:
> >2. is there a way to upgrade tmux without killing programs that run
> > under it?
>
> In the past I've avoided the need to kill some programs being run in
> a tmux s
On Fri, Feb 21, 2014 at 3:01 AM, Nicholas Marriott
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
>> wrote:
>> > Did you try modifying a copy of screen terminfo from the running system
>> > instead of copying it from anot
On Fri, Feb 21, 2014 at 3:01 AM, Nicholas Marriott
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
>> wrote:
>> > Did you try modifying a copy of screen terminfo from the running system
>> > instead of copying it from anot
On Fri, Feb 21, 2014 at 3:00 AM, Nicholas Marriott
wrote:
> 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.
Yep. Something else. :)
--
In Christ,
Timmy V.
http://blog.twonegatives.com/
http://five.sen
At 13:15 +0100 21 Feb 2014, hubert depesz lubaczewski wrote:
2. is there a way to upgrade tmux without killing programs that run
under it?
In the past I've avoided the need to kill some programs being run in a
tmux session in this situation by using reptyr[1] to temporarily move
them out o
On 21 February 2014 12:56, Carsten Mattner 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 file.
-- Thomas Adam
-
On 21 February 2014 12:15, hubert depesz lubaczewski 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
doesn't need to
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
wrote:
> Yes rebind the keys you use for neww and splitw.
>
>
>
>
On Fri, Feb 21, 2014 at 10:31 AM, Thomas Adam wrote:
> On 21 February 2014 09:27, Carsten Mattner wrote:
>> On Fri, Feb 21, 2014 at 9:40 AM, Thomas Adam wrote:
>>> On 21 February 2014 08:35, Carsten Mattner wrote:
What's the status of implementing flow control to prevent tmux from
get
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 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)
>
>
Hi Thomas,
Am 20.02.2014 um 22:50 schrieb Thomas Adam :
> 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.
Excellent! The REA
Yes rebind the keys you use for neww and splitw.
Original message
From: Carsten Mattner
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 old default-path
behavior d
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 mes
No, terminal mouse support does not allow this.
Original message
From: Timothee Cour
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 complain about the all or nothing
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
Date: 19/02/2014 15:47 (GMT+00:00)
To: tmux-users@lists.sourceforge.net
---
** [tickets:#100] Add cwd functionality for cygwin**
**Status:** open
**Labels:** cygwin
**Created:** Tue Feb 18, 2014 06:51 PM UTC by Dayton
**Last Updated:** Tue Feb 18, 2014 06:51 PM UTC
**Owner:** nobody
Currently, opening a new window or pane always opens a shell located at ~,
beca
I've been using Tmux 1.6 (release 3 from EPEL) on CentOS 6.4 for a while
now, and I've been trying to simply check if a named session is open from a
bash script... unfortunately, `tmux has-session` will output to stderr if
none is found. Any attempts to silence the output from stderr seem to
comple
Nicholas Marriott writes:
> Ok I think it is better not to include tmux.el at all then, instead just
> put the bit to copy in FAQ like this:
>
> diff --git a/FAQ b/FAQ
> index da72d43..c5abf01 100644
> --- a/FAQ
> +++ b/FAQ
> @@ -238,6 +238,31 @@ would be welcome.
>
> vim users may also want t
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 an
On 21 February 2014 09:27, Carsten Mattner wrote:
> On Fri, Feb 21, 2014 at 9:40 AM, Thomas Adam wrote:
>> On 21 February 2014 08:35, Carsten Mattner wrote:
>>> What's the status of implementing flow control to prevent tmux from
>>> getting unresponsive of a wall of text is quickly printed?
>>
>
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 poss
On Fri, Feb 21, 2014 at 9:40 AM, Thomas Adam wrote:
> On 21 February 2014 08:35, Carsten Mattner 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}
The default valu
On 21 February 2014 08:35, Carsten Mattner 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
---
What's the status of implementing flow control to prevent tmux from
getting unresponsive of a wall of text is quickly printed?
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to
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.
W
On Thu, Feb 20, 2014 at 07:25:31PM -0500, Tim Visher wrote:
> On Thu, Feb 20, 2014 at 6:40 PM, Nicholas Marriott
> 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
> > and setab.
>
> How w
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
> wrote:
> > Otherwise I suggest you also c
40 matches
Mail list logo
