Re: [PATCH 0/4] Add handling of client focus tracking
A single patch is attached as well for easy application. On Friday, February 22, 2013 at 11:54 PM, Aaron Jensen wrote: > Add handling of client focus tracking. > > Also trying a different send-email approach, let me know how it works. > > Aaron Jensen (4): > Turn bracketed paste mode on and off externally > Track client focus > Set focused by default > Check for client focus in server_client_check_focus > > server-client.c | 20 ++-- > tmux.h | 4 > tty-keys.c | 14 ++ > tty.c | 4 ++-- > 4 files changed, 34 insertions(+), 8 deletions(-) > > -- > 1.8.1.3 > > external-focus-tracking.patch Description: Binary data -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: [PATCH 0/4] Add handling of client focus tracking
This looks good, the only problem is you need to skip where c == NULL || c->session == NULL in the loop server_client_check_focus in because the array can contain NULL clients but don't worry I will fix that. On Fri, Feb 22, 2013 at 11:59:33PM -0800, Aaron Jensen wrote: >A single patch is attached as well for easy application. > >On Friday, February 22, 2013 at 11:54 PM, Aaron Jensen wrote: > > Add handling of client focus tracking. > Also trying a different send-email approach, let me know how it works. > Aaron Jensen (4): > Turn bracketed paste mode on and off externally > Track client focus > Set focused by default > Check for client focus in server_client_check_focus > server-client.c | 20 ++-- > tmux.h | 4 > tty-keys.c | 14 ++ > tty.c | 4 ++-- > 4 files changed, 34 insertions(+), 8 deletions(-) > -- > 1.8.1.3 > -- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > ___ > tmux-users mailing list > tmux-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tmux-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: [PATCH 0/4] Add handling of client focus tracking
Applied now thanks. On Fri, Feb 22, 2013 at 11:59:33PM -0800, Aaron Jensen wrote: >A single patch is attached as well for easy application. > >On Friday, February 22, 2013 at 11:54 PM, Aaron Jensen wrote: > > Add handling of client focus tracking. > Also trying a different send-email approach, let me know how it works. > Aaron Jensen (4): > Turn bracketed paste mode on and off externally > Track client focus > Set focused by default > Check for client focus in server_client_check_focus > server-client.c | 20 ++-- > tmux.h | 4 > tty-keys.c | 14 ++ > tty.c | 4 ++-- > 4 files changed, 34 insertions(+), 8 deletions(-) > -- > 1.8.1.3 > -- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > ___ > tmux-users mailing list > tmux-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tmux-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
[PATCH] Expand variables in the run-shell command string
Let's say I want to write a shell script that operates on the
currently focused pane, to be executed with 'run-shell'. The only way
to do that for now is to call 'tmux list-panes' inside the script and
parse the output to determine the active pane. This patches modifies
run-shell to expand tmux #{variables} in the command string, so data
about tmux can be passed to run-shell commands.
This is implemented in Thomas Adams hook-support branch, but as shown
above, it is useful without hooks support.
Since Thomas can't foresee when he will merge hook-support, and I
would like to see this feature in the next version, here it goes.
---
cmd-run-shell.c | 19 +++
tmux.1 | 2 ++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/cmd-run-shell.c b/cmd-run-shell.c
index 9b4c006..d25c5e6 100644
--- a/cmd-run-shell.c
+++ b/cmd-run-shell.c
@@ -75,20 +75,31 @@ cmd_run_shell_exec(struct cmd *self, struct cmd_ctx *ctx)
{
struct args *args = self->args;
struct cmd_run_shell_data *cdata;
- const char *shellcmd = args->argv[0];
+ const char *shellcmd;
+ struct session *s;
+ struct winlink *wl;
struct window_pane *wp;
+ struct format_tree *ft;
- if (cmd_find_pane(ctx, args_get(args, 't'), NULL, &wp) == NULL)
+ wl = cmd_find_pane(ctx, args_get(args, 't'), &s, &wp);
+ if (wl == NULL)
return (CMD_RETURN_ERROR);
+ ft = format_create();
+ format_session(ft, s);
+ format_winlink(ft, s, wl);
+ format_window_pane(ft, wp);
+ shellcmd = format_expand(ft, args->argv[0]);
+
cdata = xmalloc(sizeof *cdata);
- cdata->cmd = xstrdup(args->argv[0]);
+ cdata->cmd = xstrdup(shellcmd);
cdata->wp_id = wp->id;
-
cdata->ctx = ctx;
cmd_ref_ctx(ctx);
job_run(shellcmd, cmd_run_shell_callback, cmd_run_shell_free, cdata);
+ format_free(ft);
+ free(shellcmd);
return (CMD_RETURN_YIELD); /* don't let client exit */
}
diff --git a/tmux.1 b/tmux.1
index 882a71f..ada931a 100644
--- a/tmux.1
+++ b/tmux.1
@@ -3490,6 +3490,8 @@ option.
Execute
.Ar shell-command
in the background without creating a window.
+The command string is expanded using the rules specified in the FORMATS
+section.
After it finishes, any output to stdout is displayed in copy mode (in the pane
specified by
.Fl t
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb___
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: [PATCH] Expand variables in the run-shell command string
Hi
Thanks but can you do the same for the if-shell shell-command as well?
In the manpage you need to markup FORMATS as .Sx FORMATS (there are some
examples already in the file).
On Sat, Feb 23, 2013 at 01:45:43PM -0300, Thiago Padilha wrote:
> Let's say I want to write a shell script that operates on the
> currently focused pane, to be executed with 'run-shell'. The only way
> to do that for now is to call 'tmux list-panes' inside the script and
> parse the output to determine the active pane. This patches modifies
> run-shell to expand tmux #{variables} in the command string, so data
> about tmux can be passed to run-shell commands.
>
> This is implemented in Thomas Adams hook-support branch, but as shown
> above, it is useful without hooks support.
>
> Since Thomas can't foresee when he will merge hook-support, and I
> would like to see this feature in the next version, here it goes.
>
> ---
> cmd-run-shell.c | 19 +++
> tmux.1 | 2 ++
> 2 files changed, 17 insertions(+), 4 deletions(-)
> diff --git a/cmd-run-shell.c b/cmd-run-shell.c
> index 9b4c006..d25c5e6 100644
> --- a/cmd-run-shell.c
> +++ b/cmd-run-shell.c
> @@ -75,20 +75,31 @@ cmd_run_shell_exec(struct cmd *self, struct cmd_ctx *ctx)
> {
> struct args *args = self->args;
> struct cmd_run_shell_data *cdata;
> - const char *shellcmd = args->argv[0];
> + const char *shellcmd;
> + struct session *s;
> + struct winlink *wl;
> struct window_pane *wp;
> + struct format_tree *ft;
>
> - if (cmd_find_pane(ctx, args_get(args, 't'), NULL, &wp) == NULL)
> + wl = cmd_find_pane(ctx, args_get(args, 't'), &s, &wp);
> + if (wl == NULL)
> return (CMD_RETURN_ERROR);
>
> + ft = format_create();
> + format_session(ft, s);
> + format_winlink(ft, s, wl);
> + format_window_pane(ft, wp);
> + shellcmd = format_expand(ft, args->argv[0]);
> +
> cdata = xmalloc(sizeof *cdata);
> - cdata->cmd = xstrdup(args->argv[0]);
> + cdata->cmd = xstrdup(shellcmd);
> cdata->wp_id = wp->id;
> -
> cdata->ctx = ctx;
> cmd_ref_ctx(ctx);
>
> job_run(shellcmd, cmd_run_shell_callback, cmd_run_shell_free, cdata);
> + format_free(ft);
> + free(shellcmd);
>
> return (CMD_RETURN_YIELD); /* don't let client exit */
> }
> diff --git a/tmux.1 b/tmux.1
> index 882a71f..ada931a 100644
> --- a/tmux.1
> +++ b/tmux.1
> @@ -3490,6 +3490,8 @@ option.
> Execute
> .Ar shell-command
> in the background without creating a window.
> +The command string is expanded using the rules specified in the FORMATS
> +section.
> After it finishes, any output to stdout is displayed in copy mode (in the
> pane
> specified by
> .Fl t
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> ___
> tmux-users mailing list
> tmux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tmux-users
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: [PATCH] Expand variables in the run-shell command string
Ok here is the updated patch
---
cmd-if-shell.c | 20 ++--
cmd-run-shell.c | 18 ++
tmux.1 | 10 --
3 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/cmd-if-shell.c b/cmd-if-shell.c
index 6f0b151..011974f 100644
--- a/cmd-if-shell.c
+++ b/cmd-if-shell.c
@@ -55,7 +55,21 @@ cmd_if_shell_exec(struct cmd *self, struct cmd_ctx *ctx)
{
struct args *args = self->args;
struct cmd_if_shell_data *cdata;
- const char *shellcmd = args->argv[0];
+ const char *shellcmd;
+ struct session *s;
+ struct winlink *wl;
+ struct window_pane *wp;
+ struct format_tree *ft;
+
+ wl = cmd_find_pane(ctx, NULL, &s, &wp);
+ if (wl == NULL)
+ return (CMD_RETURN_ERROR);
+
+ ft = format_create();
+ format_session(ft, s);
+ format_winlink(ft, s, wl);
+ format_window_pane(ft, wp);
+ shellcmd = format_expand(ft, args->argv[0]);
cdata = xmalloc(sizeof *cdata);
cdata->cmd_if = xstrdup(args->argv[1]);
@@ -68,7 +82,9 @@ cmd_if_shell_exec(struct cmd *self, struct cmd_ctx *ctx)
cmd_ref_ctx(ctx);
job_run(shellcmd, cmd_if_shell_callback, cmd_if_shell_free, cdata);
-
+ format_free(ft);
+ free(shellcmd);
+
return (CMD_RETURN_YIELD); /* don't let client exit */
}
diff --git a/cmd-run-shell.c b/cmd-run-shell.c
index 9b4c006..69423e5 100644
--- a/cmd-run-shell.c
+++ b/cmd-run-shell.c
@@ -75,20 +75,30 @@ cmd_run_shell_exec(struct cmd *self, struct cmd_ctx *ctx)
{
struct args *args = self->args;
struct cmd_run_shell_data *cdata;
- const char *shellcmd = args->argv[0];
+ const char *shellcmd;
+ struct session *s;
+ struct winlink *wl;
struct window_pane *wp;
+ struct format_tree *ft;
- if (cmd_find_pane(ctx, args_get(args, 't'), NULL, &wp) == NULL)
+ wl = cmd_find_pane(ctx, args_get(args, 't'), &s, &wp);
+ if (wl == NULL)
return (CMD_RETURN_ERROR);
+ ft = format_create();
+ format_session(ft, s);
+ format_winlink(ft, s, wl);
+ format_window_pane(ft, wp);
+ shellcmd = format_expand(ft, args->argv[0]);
+
cdata = xmalloc(sizeof *cdata);
- cdata->cmd = xstrdup(args->argv[0]);
+ cdata->cmd = shellcmd;
cdata->wp_id = wp->id;
-
cdata->ctx = ctx;
cmd_ref_ctx(ctx);
job_run(shellcmd, cmd_run_shell_callback, cmd_run_shell_free, cdata);
+ format_free(ft);
return (CMD_RETURN_YIELD); /* don't let client exit */
}
diff --git a/tmux.1 b/tmux.1
index 882a71f..d01a150 100644
--- a/tmux.1
+++ b/tmux.1
@@ -3476,7 +3476,10 @@ if
.Ar shell-command
returns success or the second
.Ar command
-otherwise.
+otherwise. Before being executed, shell-command is expanded using the rules
+specified in the
+.Sx FORMATS
+section.
.It Ic lock-server
.D1 (alias: Ic lock )
Lock each client individually by running the command specified by the
@@ -3489,7 +3492,10 @@ option.
.D1 (alias: Ic run )
Execute
.Ar shell-command
-in the background without creating a window.
+in the background without creating a window. Before being executed,
+shell-command is expanded using the rules specified in the
+.Sx FORMATS
+section.
After it finishes, any output to stdout is displayed in copy mode (in the pane
specified by
.Fl t
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb___
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: [PATCH] Expand variables in the run-shell command string
Applied with some minor tweaks, and changed to add -t to if-shell
too. Thanks.
On Sat, Feb 23, 2013 at 03:29:55PM -0300, Thiago Padilha wrote:
> Ok here is the updated patch
>
> ---
> cmd-if-shell.c | 20 ++--
> cmd-run-shell.c | 18 ++
> tmux.1 | 10 --
> 3 files changed, 40 insertions(+), 8 deletions(-)
> diff --git a/cmd-if-shell.c b/cmd-if-shell.c
> index 6f0b151..011974f 100644
> --- a/cmd-if-shell.c
> +++ b/cmd-if-shell.c
> @@ -55,7 +55,21 @@ cmd_if_shell_exec(struct cmd *self, struct cmd_ctx *ctx)
> {
> struct args *args = self->args;
> struct cmd_if_shell_data*cdata;
> - const char *shellcmd = args->argv[0];
> + const char *shellcmd;
> + struct session *s;
> + struct winlink *wl;
> + struct window_pane *wp;
> + struct format_tree *ft;
> +
> + wl = cmd_find_pane(ctx, NULL, &s, &wp);
> + if (wl == NULL)
> + return (CMD_RETURN_ERROR);
> +
> + ft = format_create();
> + format_session(ft, s);
> + format_winlink(ft, s, wl);
> + format_window_pane(ft, wp);
> + shellcmd = format_expand(ft, args->argv[0]);
>
> cdata = xmalloc(sizeof *cdata);
> cdata->cmd_if = xstrdup(args->argv[1]);
> @@ -68,7 +82,9 @@ cmd_if_shell_exec(struct cmd *self, struct cmd_ctx *ctx)
> cmd_ref_ctx(ctx);
>
> job_run(shellcmd, cmd_if_shell_callback, cmd_if_shell_free, cdata);
> -
> + format_free(ft);
> + free(shellcmd);
> +
> return (CMD_RETURN_YIELD); /* don't let client exit */
> }
>
> diff --git a/cmd-run-shell.c b/cmd-run-shell.c
> index 9b4c006..69423e5 100644
> --- a/cmd-run-shell.c
> +++ b/cmd-run-shell.c
> @@ -75,20 +75,30 @@ cmd_run_shell_exec(struct cmd *self, struct cmd_ctx *ctx)
> {
> struct args *args = self->args;
> struct cmd_run_shell_data *cdata;
> - const char *shellcmd = args->argv[0];
> + const char *shellcmd;
> + struct session *s;
> + struct winlink *wl;
> struct window_pane *wp;
> + struct format_tree *ft;
>
> - if (cmd_find_pane(ctx, args_get(args, 't'), NULL, &wp) == NULL)
> + wl = cmd_find_pane(ctx, args_get(args, 't'), &s, &wp);
> + if (wl == NULL)
> return (CMD_RETURN_ERROR);
>
> + ft = format_create();
> + format_session(ft, s);
> + format_winlink(ft, s, wl);
> + format_window_pane(ft, wp);
> + shellcmd = format_expand(ft, args->argv[0]);
> +
> cdata = xmalloc(sizeof *cdata);
> - cdata->cmd = xstrdup(args->argv[0]);
> + cdata->cmd = shellcmd;
> cdata->wp_id = wp->id;
> -
> cdata->ctx = ctx;
> cmd_ref_ctx(ctx);
>
> job_run(shellcmd, cmd_run_shell_callback, cmd_run_shell_free, cdata);
> + format_free(ft);
>
> return (CMD_RETURN_YIELD); /* don't let client exit */
> }
> diff --git a/tmux.1 b/tmux.1
> index 882a71f..d01a150 100644
> --- a/tmux.1
> +++ b/tmux.1
> @@ -3476,7 +3476,10 @@ if
> .Ar shell-command
> returns success or the second
> .Ar command
> -otherwise.
> +otherwise. Before being executed, shell-command is expanded using the rules
> +specified in the
> +.Sx FORMATS
> +section.
> .It Ic lock-server
> .D1 (alias: Ic lock )
> Lock each client individually by running the command specified by the
> @@ -3489,7 +3492,10 @@ option.
> .D1 (alias: Ic run )
> Execute
> .Ar shell-command
> -in the background without creating a window.
> +in the background without creating a window. Before being executed,
> +shell-command is expanded using the rules specified in the
> +.Sx FORMATS
> +section.
> After it finishes, any output to stdout is displayed in copy mode (in the
> pane
> specified by
> .Fl t
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: Implementing some extra features
I have started to read the source code and began to wonder if those
features are possible to implement.
I'm assuming that a overview(very high level) of what happens when a tmux
command is executed is:
1- user types 'tmux somecmd' in a shell running inside a tmux session,
which opens 'tmux program'
2- tmux program opens a connection with the server
3- tmux program sends 'somecmd' through the connection fd and wait for a
response
4- tmux server processes the command, sending every output to the
connection fd, which tmux program forwards to stdout(which I assume is the
tmux client)
5- tmux server closes the connection fd
6- tmux program detects EOF and returns.
Since tmux is libevent based, to implement the semaphore/lock mechanisms
described, I would need to block the tmux program from returning, which
would require me to push the connection fd to some list or queue and only
close it at a later time.
Is something like this possible to do inside a normal tmux command? If so
can you give me some hints?
Thanks
On Fri, Feb 22, 2013 at 8:16 PM, Nicholas Marriott <
nicholas.marri...@gmail.com> wrote:
> No don't need any other changes thanks
>
>
> On Fri, Feb 22, 2013 at 07:14:30PM -0300, Thiago Padilha wrote:
> > Ok by me, I was just following the existing code :)
> >
> > So the patch is good to merge? Need me to do any other modifications?
> >
> > On Fri, Feb 22, 2013 at 6:50 PM, Nicholas Marriott
> > wrote:
> > > On Fri, Feb 22, 2013 at 06:34:14PM -0300, Thiago Padilha wrote:
> > >> I had forgotten to update the man pages to reflect the nem flag, this
> > >> patch contains the complete thing.
> > >
> > > I think this is a bit more pithy, don't see a need to info() the old
> > > value.
> > >
> > >
> > > diff --git a/cmd-set-option.c b/cmd-set-option.c
> > > index a09e6db..94b44c7 100644
> > > --- a/cmd-set-option.c
> > > +++ b/cmd-set-option.c
> > > @@ -63,8 +63,8 @@ struct options_entry *cmd_set_option_choice(struct
> cmd *, struct cmd_ctx *,
> > >
> > > const struct cmd_entry cmd_set_option_entry = {
> > > "set-option", "set",
> > > - "agqst:uw", 1, 2,
> > > - "[-agsquw] [-t target-session|target-window] option [value]",
> > > + "agoqst:uw", 1, 2,
> > > + "[-agosquw] [-t target-session|target-window] option [value]",
> > > 0,
> > > NULL,
> > > NULL,
> > > @@ -73,8 +73,8 @@ const struct cmd_entry cmd_set_option_entry = {
> > >
> > > const struct cmd_entry cmd_set_window_option_entry = {
> > > "set-window-option", "setw",
> > > - "agqt:u", 1, 2,
> > > - "[-agqu] " CMD_TARGET_WINDOW_USAGE " option [value]",
> > > + "agoqt:u", 1, 2,
> > > + "[-agoqu] " CMD_TARGET_WINDOW_USAGE " option [value]",
> > > 0,
> > > NULL,
> > > NULL,
> > > @@ -151,6 +151,11 @@ cmd_set_option_exec(struct cmd *self, struct
> cmd_ctx *ctx)
> > > if (cmd_set_option_unset(self, ctx, oe, oo, valstr) !=
> 0)
> > > return (CMD_RETURN_ERROR);
> > > } else {
> > > + if (args_has(args, 'o') && options_find1(oo, optstr)
> != NULL) {
> > > + if (!args_has(args, 'q'))
> > > + ctx->print(ctx, "already set: %s",
> optstr);
> > > + return (CMD_RETURN_NORMAL);
> > > + }
> > > if (cmd_set_option_set(self, ctx, oe, oo, valstr) != 0)
> > > return (CMD_RETURN_ERROR);
> > > }
> > > @@ -227,6 +232,11 @@ cmd_set_option_user(struct cmd *self, struct
> cmd_ctx *ctx, const char* optstr,
> > > ctx->error(ctx, "empty value");
> > > return (CMD_RETURN_ERROR);
> > > }
> > > + if (args_has(args, 'o') && options_find1(oo, optstr)
> != NULL) {
> > > + if (!args_has(args, 'q'))
> > > + ctx->print(ctx, "already set: %s",
> optstr);
> > > + return (CMD_RETURN_NORMAL);
> > > + }
> > > options_set_string(oo, optstr, "%s", valstr);
> > > if (!args_has(args, 'q'))
> > > ctx->info(ctx, "set option: %s -> %s", optstr,
> valstr);
> > > diff --git a/tmux.1 b/tmux.1
> > > index 475bac0..0b2892a 100644
> > > --- a/tmux.1
> > > +++ b/tmux.1
> > > @@ -1996,7 +1996,7 @@ abc123
> > > Commands which set options are as follows:
> > > .Bl -tag -width Ds
> > > .It Xo Ic set-option
> > > -.Op Fl agqsuw
> > > +.Op Fl agoqsuw
> > > .Op Fl t Ar target-session | Ar target-window
> > > .Ar option Ar value
> > > .Xc
> > > @@ -2025,6 +2025,10 @@ options.
> > > It is not possible to unset a global option.
> > > .Pp
> > > The
> > > +.Fl o
> > > +flag prevents setting an option that is already set.
> > > +.Pp
> > > +The
> > > .Fl q
> > > flag suppresses the informational message (as if the
> > > .Ic quiet
> > >
> > >
>
---
Re: Implementing some extra features
On Sat, Feb 23, 2013 at 06:24:56PM -0300, Thiago Padilha wrote:
>I have started to read the source code and began to wonder if those
>features are possible to implement.
>I'm assuming that a overview(very high level) of what happens when a tmux
>command is executed is:
Yes this is correct, except for attach-client or new-session.
>1- user types 'tmux somecmd' in a shell running inside a tmux session,
>which opens 'tmux program'
>2- tmux program opens a connection with the server
>3- tmux program sends 'somecmd' through the connection fd and wait for a
>response
>4- tmux server processes the command, sending every output to the
>connection fd, which tmux program forwards to stdout(which I assume is the
>tmux client)
>5- tmux server closes the connection fd**
Not quite, there is a client exit protocol, it is not just a close. But
that isn't important.
>6- tmux program detects EOF and returns.
>Since tmux is libevent based, to implement the semaphore/lock mechanisms
>described, I would need to block the tmux program from returning, which
>would require me to push the connection fd to some list or queue and only
>close it at a later time.
The client will not exit until it is told to, it will just sit on the
tty. What you do currently for a command-line client is return
CMD_RETURN_YIELD from your command exec function and then set the
CLIENT_EXIT bit in the flags when you are done. Take a look at
cmd-run-shell.c.
This will change shortly when I commit my command queue changes but I
suggest you not worry about that for now - just work on the current
system, it won't be hard to convert later.
>Is something like this possible to do inside a normal tmux command? If so
>can you give me some hints?
I would say you need to do this for waiting:
- Define a global tree of wait ids keyed by string, each one will need a
queue of clients. Use the tree.h RB tree and queue.h TAILQ (so eg add
a TAILQ_ENTRY waitqentry to struct client).
- In your new command's exec function make sure cmdclient is non-NULL,
if not you are inside tmux or in the config file and you can't do this
at the moment so make it an error.
- Add your client to the queue for the wait id and return
CMD_RETURN_YIELD. Don't forget to increase the client reference count
(c->references).
Then for the wakeup:
- Lookup the wait id in the tree.
- Walk the list of waiters, set their CLIENT_EXIT flag and reduce the
reference count.
- Free all the bits that aren't needed now and return CMD_RETURN_NORMAL.
With the current code this will NOT block execution of further commands
in a command sequence - this is impossible until I commit my changes. So
don't expect this to work:
tmux wait foo\; lsk
But this will:
tmux wait foo
tmux lsk
I'm not sure if I will commit my new code before I go but if I do the
idea will be very similar except instead of putting the client on the
list you will put the struct cmdq on there (and increase it's reference
but not the client's), instead of YIELD you will return WAIT and instead
of doing references-- and setting CLIENT_EXIT flag you will do
if(!cmdq_free(cmdq)) cmdq_continue(cmdq).
If you have any questions make them before about 0900 GMT tomorrow or I
will be gone until next Sunday :-).
>Thanks
>On Fri, Feb 22, 2013 at 8:16 PM, Nicholas Marriott
><[1]nicholas.marri...@gmail.com> wrote:
>
> No don't need any other changes thanks
>
> On Fri, Feb 22, 2013 at 07:14:30PM -0300, Thiago Padilha wrote:
> > Ok by me, I was just **following the existing code :)
> >
> > So the patch is good to merge? Need me to do any other modifications?
> >
> > On Fri, Feb 22, 2013 at 6:50 PM, Nicholas Marriott
> > <[2]nicholas.marri...@gmail.com> wrote:
> > > On Fri, Feb 22, 2013 at 06:34:14PM -0300, Thiago Padilha wrote:
> > >> I had forgotten to update the man pages to reflect the nem flag,
> this
> > >> patch contains the complete thing.
> > >
> > > I think this is a bit more pithy, don't see a need to info() the old
> > > value.
> > >
> > >
> > > diff --git a/cmd-set-option.c b/cmd-set-option.c
> > > index a09e6db..94b44c7 100644
> > > --- a/cmd-set-option.c
> > > +++ b/cmd-set-option.c
> > > @@ -63,8 +63,8 @@ struct options_entry *cmd_set_option_choice(struct
> cmd *, struct cmd_ctx *,
> > >
> > > **const struct cmd_entry cmd_set_option_entry = {
> > > ** ** ** ** "set-option", "set",
> > > - ** ** ** "agqst:uw", 1, 2,
> > > - ** ** ** "[-agsquw] [-t target-session|target-window] option
> [value]",
> > > + ** ** ** "agoqst:uw", 1, 2,
> > > + ** ** ** "[-agosquw] [-t target-session|target-window] option
> [value]",
> > > ** ** ** ** 0,
> > > ** ** ** ** NULL,
> > > ** ** ** ** NULL,
> > > @@ -73,8 +73,8 @@ const struct cmd_entry cmd_set_option_entry = {
Re: Implementing some extra features
I've committed my cmdq changes after all so you will need to do it that way at some point, the differences aren't substantial - basically what I outlined below, save and reference the cmdq rather than the client and wake it up with cmdq_free/cmdq_continue. If you look at run-shell it should be clear enough. On Sat, Feb 23, 2013 at 09:55:43PM +, Nicholas Marriott wrote: > On Sat, Feb 23, 2013 at 06:24:56PM -0300, Thiago Padilha wrote: > >I have started to read the source code and began to wonder if those > >features are possible to implement. > >I'm assuming that a overview(very high level) of what happens when a tmux > >command is executed is: > > Yes this is correct, except for attach-client or new-session. > > >1- user types 'tmux somecmd' in a shell running inside a tmux session, > >which opens 'tmux program' > >2- tmux program opens a connection with the server > >3- tmux program sends 'somecmd' through the connection fd and wait for a > >response > >4- tmux server processes the command, sending every output to the > >connection fd, which tmux program forwards to stdout(which I assume is > > the > >tmux client) > >5- tmux server closes the connection fd** > > Not quite, there is a client exit protocol, it is not just a close. But > that isn't important. > > >6- tmux program detects EOF and returns. > >Since tmux is libevent based, to implement the semaphore/lock mechanisms > >described, I would need to block the tmux program from returning, which > >would require me to push the connection fd to some list or queue and only > >close it at a later time. > > The client will not exit until it is told to, it will just sit on the > tty. What you do currently for a command-line client is return > CMD_RETURN_YIELD from your command exec function and then set the > CLIENT_EXIT bit in the flags when you are done. Take a look at > cmd-run-shell.c. > > This will change shortly when I commit my command queue changes but I > suggest you not worry about that for now - just work on the current > system, it won't be hard to convert later. > > >Is something like this possible to do inside a normal tmux command? If so > >can you give me some hints? > > I would say you need to do this for waiting: > > - Define a global tree of wait ids keyed by string, each one will need a > queue of clients. Use the tree.h RB tree and queue.h TAILQ (so eg add > a TAILQ_ENTRY waitqentry to struct client). > > - In your new command's exec function make sure cmdclient is non-NULL, > if not you are inside tmux or in the config file and you can't do this > at the moment so make it an error. > > - Add your client to the queue for the wait id and return > CMD_RETURN_YIELD. Don't forget to increase the client reference count > (c->references). > > Then for the wakeup: > > - Lookup the wait id in the tree. > > - Walk the list of waiters, set their CLIENT_EXIT flag and reduce the > reference count. > > - Free all the bits that aren't needed now and return CMD_RETURN_NORMAL. > > With the current code this will NOT block execution of further commands > in a command sequence - this is impossible until I commit my changes. So > don't expect this to work: > > tmux wait foo\; lsk > > But this will: > > tmux wait foo > tmux lsk > > I'm not sure if I will commit my new code before I go but if I do the > idea will be very similar except instead of putting the client on the > list you will put the struct cmdq on there (and increase it's reference > but not the client's), instead of YIELD you will return WAIT and instead > of doing references-- and setting CLIENT_EXIT flag you will do > if(!cmdq_free(cmdq)) cmdq_continue(cmdq). > > If you have any questions make them before about 0900 GMT tomorrow or I > will be gone until next Sunday :-). > > >Thanks > >On Fri, Feb 22, 2013 at 8:16 PM, Nicholas Marriott > ><[1]nicholas.marri...@gmail.com> wrote: > > > > No don't need any other changes thanks > > > > On Fri, Feb 22, 2013 at 07:14:30PM -0300, Thiago Padilha wrote: > > > Ok by me, I was just **following the existing code :) > > > > > > So the patch is good to merge? Need me to do any other modifications? > > > > > > On Fri, Feb 22, 2013 at 6:50 PM, Nicholas Marriott > > > <[2]nicholas.marri...@gmail.com> wrote: > > > > On Fri, Feb 22, 2013 at 06:34:14PM -0300, Thiago Padilha wrote: > > > >> I had forgotten to update the man pages to reflect the nem flag, > > this > > > >> patch contains the complete thing. > > > > > > > > I think this is a bit more pithy, don't see a need to info() the > > old > > > > value. > > > > > > > > > > > > diff --git a/cmd-set-option.c b/cmd-set-option.c > > > > index a09e6db..94b44c7 100644 > > > > --- a/cmd-set-option.c > > > > +++ b/cmd-set-option.c > > > > @@ -63,8 +63,8 @@ struct options
Re: Implementing some extra features
Ok thanks for the info. I just got home now and will go sleep, and when I wake up you will probably be gone already, so I will see what I can do and next sunday you give feedback. Until then On Sat, Feb 23, 2013 at 7:45 PM, Nicholas Marriott < nicholas.marri...@gmail.com> wrote: > I've committed my cmdq changes after all so you will need to do it that > way at some point, the differences aren't substantial - basically what I > outlined below, save and reference the cmdq rather than the client and > wake it up with cmdq_free/cmdq_continue. If you look at run-shell it > should be clear enough. > > > On Sat, Feb 23, 2013 at 09:55:43PM +, Nicholas Marriott wrote: > > On Sat, Feb 23, 2013 at 06:24:56PM -0300, Thiago Padilha wrote: > > >I have started to read the source code and began to wonder if those > > >features are possible to implement. > > >I'm assuming that a overview(very high level) of what happens when > a tmux > > >command is executed is: > > > > Yes this is correct, except for attach-client or new-session. > > > > >1- user types 'tmux somecmd' in a shell running inside a tmux > session, > > >which opens 'tmux program' > > >2- tmux program opens a connection with the server > > >3- tmux program sends 'somecmd' through the connection fd and wait > for a > > >response > > >4- tmux server processes the command, sending every output to the > > >connection fd, which tmux program forwards to stdout(which I assume > is the > > >tmux client) > > >5- tmux server closes the connection fd** > > > > Not quite, there is a client exit protocol, it is not just a close. But > > that isn't important. > > > > >6- tmux program detects EOF and returns. > > >Since tmux is libevent based, to implement the semaphore/lock > mechanisms > > >described, I would need to block the tmux program from returning, > which > > >would require me to push the connection fd to some list or queue > and only > > >close it at a later time. > > > > The client will not exit until it is told to, it will just sit on the > > tty. What you do currently for a command-line client is return > > CMD_RETURN_YIELD from your command exec function and then set the > > CLIENT_EXIT bit in the flags when you are done. Take a look at > > cmd-run-shell.c. > > > > This will change shortly when I commit my command queue changes but I > > suggest you not worry about that for now - just work on the current > > system, it won't be hard to convert later. > > > > >Is something like this possible to do inside a normal tmux command? > If so > > >can you give me some hints? > > > > I would say you need to do this for waiting: > > > > - Define a global tree of wait ids keyed by string, each one will need a > > queue of clients. Use the tree.h RB tree and queue.h TAILQ (so eg add > > a TAILQ_ENTRY waitqentry to struct client). > > > > - In your new command's exec function make sure cmdclient is non-NULL, > > if not you are inside tmux or in the config file and you can't do this > > at the moment so make it an error. > > > > - Add your client to the queue for the wait id and return > > CMD_RETURN_YIELD. Don't forget to increase the client reference count > > (c->references). > > > > Then for the wakeup: > > > > - Lookup the wait id in the tree. > > > > - Walk the list of waiters, set their CLIENT_EXIT flag and reduce the > > reference count. > > > > - Free all the bits that aren't needed now and return CMD_RETURN_NORMAL. > > > > With the current code this will NOT block execution of further commands > > in a command sequence - this is impossible until I commit my changes. So > > don't expect this to work: > > > > tmux wait foo\; lsk > > > > But this will: > > > > tmux wait foo > > tmux lsk > > > > I'm not sure if I will commit my new code before I go but if I do the > > idea will be very similar except instead of putting the client on the > > list you will put the struct cmdq on there (and increase it's reference > > but not the client's), instead of YIELD you will return WAIT and instead > > of doing references-- and setting CLIENT_EXIT flag you will do > > if(!cmdq_free(cmdq)) cmdq_continue(cmdq). > > > > If you have any questions make them before about 0900 GMT tomorrow or I > > will be gone until next Sunday :-). > > > > >Thanks > > >On Fri, Feb 22, 2013 at 8:16 PM, Nicholas Marriott > > ><[1]nicholas.marri...@gmail.com> wrote: > > > > > > No don't need any other changes thanks > > > > > > On Fri, Feb 22, 2013 at 07:14:30PM -0300, Thiago Padilha wrote: > > > > Ok by me, I was just **following the existing code :) > > > > > > > > So the patch is good to merge? Need me to do any other > modifications? > > > > > > > > On Fri, Feb 22, 2013 at 6:50 PM, Nicholas Marriott > > > > <[2]nicholas.marri...@gmail.com> wrote: > > > > > On Fri, Feb 22, 2013 at 06:34:14PM -0300, Thiago Padilha > wrote: > > > > >> I had for
