The attached patch hides the cursor while drawing borders between window
panes.
Most programs hide the cursor while redrawing their chrome because it's
ugly to see the cursor jumping around the screen. Better for it to
disappear for a moment.
Here is a video demonstrating the issue:
https://dl.dr
The attached patch sends a notification to control-mode clients of a layout
change when a window is zoomed or unzoomed. Currently such a layout change
goes unremarked-upon, and control mode clients will find themselves out of
sync when a window is zoomed or unzoomed.
zoom_unzoom.patch
Description
Currently, "capture-pane -J" will output trailing spaces at the end of
every line, even if there aren't really spaces there (e.g., the line's
length is less than the grid's width). This causes problems for control
mode clients because the output of capture-pane is much larger than it
needs to be, a
cmd_print() has a bug that causes a crash on very long commands.
args_print() may return a value equal to the passed-in length, and
cmd_print() appends a null after that location, which steps on the stack of
cmdq_continue(). This patch reserves space for the null in the length
passed to arg_print()
When command mode is begun, new-session (or a command given on the command
line) is run automatically. Although the control client did not initiate
the command, it receives its output. The "extra" %begin-%end block throws
the client off. This changes modifies the %begin guard for commands not
initi
This fixes a bug in control mode. It occurs when unlinking the last
window in the current session. The %end guard is not printed because
the client's session is NULL after the last window is unlinked and the
session is automatically destroyed. As far as I can tell there's no
reason to require a non
for a few days til after 1.8?
>
>
> On Sun, Mar 24, 2013 at 01:37:57PM -0700, George Nachman wrote:
> > There is an odd bit of behavior in CUU and CUD when the cursor is at
> > the end of the line in xterm that tmux does not have. The following
> > command:
> >
> > ec
There is an odd bit of behavior in CUU and CUD when the cursor is at
the end of the line in xterm that tmux does not have. The following
command:
echo -e '\033[2J\033[2;80Ha\033[1Ab\n'
when run on a terminal 80 characters wide, will print both "a" and "b"
on the 80th column in xterm. In tmux, the
On Sat, May 5, 2012 at 12:02 PM, Nicholas Marriott <
nicholas.marri...@gmail.com> wrote:
> Hi
>
> - I think you don't need s->id and next_session_id because s->idx is
> unique and ever-increasing (it is impossible to renumber sessions).
>
>
This makes it more difficult to add the ability to renum
There is a problem with buffering in control mode. This happens when a pty
produces output faster than a control client can read. The problems are:
- the tmux job grows in memory usage with no upper bound
- even an alert user can't stop an out-of-control job fast enough to avoid
having to wait for
The attached patch adds control mode and is up to date with the latest
changes.
Index: tmux.h
===
--- tmux.h (revision 2749)
+++ tmux.h (working copy)
@@ -402,6 +402,7 @@
#define IDENTIFY_UTF8 0x1
#define IDENTIFY_256COLOUR
This patch adds hooks for notifications on window changes, session changes,
and layout changes.
notify.patch
Description: Binary data
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http:
This patch facilitates control mode's tty initialization by moving the
common code into a separate function.
termios.patch
Description: Binary data
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Cli
Missed this one in the previous window_set_name patch.
names.patch
Description: Binary data
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
a
This is used by control mode to get the window ID of the new window.
breakpane.patch
Description: Binary data
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but
Thanks!
On Sun, Mar 4, 2012 at 12:51 PM, Nicholas Marriott
wrote:
> Applied with a couple of fixes - usages need to be sorted, and you need
> to free both the format itself and the return from format_expand.
>
> Cheers
>
>
> On Sun, Mar 04, 2012 at 12:08:09PM -0800,
+ return (KEYC_NONE);
> + return (u);
> + }
>
> /* Check for modifiers. */
> modifiers = 0;
>
>
>
> On Sun, Mar 04, 2012 at 11:52:58AM -0800, George Nachman wrote:
>> It's a little inefficient w
lso I guess the same -F flag should be added to split-window?
>
>
> On Sat, Mar 03, 2012 at 07:01:51PM -0800, George Nachman wrote:
>> Thanks for committing the previous patch. Here is a patch that adds a -F
>> format arg to new-window that can be used in conjunction with -
It's a little inefficient when sending a lot of keys, but it's a much
cleaner solution. The only thing I'd change is to also accept size ==
4.
Index: key-string.c
===
--- key-string.c(revision 2710)
+++ key-string.c(wo
This patch adds a -h argument to send-keys. It is intended for control mode
to avoid any running into problems with transmitting certain bytes over a
transport with inband signaling (e.g., telnet) or for sending special keys
that the terminal driver might affect (like newlines). Example usage to
se
Thanks for committing the previous patch. Here is a patch that adds a -F
format arg to new-window that can be used in conjunction with -P. Note that
it doesn't support any of the window pane format strings because it doesn't
seem to make sense in this context.
Index: cmd-new-window.c
=
week.
>
> Thanks
>
>
> On Sun, Feb 05, 2012 at 10:06:04PM -0800, George Nachman wrote:
>> As we discussed earlier, this patch adds -F format to display-message.
>> If -F is passed then that format is used in pref
As we discussed earlier, this patch adds -F format to display-message.
If -F is passed then that format is used in preference to the
'message' argument.
Index: tmux.1
===
--- tmux.1 (revision 2697)
+++ tmux.1 (working copy)
This patch adds a new command, move-pane. It is a wafer-thin wrapper
around the implementation of join-pane and simply removes the
restriction that source and target must belong to different windows.
In order for move-pane to be complete, join-pane gets a -b argument
that says to place the source b
This is a trivial patch that paves the way for control mode to change
the tty size without code duplication.
Index: tmux.h
===
--- tmux.h (revision 2697)
+++ tmux.h (working copy)
@@ -1454,6 +1454,7 @@
void tty_pututf8(st
This patch replaces the repeated pattern of freeing a window name and
setting it to a strdup'ed value with a function. It lays the trail for
a future patch which adds a control client notification when windows
are renamed.
Do you want me to send a patch for the list-windows target or are you
handl
The following patch includes these changes:
- Define a window ID and a session ID that is unique for the lifetime
of a tmux server. (session ID isn't yet exposed, but will be visible
to control clients in a future patch)
- Change layout_dump to include window pane IDs in its output
- Define a windo
iTerm2's mouseless copy has worked pretty well and might serve as a
basis for a similar feature here. Here's how it works:
You press Cmd-F and you get a search box (like Chrome or Firefox).
Type some text that matches what you want to copy. Pressing enter
advances to the next match, shift-enter to
This document describes in text the changes made and their
motivations. At the end, I make recommendations on how to split this
up into multiple smaller commits.
New Files
--
There are four new files:
1. control.c
Handles basic I/O with control clients, including:
- Queuing spontan
On Fri, Jan 20, 2012 at 11:34 PM, Nicholas Marriott
wrote:
> Hi
>
> I got it now. Thanks.
>
> This mostly looks fine aside from style nits which will be easy to sort
> out, although I'll wait to see the diff to see what impact it has
> outside control.c.
>
> You will need to add your copyright lin
G
On Fri, Jan 20, 2012 at 12:19 PM, Nicholas Marriott
wrote:
> Where is the latest code? Is this it https://github.com/gnachman/tmux.git?
>
> Cheers
>
>
> On Tue, Dec 20, 2011 at 10:52:23PM -0800, George Nachman wrote:
>> If you use a Mac, you might be interested to know that
If you use a Mac, you might be interested to know that a new test
build of iTerm2 includes tmux integration. By running tmux with a new
argument, tmux windows are rendered as native windows or tabs. There's
no more need for a prefix key. Interacting with windows and split
panes becomes easier, and
I've noticed that there's a slight difference in how the DECSC/DECRC codes
work in tmux vs. xterm. tmux is compatible with how screen works, so it
very well may be intentional, but I want to be sure, since xterm is
sometimes considered the canonical implementation of a terminal.
In tmux, the DECSC
> On Sun, Dec 04, 2011 at 03:58:36PM +0100, Romain Francoise wrote:
>> I think I spoke too fast. KERN_FILE_BYPID only gives you the inode number
>> of the cwd and the mountpoint of the filesystem where it's located.
>
> Hm. That sucks... looks like getcwd() works by walking each vnode on
> the
Hi Nicholas,
I've got some time coming up to work on this. Can you send me whatever
you've done so far?
Thanks,
George
On Wed, Mar 23, 2011 at 11:12 PM, Nicholas Marriott
wrote:
> Yep this is a cool idea and I am happy but that George wrote up the
> design doc but I haven't had time up to now a
tmux's socket directly, more that
> there is already a protocol used over the socket. Why not have iTerm2
> reuse it?
>
> -Kekoa
>
> On Thu, Mar 24, 2011 at 12:01 PM, George Nachman
> wrote:
> >> In a sense tmux is already client/server via a socket in /tmp but I
&
>
> In a sense tmux is already client/server via a socket in /tmp but I
> don't know if the protocol was done in a way that would allow new
> clients to be written easily.
The advantage of making the tmux client talk to iTerm2 over having iTerm2
communicate directly with tmux's socket is that you
t; Date: Tue, 21 Dec 2010 18:38:49 -0500
> From: Patrick Shanahan
> Subject: Re: Integration with a terminal emulator
> To: tmux-users@lists.sourceforge.net
> Message-ID: <20101221233849.gd11...@wahoo.no-ip.org>
> Content-Type: text/plain; charset=us-ascii
>
> * George Nachm
udo
terminal's "tmux mode" flag off.
This would allow the terminal emulator to attach to all nested tmux sessions
when it starts up. What do you think of this idea?
On Tue, Dec 21, 2010 at 2:21 PM, Nicholas Marriott <
nicholas.marri...@gmail.com> wrote:
> On
ugh of this to allow a client to do everything on stdin (ie,
> the easy bit) but I've been too busy again to do much else :-/.
>
> Just to let you know I haven't forgotten, will hopefully get back to it
> soon...
>
>
> On Tue, Dec 07, 2010 at 04:00:17PM -0800, George N
>
> >
> >I added a prefix to tmux's output and defined E, I, and P in the spec.
> >I'd like to add a new tmux command that allows the client to store and
> >retrieve an arbitrary dictionary of string->string. I want to store
> window
> >positions, font names, etc., so that when you
On Tue, Dec 7, 2010 at 2:08 AM, Nicholas Marriott <
nicholas.marri...@gmail.com> wrote:
> On Mon, Dec 06, 2010 at 06:24:29PM -0800, George Nachman wrote:
> > > As far as parsing command output, I'll need your help on that. I
> don't
> > > thin
>
>
> >As far as parsing command output, I'll need your help on that. I don't
> >think I'll be able to tell from the man page which commands generate
> which
> >errors. I will need to know if a command's output is normal or an
> error.
> >If the result is an error then I need two th
ommands? If so, how?
>
>
> On Tue, Dec 07, 2010 at 01:20:09AM +, Nicholas Marriott wrote:
> > I want a %noop from tmux->terminal, I don't really care about a ping
> > command, but if you need it then that's fine.
> >
> >
> > On Mon, Dec 06, 2010 at
Keeping ^D as the terminator. Not in love with the asymmetry, but ^D would
be unnecessary in commands, and appears to be necessary in responses (with
the alternative being lengths, but that is hard on humans).
On Mon, Dec 6, 2010 at 4:24 PM, Nicholas Marriott <
nicholas.marri...@gmail.com> wrote:
On Mon, Dec 06, 2010 at 03:36:56PM -0800, George Nachman wrote:
> > > - There needs to be a mechanism to specify the client "identify"
> > > information, particularly the terminfo description tmux should use
> but
> > > also the terminal flags (
>
>
> > - There needs to be a mechanism to specify the client "identify"
> > information, particularly the terminfo description tmux should use
> but
> > also the terminal flags (if is UTF-8, 256 colours, 88
> > colours). Easiest probably to have that as an argument to -C.
> >
>
On Mon, Dec 6, 2010 at 3:09 PM, Nicholas Marriott <
nicholas.marri...@gmail.com> wrote:
> Actually I had a quick look now,
>
> Looks good, and the idea of using APC is a good one.
>
> A few things:
>
> - I think the handshake should have the tmux version or a protocol
> version. I think the latter
On Mon, Nov 22, 2010 at 1:15 PM, Nicholas Marriott <
nicholas.marri...@gmail.com> wrote:
> At the moment I don't see a problem adding code to do this but how much
> free time I have is highly variable so no guarantees how quickly.
>
>
> On Thu, Nov 18, 2010 at 01:06:20AM -
Not to worry, the plan won't break your current workflow if that is what you
prefer.
So far what we have discussed is an API between iTerm2 and tmux that would
allow tmux's state to be reflected in iTerm2's. My goal in proposing this
idea was to make the environment seamless. There are cases where
Sorry for the delay, I was also on vacation. I think we're in agreement on
the significant issues. Will you be able to proceed with this? I will start
drafting a design doc if you think it's feasible on your end. I found
another term that does something similar (http://eterm.org), though I
haven't
>> That would work. We could actually go all-pull on the protocol and
>> have a blocking "poll for new data" command that I send you, if that
>> makes life any easier. It's all the same from the client's end.
>
> Hmm. It all seems much the same to me, in both cases you will block in
> poll or selec
On Thu, Nov 11, 2010 at 1:51 PM, Nicholas Marriott
wrote:
> On Thu, Nov 11, 2010 at 11:10:36AM -0800, George Nachman wrote:
>> > Its probably best to use the tmux terminology if you're talking getting
>> > stuff out of tmux because that's what it'll use :
> Its probably best to use the tmux terminology if you're talking getting
> stuff out of tmux because that's what it'll use :-).
Having delved a bit deeper, window isn't quite the right term either
as you can have multiple panes in one window. I would prefer to show
each pane in its own tab (event
On Wed, Nov 10, 2010 at 4:33 PM, Nicholas Marriott
wrote:
> On Wed, Nov 10, 2010 at 01:41:36PM -0800, George Nachman wrote:
>> >> Now that I understand your architecture better, it's pretty clear to
>> >> me that we don't want to write our own client. I
>> Now that I understand your architecture better, it's pretty clear to
>> me that we don't want to write our own client. I want to support the
>> use case of ssh'ing to a remote host and running the tmux client
>> there.
>
> In that case your only options from what I can see are:
>
> a) Open an ss
> There are three approaches I can see:
>
> 1) Protocol changes. This could work, could have a flag to mark this as
> an "extended" client that gets additional update messages in various
> places. I'd be concerned how invasive this would be though.
Now that I understand your architecture better, i
ectly, the server is already
responsible for rendering).
On Fri, Nov 5, 2010 at 6:20 PM, Nicholas Marriott
wrote:
> On Fri, Nov 05, 2010 at 05:53:08PM -0700, George Nachman wrote:
>> Hi tmux-users,
>>
>> I'm the maintainer for a terminal emulator on MacOS
>> (h
Hi tmux-users,
I'm the maintainer for a terminal emulator on MacOS
(http://iterm2.googlecode.com) and I am assessing the feasibility of
adding support for acting as a tmux client to my program. I'm
intrigued by your client-server interface, which seems to make this
much more doable than in other
59 matches
Mail list logo
