On Tue, Mar 05, 2013 at 12:10:57PM -0300, Thiago Padilha wrote:
> Ok, this week I will implement it
>
> About the command, do you prefer two separate commands for
> locking/unlocking and waiting signaling? What name(s)/parameters
> should the commands have? Should I use a separate file for defini
Ok, this week I will implement it
About the command, do you prefer two separate commands for
locking/unlocking and waiting signaling? What name(s)/parameters
should the commands have? Should I use a separate file for defining
the tree/global variables(like I did with the monitor.c file)
I think
On Tue, Mar 05, 2013 at 11:20:54AM -0300, Thiago Padilha wrote:
> Ok, I your idea is simpler and it should work. mine was just a proof
> of concept actually.
I suggest you extend my code to add the tree+queues and then I will
apply it and then we can add locks. Or you can do both but send them as
Ok, I your idea is simpler and it should work. mine was just a proof
of concept actually.
I would like to get this on the next version(already using on my
scripts) but I'm kinda busy to reimplement right now so I will
probably do it on weekend. Do you any idea when you will freeze tmux
1.8 feature
On Tue, Mar 05, 2013 at 10:30:07AM -0300, Thiago Padilha wrote:
>I'm not always sure about the meaning of client in tmux, but what needs to
>hold the lock is not the tmux command that connects to the server, but the
>process that is connected to the pseudo tty that is displayed by the t
I'm not always sure about the meaning of client in tmux, but what needs to
hold the lock is not the tmux command that connects to the server, but the
process that is connected to the pseudo tty that is displayed by the tmux
pane(normally this will be a shell), that is why I used panes to reference
I think this could be much simpler - to give you an idea, this is the
kind of thing I had in mind, but instead of just one saved cmdq having a
tree of wait channels each with a list of cmdq attached.
Locking can be implemented very similarly and perhaps even using the
same data structures as neede
I haven't had a lot of time to spend on this but:
I don't understand why you are doing anything with panes. What have
panes got to do with it? This only needs to worry about clients. Panes
can't wait for anything.
Also we will need to change the name, I don't like "monitor", but we can
worry abou
Any chance this patch will be accepted?
I still need to tweak a few things:
- Detect when a waiting pane exits and remove it from the queue/monitor
- Move the queue shifting to the event loop
- Handle SIGINT in the tmux client(Not sure about this one)
I didn't manage to implement those myself,
Here's a nice integration between vim and tmux for any zsh users that want
to give this patch a try: https://gist.github.com/tarruda/5051527
Combined with the new zoom patch, you can get a nice 'toggle top terminal'
experience.
On Tue, Feb 26, 2013 at 11:37 AM, Thiago Padilha wrote:
> Here is TA
Here is TAILQ version of the patch, along with the event loop diff(which
randomly crashes the server for me again)
---
Makefile.am | 2 +
cmd-monitor.c | 110
cmd.c | 1 +
examples/monitor.sh | 120 ++
monitor
Ok, can you give me a hint/example on how I might listen for a client exit
so I can remove the node associated with the monitor?
On Tue, Feb 26, 2013 at 10:56 AM, Thomas Adam wrote:
> On Tue, Feb 26, 2013 at 10:50:58AM -0300, Thiago Padilha wrote:
> > I expressed myself badly. I meant using your
On Tue, Feb 26, 2013 at 10:50:58AM -0300, Thiago Padilha wrote:
> I expressed myself badly. I meant using your commit as a model for
> organizing my code, not base the work on it.
OK.
> This patch contains the refactored version and it should be possible
> to apply on current master
Still using
I expressed myself badly. I meant using your commit as a model for
organizing my code, not base the work on it.
This patch contains the refactored version and it should be possible
to apply on current master
---
Makefile.am | 2 +
cmd-monitor.c | 110
This one refactors the previous patch to use event loop when shifting
monitors. I have tested it now and it seems to be working alright, I
guess I have done something wrong the first time I tried this.
---
monitor.c | 32 ++--
tmux.h| 1 +
2 files changed, 31 inser
On 26 February 2013 12:02, Thiago Padilha wrote:
> Sorry I forgot to pull from sf before creating the patch
>
> I'm going to refactor based on your hook-support
> commit(https://github.com/ThomasAdam/tmux/commit/ea2f662950f0bc12eb673c2cbd946f2579c62c7f)
> ok?
No it's not OK because that's on-goin
Sorry I forgot to pull from sf before creating the patch
I'm going to refactor based on your hook-support commit(
https://github.com/ThomasAdam/tmux/commit/ea2f662950f0bc12eb673c2cbd946f2579c62c7f)
ok?
About the SIMPLEQ, I used it because I only needed a simple stack/queue but
I will change it to
On Mon, Feb 25, 2013 at 09:27:24PM -0300, Thiago Padilha wrote:
> Command that provides features for all synchronization needs in tmux scripts.
I can't apply this with git-apply.
> 1- When unlocking waiting panes, I guess it should be done in the
> event loop, however I was getting random crashes
Command that provides features for all synchronization needs in tmux scripts.
I added an example script that serves a temporary documentation and
shows the features provides by displaying a simple 'animation' which
integrates multiple panes.
I can see two issues with the current implementation:
19 matches
Mail list logo
