Re: tmux 2.0 released

On Thu, May 07, 2015 at 12:12:46AM +0100, Thomas Adam wrote: > I'm pleased to announce the release of tmux 2.0. Please take a look > here: > > https://sourceforge.net/projects/tmux/files/tmux/tmux-2.0/ > > for the release tarball and changes introduced in to 2.0. On its way to Debian... Note for

Re: tmux bug (?) and problem (and more)

On Sun, Jun 22, 2014 at 10:50:51PM +0200, Emanuel Berg wrote: > Nonetheless, there should be a better way than sleep to > do it. I'm on it. tmux is supposed to do this the right way since 1.7, using a lockfile. Your experience suggests that it's not working. --

Re: pane border color issue on 1.8

Pavlos Parissis writes: > This issue doesn't happen on 1.7 version. > Any idea what could be the problem here? This is not a bug, it's a feature. When there's only two panes, the separator is split in two to show which pane is active. Try switching between the panes to understand the logic of it

Re: BUG: Crash when killing a session's last window's program from a grouped session

Which tmux version are you using? Can you reproduce the bug with the latest code from Git? -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppD

Re: [PATCH] Accept alternative spellings of "colour"

Nicholas Marriott writes: > I don't see a need for this. How frustrating is it really to have to > change one letter? Admittedly not very, but enough that I felt the need to send a patch. :) It's mostly annoying when picking colors from M-x list-colors-display, you have to remember to change the

[PATCH] Accept alternative spellings of "colour"

Using colors from the 256-color set is a bit annoying at times because tmux only accepts the British spelling "colour123" where xterm uses "color123" and Emacs (which has the very useful M-x list-colors-display) uses "color-123". To make customization less frustrating, accept all variants as input

[PATCH] Add pane_synchronized window format

I would find it useful to have a visual reminder that panes are synchronized in my status line, so add a 'pane_synchronized' format that can be used as a conditional. Thanks, diff --git a/format.c b/format.c index 811068a..238aa4a 100644 --- a/format.c +++ b/format.c @@ -460,6 +460,8 @@ format_wi

Re: [PATCH 1/1] Allow conditional formats to expand formats

Thomas writes: > @@ -182,6 +182,9 @@ format_replace(struct format_tree *ft, > goto fail; > value = ptr + 1; > } > + > + if ((value_found = format_expand(ft, value)) != NULL) > + value = value_found;

[PATCH] Don't send focus events to dead panes

When `remain-on-exit' is set and the terminal supports focus reporting, tmux 1.8 sometimes crashes because it uses the bufferevent of a dead pane in server_client_check_focus(). There's already a check in server_client_check_resize(), so just move it to the caller loop to handle both cases at the

Re: expanson of specials in source-file

Daniel writes: > The following would be nice for host-local config: >source-file ~/.tmux.conf.#h If someone wants to cook up a patch for this, please also take a look at: http://bugs.debian.org/629620 -- Own the

Re: Changes to tmux-code.git on SF -- "master" branch rewound.

Nicholas Marriott writes: > I don't understand what master has to do with it, are you building > packages from master rather than from a tag? Yes, I build packages for Debian's experimental suite from master, usually every couple of weeks. For unstable I use the latest official release, of cours

Re: Changes to tmux-code.git on SF -- "master" branch rewound.

Nicholas Marriott writes: > If we have nice history it is a bonus but if it's easier then it'll be > messed up. Why is this a problem? Every change is there at least once, > nothing is lost. What can you no longer do here? It's fundamentally broken to have every change in there twice, one of whi

Re: Changes to tmux-code.git on SF -- "master" branch rewound.

Thomas Adam writes: > On Tuesday evening -- I'm planning to release tmux 1.8. To this end, > I've updated the "master" branch on SF to reflect what will be in it. > To most people this won't be news because it should contain everything > it used to beforehand, but I've had to rewrite the history

Re: Should copy-pipe use a (writable) job?

Chris Johnsen writes: > Having maintained tmux as cross-platform project, you probably have > a good feel for where the sharp cross-platform edges lurk, so > I welcome further consideration of the right approach. I would > certainly not attempt to claim that my implementation is definitely > cros

[PATCH] Document new window flag 'Z', clarify description

Use the word 'zoom' to describe resize-pane -Z, and add the new window flag 'Z' to the table. diff --git a/tmux.1 b/tmux.1 index 519bf6f..6264517 100644 --- a/tmux.1 +++ b/tmux.1 @@ -1624,8 +1624,8 @@ is given in lines or cells (the default is 1). .Pp With .Fl Z , -the active pane is toggled be

[PATCH] Don't zoom windows with only one pane

Zooming has no visible effect if the window has only one pane (other than adding a window flag), so we might as well do nothing at all. diff --git a/window.c b/window.c index fc06e87..2be51e9 100644 --- a/window.c +++ b/window.c @@ -480,6 +480,10 @@ window_zoom(struct window_pane *wp) if

[PATCH] Plug format_window_pane() leak

Commit 1db4ec6e63 added a new pane_current_command format using osdep_get_name(), which allocates. So we need to free the result after using it. Thanks, diff --git a/format.c b/format.c index ad52cae..b71 100644 --- a/format.c +++ b/format.c @@ -398,7 +398,8 @@ format_window_pane(struct forma

[PATCH] Make last-pane unzoom window

I was testing the new zoom feature and found that last-pane doesn't unzoom the window although it's a frequently used command that would seem a natural fit for unzooming. Also, fix a typo in the description. Thanks, diff --git a/cmd-select-pane.c b/cmd-select-pane.c index d24d7b3..b8a1267 100644

Re: [PATCH] Plug two small memory leaks

Nicholas Marriott writes: > This is with: > valgrind --leak-check=full --trace-children=yes --trace-children-skip=*sh > --log-file=out ./tmux new > How are you running valgrind? > Are you sure you are using a clean, unmodified checkout from latest git? > What are you doing to test? I have a l

Re: [PATCH] Plug two small memory leaks

Nicholas Marriott writes: > So you don't see this if you comment out the screen_reflow call? Or do > the leaked allocations move somewhere else? Without the screen_reflow call I get only this one: ==19895== 127,862 bytes in 481 blocks are definitely lost in loss record 196 of 197 ==19895==

Re: [PATCH] Plug two small memory leaks

Nicholas Marriott writes: > Do you have this change? I was the one who reported this particular issue in the first place. And the reason I'm using Valgrind now is that even after this change, tmux seems to leak. Example report of a few seconds of resizing my terminal: ==19895== HEAP SUMMARY: =

[PATCH] Plug two small memory leaks

While testing the reflow code I noticed that resizing the screen a lot seems to leak some memory, and Valgrind agrees. In fact, memory gets leaked even if I compile out the reflow code, so there are probably some old bugs in there. I'm trying to understand what we're doing wrong but in the meantim

Re: tmux in tmux

Thomas Adam writes: > Nope. Not without nesting. But you can nest and use a different prefix in the inner tmux... -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile de

Re: [PATCH] Canonicalize socket directory, not full path

Thomas Adam writes: > Wasn't this already looked in to? Thanks, I wasn't aware of this previous discussion... > Certainly there's a patch attached to that thread from Nicholas. It never made it into CVS, so the bug is still there. --

[PATCH] Canonicalize socket directory, not full path

When tmux starts for the very first time we call realpath() on a socket path that doesn't exist yet, the server hasn't started so the socket hasn't been created. On Linux at least, this fails with ENOENT and leaves the path unchanged, so it can contain a double slash (e.g. /tmp//tmux-uid/label). T

[PATCH] Fix up memcpy call in window_mode_attrs()

Presumably we want to use the size of the destination, not the size of the pointer. --- window.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/window.c b/window.c index 5ef8195..6ec51c3 100644 --- a/window.c +++ b/window.c @@ -1203,7 +1203,7 @@ winlink_clear_flags(struct w

Re: [PATCH 0/1] Expand/collapse in choose-tree

Thomas Adam writes: > I am not so sure I like this -- I don't mind updating the man page to > detail this more, but I don't think this warrants explanatory text > directly on the screen. Fair enough. It won't be the only awesome feature in tmux that is only discoverable by reading the man page.

Re: [PATCH V2 1/1] Add expand/collapse functionality in choose-tree

Thomas Adam writes: > I've still left the bindings for expand_all and collapse_all unchanged -- > if they need to change, feel free to do so. I suggest using '+' and '-'. Mnemonic and easy to reach. -- Got visibility?

Re: [PATCH 0/1] Expand/collapse in choose-tree

Thomas Adam writes: > This improves upon my original POC patch from the other day, to add in > support for expanding/collapsing sessions in choose-tree. Thanks, I like it. Two minor suggestions: - the arrow keys are too far to reach for me, using Space to expand or collapse the items would be

Re: [PATCH] choose-tree: use line-drawing characters if possible

Nicholas Marriott writes: >> > Although I am a little inclined to instead add #[acs] #[noacs] and make >> > it use screen_write_cnputs so people can use #[format] stuff which might >> > be nice for choose-list. Wouldn't be so nice if you have a window called >> > #[foo] though... so maybe not. >>

Re: [PATCH] choose-tree: use line-drawing characters if possible

Nicholas Marriott writes: > Sorry I didn't really give you many clear clues here - we actually need > to make it pass some code through so the final write is done with the > charset bit set. How about something like the diff below? Ah yes, very nice. It takes care of the acsc and utf-8 modes in

Re: [PATCH] choose-tree: use line-drawing characters if possible

Nicholas Marriott writes: > Don't think I want to use UTF-8 arrows unless the ACS arrows will work > too. Ok. Conceptually we just have to use smacs/rmacs around the codes when writing to the terminal and it should work, right? I tried the naive approach below and the escape sequences are not in

Re: [PATCH] choose-tree: use line-drawing characters if possible

Nicholas Marriott writes: > The problem is that you need to turn ACS on and off, it's not as simple > as just using and so on. There is currently no way to tell the > window-choose code that a section of an entry should be displayed with > ACS on. Ah, ok. Yeah, that sounds harder to fix. I

Re: [PATCH] choose-tree: use line-drawing characters if possible

Nicholas Marriott writes: > I don't like using "`" at all, it tends to be very different between > different fonts and look weird in them all. > I'd rather have a solution that always worked not just with UTF-8 :-). Hmm. I didn't find the previous discussion between you and Thomas on this subje

[PATCH] choose-tree: use line-drawing characters if possible

This is loosely based on a previous patch by Thomas to use line-drawing characters to show the tree in the new choose-tree command, but this time we only use them if the client has UTF-8, which should be a safe enough heuristic. If it doesn't, the tree is rendered as ASCII, with a slightly cleaned

Re: [PATCH] Fix default client template

Thomas Adam writes: > I suppose the wider point is that you're not going to please everybody, > and that despite the change -- and that people are free to change it -- > might seem like too much of a change for people who now have to edit > their configuration files, etc. Changing the default te

Re: [PATCH] Fix default client template

Nicholas Marriott writes: > If it makes things significantly simpler to have one define, I think I > would consider trimming bits from list-windows and force people to add > them back with -F rather than adding them to choose-windows. Can we at least have this? (Note: includes the fix previously

Re: [PATCH] Fix default client template

Thomas Adam writes: > Yes. And hey, guess what? You're now free to change it with -F. choose-window is a very important command, using an inferior default just to factorize some code is a disservice to our users. -- L

[PATCH] Fix default client template

list-clients/choose-client are broken in current svn because the new template is not syntactically correct, see following patch. While we're on the subject, is it a feature that choose-window now uses the same template as list-windows? The old choose-window included the title of the active pane wh

Re: How to share information between panes of a window

Stephen Thirlwall writes: > Ideally, I'd like to be able to query the value of TVIM_PANE_ID from > any pane in that particular window. > Note that there may be a tvim pane in multiple windows, so this needs > to be local to the window, not a global setting. > Is there some way to do this using

Re: [PATCH] Avoid syntax error in examples/screen-keys.conf

Thomas Adam writes: > Hence, rather than relying on the comment to remain to protect this -- > I would simply quote the backslash as in: > unbind '\' I don't have a strong opinion either way on this, I guess whoever makes the change in SF gets to decide how to quote th

[PATCH] Avoid syntax error in examples/screen-keys.conf

+++ b/examples/screen-keys.conf @@ -72,7 +72,7 @@ unbind w bind w list-windows # quit \ -unbind \ +unbind \ # protect backslash bind \ confirm-before "kill-server" # kill K k -- Romain Francoise http://people.debian.org/~

Re: status at top

atus line to change windows also changes the active pane. -- Romain Francoise http://people.debian.org/~rfrancoise/ -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning li

Re: Using tmux as a fanout

Michael Fischer writes: > 2) I'm currently bookending my script with "new-session; CMD foreach server>; kill-pane -t 0" but this feels inelegant, any > suggestions on how to improve this? Create the first pane in new-session. For reference, my own simple script to do this: #!/bin/sh # Usage: t

Re: [PATCH] Allow users to disable screen title setting sequence

o name windows and wants to keep it in the general case, but they want windows that are explicitly given a name in tmux.conf to not honor the rename. Knowing which window that applies to is easier on the tmux side than on the shell side, I guess (because of configuration management, ssh, whatever

[PATCH] Allow users to disable screen title setting sequence

Hi, Over on the Debian BTS, in bug #654882, one of our users requests the ability to turn off the screen title setting escape sequence so that tmux doesn't discard a manually-set window name, ever. Would something like the following be acceptable? Thanks. diff --git a/input.c b/input.c index 173

[PATCH] Ignore status line clicks for mouse-select-pane

Hi, When mouse-select-pane and mouse-select-window are both enabled, clicking on the status line to select another window also changes the current pane of the active window to the one adjacent to the status line. This is probably not what was intended, so make mouse-select-pane ignore clicks in t

Re: [PATCH] New option to get cwd of new windows from active window

path of the > session. Can this be accomplished yet? Hmm. I guess the new-session command could take an option to automatically set default-path to the session cwd at creation time. That would work, but it's not very clean. -- Romain Francoise http:/

Re: [PATCH] New option to get cwd of new windows from active window

marcel partap writes: > ..just for reference, from konsole/src/ProcessInfo.cpp, includes omitted: > [...] Thanks, that was useful. -- Romain Francoise http://people.debian.org/~rfrancoise/ -- Cloud Se

Re: [PATCH] New option to get cwd of new windows from active window

Nicholas Marriott writes: > Ok, so OpenBSD should have a way to do this soon, either a new > second-level sysctl KERN_PROC_CWD or a new third-level under > KERN_PROC_ARGS. Don't worry about that though, let's move forward with > your diff and I'll add OpenBSD when my code goes in. Awesome, thank

Re: [PATCH] New option to get cwd of new windows from active window

Nicholas Marriott writes: > Can we do this on ANY platform apart from Linux? Solaris, with procfs. That's about it, I think. -- Romain Francoise http://people.debian.org/~rfrancoise/ -- All the data cont

Re: [PATCH] New option to get cwd of new windows from active window

re back to square one. -- Romain Francoise http://people.debian.org/~rfrancoise/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, securi

Re: [PATCH] New option to get cwd of new windows from active window

s for me. So, if linking with -lkvm is acceptable I'll add support for OpenBSD and send an updated patch. Thanks, -- Romain Francoise http://people.debian.org/~rfrancoise/ -- All the data continuously generated in

Re: [PATCH] New option to get cwd of new windows from active window

having to carry this feature as a Debian patch. Thanks, -- Romain Francoise http://people.debian.org/~rfrancoise/ -- All the data continuously generated in your IT infrastructure contains a definitive record o

Re: [PATCH] New option to get cwd of new windows from active window

Thomas Adam writes: > Why, when this is in the tmux FAQ? The "solution" in the FAQ is ugly. -- Romain Francoise http://people.debian.org/~rfrancoise/ -- All the data continuously generated in your IT i

[PATCH] New option to get cwd of new windows from active window

Hi, This patch adds a new session option 'inherit-default-path' and the associated machinery to create new windows/panes in the same working directory as the active window instead of using the value of default-path. It affects only windows created from keys or the command prompt. Note that only L

Re: Implement word motion edit actions

Nicholas Marriott writes: > --- status.c 15 Nov 2011 23:34:12 - 1.81 > +++ status.c 27 Nov 2011 03:09:56 - > @@ -1156,11 +1156,8 @@ status_prompt_key(struct client *c, int > /* Find the separator at the end of the word. */ > while (c->prompt_index != si

Re: Implement word motion edit actions

is wrong too: in vi mode it moves past the word, as in Emacs, but it should leave the cursor at the end of the word. -- Romain Francoise http://people.debian.org/~rfrancoise/ -- All the data continuously generated in you

Re: Implement word motion edit actions

). Thanks, -- Romain Francoise http://people.debian.org/~rfrancoise/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats,

Terminal types supporting XT

\\007" -":Cs=\\E[%p1%d q:Csr=\\E[2 q" +":Cs=\\E[%p1%d q:Csr=\\E[2 q,screen:XT" + ",rxvt*:XT" }, { .name = "update-environment", Thanks, -- Romain Francoise http://people.debian.org/~

Re: Signal handling in current CVS

I see that my patch is now in CVS, thanks! But the merge from OpenBSD back to SF was a bit careless, the setenv/unsetenv configuration for libevent is now a no-op since event_init() was moved elsewhere... please apply the following to SF to restore it: Index: server.c =

Re: Signal handling in current CVS

435,6 +367,9 @@ server_signal_callback(int sig, unused s EV_READ|EV_PERSIST, server_accept_callback, NULL); event_add(&server_ev_accept, NULL); break; + default: + /* signal not handled here, ignore. */ + ret

Re: Crash in window_copy_find_length()

I think it would still have crashed during copy-mode, > though. Doesn't seem to be the case in tmux 1.2 at least. -- Romain Francoise http://people.debian.org/~rfrancoise/ --

Crash in window_copy_find_length()

ing `list-keys' output. Thanks, -- Romain Francoise http://people.debian.org/~rfrancoise/ -- ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users

Signal handling in current CVS

The last change in tmux.c to ignore SIGCHLD in main() introduces a bug: the signal handler is never reset back to SIG_DFL and this signal configuration in inherited by the server when it's created, and in turn by the commands that are spawned because signal_del() resets it to the previous value in

Making dead windows easier to spot

gt;sx, w->sy, window_count_panes(w), + w->active->fd == -1 ? ", dead" : "", left, title, right); } Would that be suitable for inclusion? Thanks, -- Romain Francoise http://people.debian.org/~rfrancoise/ ---

Double-free crash in server_destroy_pane()

t_free(wp->event); - wp->fd = -1; + if (wp->fd != -1) { + close(wp->fd); + bufferevent_free(wp->event); + wp->fd = -1; + } if (options_get_number(&w->options, "remain-on-exit"))