* George Nachman [12-21-10 18:24]:
> Sounds good.
>
> I had a though the other day that it would be nice to support nested tmux
> sessions in this mode. I believe tmux doesn't normally support this, but I
> think it would be great to always run tmux locally to protect against the
> terminal emula
Sounds good.
I had a though the other day that it would be nice to support nested tmux
sessions in this mode. I believe tmux doesn't normally support this, but I
think it would be great to always run tmux locally to protect against the
terminal emulator crashing, but also allow people to ssh to a
On Sun, Dec 19, 2010 at 01:27:46PM -0600, George Nachman wrote:
>Awesome! Thanks for the update. Is there enough there that I could start
>testing? I didn't get as much done on vacation as I hoped, but split panes
>are very close to finished.
Not really yet, hopefully will get more don
Awesome! Thanks for the update. Is there enough there that I could start
testing? I didn't get as much done on vacation as I hoped, but split panes
are very close to finished.
On Sun, Dec 19, 2010 at 12:57 PM, Nicholas Marriott <
nicholas.marri...@gmail.com> wrote:
> I wrote enough of this to all
I wrote enough 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 Nachman wrote:
> >
>
>
> >
> >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 07, 2010 at 01:11:49PM -0800, George Nachman wrote:
>
> >
> > Easiest thing would just be to send it prefixed with E, I or O (or
> > ERROR/INFO/OUTPUT or whatever you prefer).
> >
> > Sure, that's fine. I and O could be grouped together, most likely.
> >
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
> > > think I'll be able to tell from the man page whic
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
> > 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 no
>
>
> >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
On Mon, Dec 06, 2010 at 05:44:29PM -0800, George Nachman wrote:
>- I added a %noop unsolicited message.
>- I changed the terminator from ^D to ^D NEWLINE to make it more
>human-friendly.
>- I'll keep ping because I do have a "send something every x seconds to
>keep the connectio
- I added a %noop unsolicited message.
- I changed the terminator from ^D to ^D NEWLINE to make it more
human-friendly.
- I'll keep ping because I do have a "send something every x seconds to keep
the connection alive" feature and ping will do the job.
As far as parsing command output, I'll need y
Do you want to differentiate error, info and normal ("print") output
from commands? 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,
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 04:47:18PM -0800, George Nachman wrote:
>Keeping ^D as the terminator. Not in love with the asymmetry, but ^D would
>be unnecessary in commands, and a
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:
actually scratch this, other commands can generate newlines and i don't
want to play substitution games
^D will be fine
On Tue, Dec 07, 2010 at 12:30:08AM +, Nicholas Marriott wrote:
> Since we give the length for "output" command and a pane target can't
> contain newlines, why not make EOF
Since we give the length for "output" command and a pane target can't
contain newlines, why not make EOF a newline? Using newline instead of
^D will make this usable by humans as well.
On Mon, Dec 06, 2010 at 04:01:05PM -0800, George Nachman wrote:
>Oh, I see the issue - when you give ssh a c
Two other things:
- We should have a "noop" command as well.
- I think the protocol commands (in both directions) should be clearly
different from normal tmux commands. I'd say prefix them with a % or
something or even make them capital letters (tmux commands will never
use caps).
On Mon,
Oh, I see the issue - when you give ssh a command to run that isn't your
shell then environment vars aren't passed through. I don't want to make it
difficult to be more flexible in the future, so I'll add a new command for
this. I could imagine one day supporting different settings for character
en
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 (if is UTF-8, 256 colours, 88
> > colours).
>
>
> > - 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 06, 2010 at 03:25:51PM -0800, George Nachman wrote:
>On Mon, Dec 6, 2010 at 3:09 PM, Nicholas Marriott
><[1]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:
>
>
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
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 because the OpenBSD tmux doesn't have a
version number.
- Your list of options has some things that
Sorry, I didn't have time to look at this yet, I'll do it tomorrow
evening probably.
Cheers
On Mon, Dec 06, 2010 at 02:43:52PM -0800, George Nachman wrote:
>As a follow-up, here is the design doc:
>
> [1]https://docs.google.com/document/d/1ABI0kqUUxoAjxhWW3AsWFis6bgvMoEbcTcA2N21ncmU/edit
As a follow-up, here is the design doc:
https://docs.google.com/document/d/1ABI0kqUUxoAjxhWW3AsWFis6bgvMoEbcTcA2N21ncmU/edit?hl=en&pli=1#
Comments are welcome. I'll keep working on the second part, but I'd like to
make sure the big picture looks OK before getting into the details.
On Mon, Nov 22,
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
I'm a bit lost here, tmux via iterm2 already works exactly as one
would expect, in fact I was planning on testing iterm +tmux -> ssh ->
screen in about 33 hours or so.
It seems to me, a user, that SSH already makes things transparent. It
actually all works fine, I'm exactly as happy as the day I
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 -0800, George Nachman wrote:
>Sorry for the delay, I was also on vacation. I think we're in agreement on
>the signif
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
On Thu, Nov 11, 2010 at 04:15:29PM -0800, George Nachman wrote:
> >> 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
>> 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 02:34:56PM -0800, George Nachman wrote:
> 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
George Nachman writes:
> I agree that specifying the size first makes more sense. Once you have
> to deal with separators, things get complicated with escaping and so
> on. I would prefer to have tmux's output be formatted for easy
> parsing. For instance, instead of:
>
> => list-sessions
> 0: 19
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 :-).
>>
>> Having delved a bit deeper, windo
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 :-).
>
> Having delved a bit deeper, window isn't quite the right term either
> as you can have multiple p
> 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 05:40:56PM -0800, George Nachman wrote:
> 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 wa
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 want to support the
>> >> use case of ssh'in
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 want to support the
> >> use case of ssh'ing to a remote host and running the tmux client
> >> there.
> >
>
>> 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
As far as history goes it would be possible for tmux to draw the entire
history to a file (or more accurately to a tmux buffer which could then
be saved to a file) as escape sequences for one terminal or another (we
already need an extension of capture-pane to save the history and there
is no reaso
On Sat, Nov 06, 2010 at 05:05:31PM -0700, George Nachman wrote:
> > 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 invasiv
Hi there,
I am the author of tmux-ruby.
George Nachman writes:
>> 2) Call tmux commands through the existing client. There is at least one
>> project I know of that does this already to provide a Ruby API to
>> tmux.
>
> I found the project (tmux-ruby) but not any documentation for it, so
> it'
> 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
On Fri, Nov 05, 2010 at 06:38:43PM -0700, George Nachman wrote:
> I guess I'm unclear on where the line is drawn between the tmux client
> and server. Is all state stored in the server, such as the scrollback
> buffer?
Yes, there is no state in the client aside from some very minor stuff
like exit
I guess I'm unclear on where the line is drawn between the tmux client
and server. Is all state stored in the server, such as the scrollback
buffer?
It may be the case that I have to write my own client, or extend the
existing client, which I'm OK with doing. I'd like my terminal
emulator to attac
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
> (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 clien
48 matches
Mail list logo
