Re: Expanding Control Mode

[Nicholas Marriott]

Great, applied to OpenBSD now, will be in GitHub next time it syncs up.



On Wed, May 03, 2017 at 04:51:29PM -0500, Joshua Brot wrote:
> Ok. That's good enough for my purposes.
> 
> > On May 3, 2017, at 16:20, Nicholas Marriott  
> > wrote:
> > 
> > They are unique in that you can only have one client with that name at a
> > time, but (like the PID) they are not unique through the lifetime of the
> > tmux process.
> > 
> > 
> >> On Wed, May 03, 2017 at 12:56:04PM -0500, Joshua Brot wrote:
> >> As long as the name is guaranteed to be unique, that shouldn't pose any 
> >> problems for me.
> >> 
> >>> On May 3, 2017, at 04:54, Nicholas Marriott  
> >>> wrote:
> >>> 
> >>> Looks good, but I think we should use c->name for
> >>> %%client-session-changed not the PID. Does that change anything for your
> >>> use?
> >>> 
> >>> 
> >>> 
>  On Wed, May 03, 2017 at 02:22:24AM -0500, Joshua Brot wrote:
>  No problem.
>  
> > On 5/3/17, Nicholas Marriott  wrote:
> > Can you send me everything together please?
> > 
> > 
> >> On Wed, May 03, 2017 at 01:14:09AM -0500, Joshua Brot wrote:
> >> I've now implemented the client-session-changed control mode hook per
> >> our discussion. Furthermore, I discovered that client-session-changed
> >> was not being sent during the switch client command which explains why
> >> it was not firing enough earlier. My patch corrects this behavior. I
> >> then proceeded to grep the entire source for "session = " and can say
> >> with relative confidence that at every other place where the session
> >> gets changed, the client-session-changed notification is properly
> >> sent.
> >> 
> >> I've attached a separate patch from last time. Let me know if you'd
> >> prefer to have one patch with both changes. Also let me know if
> >> there's anything else that needs changing in the patch. All together,
> >> with these two patches I'm very satisfied with the data provided by
> >> control mode and I believe I should be able to complete my project as
> >> planned. :)
> >> 
> >> Thanks,
> >> Joshua
> >> 
> >>> On 5/2/17, Nicholas Marriott  wrote:
> >>> I think all sessions windows panes is OK, at the moment only input is
> >>> filtered by the control client's session (because it is high volume).
> >>> 
> >>> pane-mode-changed it would be nice if it showed the mode but TBH it is
> >>> probably not worth the trouble if doing ls/lsp/whatever is fine (can
> >>> add
> >>> a format to show the name of the mode if needed).
> >>> 
> >>> For client-session-changed I suggest splitting it into
> >>> %%session-changed
> >>> (for this client's session like now) and %%client-session-changed (for
> >>> another client's session). You'll need to loop over all clients and
> >>> choose which one to use, like it does for window-renamed etc.
> >>> 
> >>> 
> >>> 
> >>> 
>  On Tue, May 02, 2017 at 08:37:16PM -0500, Joshua Brot wrote:
>  Thanks for the pointers. Based off of what you said, I've created a
>  patch which implements the features I mentioned. Two things I'm not
>  sure about: 1) it seems like the control mode client will receive
>  these notifications for all sessions/windows/panes, as opposed to
>  notifications for the current session only. Should I revise the patch
>  to add in filtes for this? 2) For the pane-mode-changed notification,
>  it looks like I only get the pane-id which means the notification
>  doesn't report much and I'll probably have to perform a list-panes
>  query in response to get more information. Neither of these issues
>  seem very problematic, though, so perhaps its best to just leave the
>  patch as it is.
>  
>  With regards to the client_session_changed callback, what I'd like is
>  to have a notification for when any client changes sessions (not just
>  the one running Control Mode). I thought that client_session_changed
>  was called every time a client changed sessions, but in testing this
>  appears not to be the case (I'm not even quite sure when it does get
>  called). Should this be a new control mode notification like the ones
>  I just implemented, or should this be handled in a different way?
>  
>  Thanks,
>  Joshua
>  
> > On 5/2/17, Nicholas Marriott  wrote:
> > Hi
> > 
> > What have you got so far?
> > 
> > Control mode should already get updated for client-session-changed,
> > if
> > you look at notify.c:notify_callback there is already a check that
> > passes it into 

Re: Expanding Control Mode

[Nicholas Marriott]

Looks good, but I think we should use c->name for
%%client-session-changed not the PID. Does that change anything for your
use?



On Wed, May 03, 2017 at 02:22:24AM -0500, Joshua Brot wrote:
> No problem.
> 
> On 5/3/17, Nicholas Marriott  wrote:
> > Can you send me everything together please?
> >
> >
> > On Wed, May 03, 2017 at 01:14:09AM -0500, Joshua Brot wrote:
> >> I've now implemented the client-session-changed control mode hook per
> >> our discussion. Furthermore, I discovered that client-session-changed
> >> was not being sent during the switch client command which explains why
> >> it was not firing enough earlier. My patch corrects this behavior. I
> >> then proceeded to grep the entire source for "session = " and can say
> >> with relative confidence that at every other place where the session
> >> gets changed, the client-session-changed notification is properly
> >> sent.
> >>
> >> I've attached a separate patch from last time. Let me know if you'd
> >> prefer to have one patch with both changes. Also let me know if
> >> there's anything else that needs changing in the patch. All together,
> >> with these two patches I'm very satisfied with the data provided by
> >> control mode and I believe I should be able to complete my project as
> >> planned. :)
> >>
> >> Thanks,
> >> Joshua
> >>
> >> On 5/2/17, Nicholas Marriott  wrote:
> >> > I think all sessions windows panes is OK, at the moment only input is
> >> > filtered by the control client's session (because it is high volume).
> >> >
> >> > pane-mode-changed it would be nice if it showed the mode but TBH it is
> >> > probably not worth the trouble if doing ls/lsp/whatever is fine (can
> >> > add
> >> > a format to show the name of the mode if needed).
> >> >
> >> > For client-session-changed I suggest splitting it into
> >> > %%session-changed
> >> > (for this client's session like now) and %%client-session-changed (for
> >> > another client's session). You'll need to loop over all clients and
> >> > choose which one to use, like it does for window-renamed etc.
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, May 02, 2017 at 08:37:16PM -0500, Joshua Brot wrote:
> >> >> Thanks for the pointers. Based off of what you said, I've created a
> >> >> patch which implements the features I mentioned. Two things I'm not
> >> >> sure about: 1) it seems like the control mode client will receive
> >> >> these notifications for all sessions/windows/panes, as opposed to
> >> >> notifications for the current session only. Should I revise the patch
> >> >> to add in filtes for this? 2) For the pane-mode-changed notification,
> >> >> it looks like I only get the pane-id which means the notification
> >> >> doesn't report much and I'll probably have to perform a list-panes
> >> >> query in response to get more information. Neither of these issues
> >> >> seem very problematic, though, so perhaps its best to just leave the
> >> >> patch as it is.
> >> >>
> >> >> With regards to the client_session_changed callback, what I'd like is
> >> >> to have a notification for when any client changes sessions (not just
> >> >> the one running Control Mode). I thought that client_session_changed
> >> >> was called every time a client changed sessions, but in testing this
> >> >> appears not to be the case (I'm not even quite sure when it does get
> >> >> called). Should this be a new control mode notification like the ones
> >> >> I just implemented, or should this be handled in a different way?
> >> >>
> >> >> Thanks,
> >> >> Joshua
> >> >>
> >> >> On 5/2/17, Nicholas Marriott  wrote:
> >> >> > Hi
> >> >> >
> >> >> > What have you got so far?
> >> >> >
> >> >> > Control mode should already get updated for client-session-changed,
> >> >> > if
> >> >> > you look at notify.c:notify_callback there is already a check that
> >> >> > passes it into control_notify_client_session_changed.
> >> >> >
> >> >> > For new ones you will need to add a notify_add call somewhere and
> >> >> > then
> >> >> > add a control-notify.c function and a check in notify_callback, for
> >> >> > active pane it'll probably need a notify_add call in
> >> >> > window.c:window_set_active_pane.
> >> >> >
> >> >> > Mode changes you can do in window_pane_set_mode and
> >> >> > window_pane_reset_mode.
> >> >> >
> >> >> >
> >> >> > On Tue, May 02, 2017 at 02:27:57AM -0500, Joshua Brot wrote:
> >> >> >> Hi!
> >> >> >>
> >> >> >> I???m currently in the process of writing a Wayland Compositor with
> >> >> >> the
> >> >> >> goal of using tmux as a tiling window manager. Basically, the
> >> >> >> compositor
> >> >> >> provides an interface similar to the TTY with tmux running. When
> >> >> >> the
> >> >> >> user
> >> >> >> launches a visual application, the compositor will then overlay it
> >> >> >> on
> >> >> >> the
> >> >> >> pane from which it was launched. My current strategy for
> >> >> >> implementing
> >> >> >> this
> >> >> >> 

Re: Expanding Control Mode

[Nicholas Marriott]

Can you send me everything together please?


On Wed, May 03, 2017 at 01:14:09AM -0500, Joshua Brot wrote:
> I've now implemented the client-session-changed control mode hook per
> our discussion. Furthermore, I discovered that client-session-changed
> was not being sent during the switch client command which explains why
> it was not firing enough earlier. My patch corrects this behavior. I
> then proceeded to grep the entire source for "session = " and can say
> with relative confidence that at every other place where the session
> gets changed, the client-session-changed notification is properly
> sent.
> 
> I've attached a separate patch from last time. Let me know if you'd
> prefer to have one patch with both changes. Also let me know if
> there's anything else that needs changing in the patch. All together,
> with these two patches I'm very satisfied with the data provided by
> control mode and I believe I should be able to complete my project as
> planned. :)
> 
> Thanks,
> Joshua
> 
> On 5/2/17, Nicholas Marriott  wrote:
> > I think all sessions windows panes is OK, at the moment only input is
> > filtered by the control client's session (because it is high volume).
> >
> > pane-mode-changed it would be nice if it showed the mode but TBH it is
> > probably not worth the trouble if doing ls/lsp/whatever is fine (can add
> > a format to show the name of the mode if needed).
> >
> > For client-session-changed I suggest splitting it into %%session-changed
> > (for this client's session like now) and %%client-session-changed (for
> > another client's session). You'll need to loop over all clients and
> > choose which one to use, like it does for window-renamed etc.
> >
> >
> >
> >
> > On Tue, May 02, 2017 at 08:37:16PM -0500, Joshua Brot wrote:
> >> Thanks for the pointers. Based off of what you said, I've created a
> >> patch which implements the features I mentioned. Two things I'm not
> >> sure about: 1) it seems like the control mode client will receive
> >> these notifications for all sessions/windows/panes, as opposed to
> >> notifications for the current session only. Should I revise the patch
> >> to add in filtes for this? 2) For the pane-mode-changed notification,
> >> it looks like I only get the pane-id which means the notification
> >> doesn't report much and I'll probably have to perform a list-panes
> >> query in response to get more information. Neither of these issues
> >> seem very problematic, though, so perhaps its best to just leave the
> >> patch as it is.
> >>
> >> With regards to the client_session_changed callback, what I'd like is
> >> to have a notification for when any client changes sessions (not just
> >> the one running Control Mode). I thought that client_session_changed
> >> was called every time a client changed sessions, but in testing this
> >> appears not to be the case (I'm not even quite sure when it does get
> >> called). Should this be a new control mode notification like the ones
> >> I just implemented, or should this be handled in a different way?
> >>
> >> Thanks,
> >> Joshua
> >>
> >> On 5/2/17, Nicholas Marriott  wrote:
> >> > Hi
> >> >
> >> > What have you got so far?
> >> >
> >> > Control mode should already get updated for client-session-changed, if
> >> > you look at notify.c:notify_callback there is already a check that
> >> > passes it into control_notify_client_session_changed.
> >> >
> >> > For new ones you will need to add a notify_add call somewhere and then
> >> > add a control-notify.c function and a check in notify_callback, for
> >> > active pane it'll probably need a notify_add call in
> >> > window.c:window_set_active_pane.
> >> >
> >> > Mode changes you can do in window_pane_set_mode and
> >> > window_pane_reset_mode.
> >> >
> >> >
> >> > On Tue, May 02, 2017 at 02:27:57AM -0500, Joshua Brot wrote:
> >> >> Hi!
> >> >>
> >> >> I???m currently in the process of writing a Wayland Compositor with
> >> >> the
> >> >> goal of using tmux as a tiling window manager. Basically, the
> >> >> compositor
> >> >> provides an interface similar to the TTY with tmux running. When the
> >> >> user
> >> >> launches a visual application, the compositor will then overlay it on
> >> >> the
> >> >> pane from which it was launched. My current strategy for implementing
> >> >> this
> >> >> is to launch an internal tmux client in control mode to every session
> >> >> on
> >> >> the server in order to track what actions the client is taking and
> >> >> respond
> >> >> accordingly.
> >> >>
> >> >> In its current state, tmux???s control mode looks like it provides
> >> >> almost
> >> >> enough capabilities to make this project work. The biggest thing it is
> >> >> missing are notifications for when the user switches active panes
> >> >> within a
> >> >> window and when the user switches active windows in a session. It
> >> >> would
> >> >> also be nice to have a notification for when the user switches into
> >> 

Re: Expanding Control Mode

[Joshua Brot]

I've now implemented the client-session-changed control mode hook per
our discussion. Furthermore, I discovered that client-session-changed
was not being sent during the switch client command which explains why
it was not firing enough earlier. My patch corrects this behavior. I
then proceeded to grep the entire source for "session = " and can say
with relative confidence that at every other place where the session
gets changed, the client-session-changed notification is properly
sent.

I've attached a separate patch from last time. Let me know if you'd
prefer to have one patch with both changes. Also let me know if
there's anything else that needs changing in the patch. All together,
with these two patches I'm very satisfied with the data provided by
control mode and I believe I should be able to complete my project as
planned. :)

Thanks,
Joshua

On 5/2/17, Nicholas Marriott  wrote:
> I think all sessions windows panes is OK, at the moment only input is
> filtered by the control client's session (because it is high volume).
>
> pane-mode-changed it would be nice if it showed the mode but TBH it is
> probably not worth the trouble if doing ls/lsp/whatever is fine (can add
> a format to show the name of the mode if needed).
>
> For client-session-changed I suggest splitting it into %%session-changed
> (for this client's session like now) and %%client-session-changed (for
> another client's session). You'll need to loop over all clients and
> choose which one to use, like it does for window-renamed etc.
>
>
>
>
> On Tue, May 02, 2017 at 08:37:16PM -0500, Joshua Brot wrote:
>> Thanks for the pointers. Based off of what you said, I've created a
>> patch which implements the features I mentioned. Two things I'm not
>> sure about: 1) it seems like the control mode client will receive
>> these notifications for all sessions/windows/panes, as opposed to
>> notifications for the current session only. Should I revise the patch
>> to add in filtes for this? 2) For the pane-mode-changed notification,
>> it looks like I only get the pane-id which means the notification
>> doesn't report much and I'll probably have to perform a list-panes
>> query in response to get more information. Neither of these issues
>> seem very problematic, though, so perhaps its best to just leave the
>> patch as it is.
>>
>> With regards to the client_session_changed callback, what I'd like is
>> to have a notification for when any client changes sessions (not just
>> the one running Control Mode). I thought that client_session_changed
>> was called every time a client changed sessions, but in testing this
>> appears not to be the case (I'm not even quite sure when it does get
>> called). Should this be a new control mode notification like the ones
>> I just implemented, or should this be handled in a different way?
>>
>> Thanks,
>> Joshua
>>
>> On 5/2/17, Nicholas Marriott  wrote:
>> > Hi
>> >
>> > What have you got so far?
>> >
>> > Control mode should already get updated for client-session-changed, if
>> > you look at notify.c:notify_callback there is already a check that
>> > passes it into control_notify_client_session_changed.
>> >
>> > For new ones you will need to add a notify_add call somewhere and then
>> > add a control-notify.c function and a check in notify_callback, for
>> > active pane it'll probably need a notify_add call in
>> > window.c:window_set_active_pane.
>> >
>> > Mode changes you can do in window_pane_set_mode and
>> > window_pane_reset_mode.
>> >
>> >
>> > On Tue, May 02, 2017 at 02:27:57AM -0500, Joshua Brot wrote:
>> >> Hi!
>> >>
>> >> I???m currently in the process of writing a Wayland Compositor with
>> >> the
>> >> goal of using tmux as a tiling window manager. Basically, the
>> >> compositor
>> >> provides an interface similar to the TTY with tmux running. When the
>> >> user
>> >> launches a visual application, the compositor will then overlay it on
>> >> the
>> >> pane from which it was launched. My current strategy for implementing
>> >> this
>> >> is to launch an internal tmux client in control mode to every session
>> >> on
>> >> the server in order to track what actions the client is taking and
>> >> respond
>> >> accordingly.
>> >>
>> >> In its current state, tmux???s control mode looks like it provides
>> >> almost
>> >> enough capabilities to make this project work. The biggest thing it is
>> >> missing are notifications for when the user switches active panes
>> >> within a
>> >> window and when the user switches active windows in a session. It
>> >> would
>> >> also be nice to have a notification for when the user switches into
>> >> and
>> >> out of copy mode, but this isn???t essential. Finally, it would be nice
>> >> to
>> >> get notifications on the ???client-session-changed??? hook, but since
>> >> there is a hook already I can very easily work around this.
>> >>
>> >> I have begun to look through tmux???s source in order to implement

Re: Expanding Control Mode

[Nicholas Marriott]

I think all sessions windows panes is OK, at the moment only input is
filtered by the control client's session (because it is high volume).

pane-mode-changed it would be nice if it showed the mode but TBH it is
probably not worth the trouble if doing ls/lsp/whatever is fine (can add
a format to show the name of the mode if needed).

For client-session-changed I suggest splitting it into %%session-changed
(for this client's session like now) and %%client-session-changed (for
another client's session). You'll need to loop over all clients and
choose which one to use, like it does for window-renamed etc.




On Tue, May 02, 2017 at 08:37:16PM -0500, Joshua Brot wrote:
> Thanks for the pointers. Based off of what you said, I've created a
> patch which implements the features I mentioned. Two things I'm not
> sure about: 1) it seems like the control mode client will receive
> these notifications for all sessions/windows/panes, as opposed to
> notifications for the current session only. Should I revise the patch
> to add in filtes for this? 2) For the pane-mode-changed notification,
> it looks like I only get the pane-id which means the notification
> doesn't report much and I'll probably have to perform a list-panes
> query in response to get more information. Neither of these issues
> seem very problematic, though, so perhaps its best to just leave the
> patch as it is.
> 
> With regards to the client_session_changed callback, what I'd like is
> to have a notification for when any client changes sessions (not just
> the one running Control Mode). I thought that client_session_changed
> was called every time a client changed sessions, but in testing this
> appears not to be the case (I'm not even quite sure when it does get
> called). Should this be a new control mode notification like the ones
> I just implemented, or should this be handled in a different way?
> 
> Thanks,
> Joshua
> 
> On 5/2/17, Nicholas Marriott  wrote:
> > Hi
> >
> > What have you got so far?
> >
> > Control mode should already get updated for client-session-changed, if
> > you look at notify.c:notify_callback there is already a check that
> > passes it into control_notify_client_session_changed.
> >
> > For new ones you will need to add a notify_add call somewhere and then
> > add a control-notify.c function and a check in notify_callback, for
> > active pane it'll probably need a notify_add call in
> > window.c:window_set_active_pane.
> >
> > Mode changes you can do in window_pane_set_mode and
> > window_pane_reset_mode.
> >
> >
> > On Tue, May 02, 2017 at 02:27:57AM -0500, Joshua Brot wrote:
> >> Hi!
> >>
> >> I???m currently in the process of writing a Wayland Compositor with the
> >> goal of using tmux as a tiling window manager. Basically, the compositor
> >> provides an interface similar to the TTY with tmux running. When the user
> >> launches a visual application, the compositor will then overlay it on the
> >> pane from which it was launched. My current strategy for implementing this
> >> is to launch an internal tmux client in control mode to every session on
> >> the server in order to track what actions the client is taking and respond
> >> accordingly.
> >>
> >> In its current state, tmux???s control mode looks like it provides almost
> >> enough capabilities to make this project work. The biggest thing it is
> >> missing are notifications for when the user switches active panes within a
> >> window and when the user switches active windows in a session. It would
> >> also be nice to have a notification for when the user switches into and
> >> out of copy mode, but this isn???t essential. Finally, it would be nice to
> >> get notifications on the ???client-session-changed??? hook, but since
> >> there is a hook already I can very easily work around this.
> >>
> >> I have begun to look through tmux???s source in order to implement these
> >> features myself, but I haven???t made much progress yet as the project is
> >> quite large and I???m not familiar enough with all of the use cases needed
> >>  to make these notifications always work. Any advice on how to implement
> >> these features would be much appreciated (or if someone is willing to
> >> implement the features themself, that would be great too :). Finally, any
> >> feedback on my general strategy would be appreciated as I???m not entirely
> >> sure if I???m going about this in a reasonable way.
> >>
> >> Thanks!
> >> ???Joshua Brot
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "tmux-users" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to tmux-users+unsubscr...@googlegroups.com.
> >> To post to this group, send an email to tmux-users@googlegroups.com.
> >> For more options, visit https://groups.google.com/d/optout.
> >

> From c830ea1e227b73888f51961eb7517deac2f93981 Mon Sep 17 00:00:00 2001
> From: Joshua Brot 
> Date: 

Re: Expanding Control Mode

[Nicholas Marriott]

Hi

What have you got so far?

Control mode should already get updated for client-session-changed, if
you look at notify.c:notify_callback there is already a check that
passes it into control_notify_client_session_changed.

For new ones you will need to add a notify_add call somewhere and then
add a control-notify.c function and a check in notify_callback, for
active pane it'll probably need a notify_add call in
window.c:window_set_active_pane.

Mode changes you can do in window_pane_set_mode and
window_pane_reset_mode.


On Tue, May 02, 2017 at 02:27:57AM -0500, Joshua Brot wrote:
> Hi!
> 
> I???m currently in the process of writing a Wayland Compositor with the goal 
> of using tmux as a tiling window manager. Basically, the compositor provides 
> an interface similar to the TTY with tmux running. When the user launches a 
> visual application, the compositor will then overlay it on the pane from 
> which it was launched. My current strategy for implementing this is to launch 
> an internal tmux client in control mode to every session on the server in 
> order to track what actions the client is taking and respond accordingly.
> 
> In its current state, tmux???s control mode looks like it provides almost 
> enough capabilities to make this project work. The biggest thing it is 
> missing are notifications for when the user switches active panes within a 
> window and when the user switches active windows in a session. It would also 
> be nice to have a notification for when the user switches into and out of 
> copy mode, but this isn???t essential. Finally, it would be nice to get 
> notifications on the ???client-session-changed??? hook, but since there is a 
> hook already I can very easily work around this.
> 
> I have begun to look through tmux???s source in order to implement these 
> features myself, but I haven???t made much progress yet as the project is 
> quite large and I???m not familiar enough with all of the use cases needed  
> to make these notifications always work. Any advice on how to implement these 
> features would be much appreciated (or if someone is willing to implement the 
> features themself, that would be great too :). Finally, any feedback on my 
> general strategy would be appreciated as I???m not entirely sure if I???m 
> going about this in a reasonable way.
> 
> Thanks!
> ???Joshua Brot
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "tmux-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to tmux-users+unsubscr...@googlegroups.com.
> To post to this group, send an email to tmux-users@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"tmux-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tmux-users+unsubscr...@googlegroups.com.
To post to this group, send an email to tmux-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.