If you have mouse-select-pane enabled you can switch panes via the mouse
wheel. But if the current pane is in copy mode this doesn't work. The
attached patch fixes this.
--
Balazs
diff --git a/server-client.c b/server-client.c
index 77e6de7..6001d64 100644
--- a/server-client.c
+++ b/server-clien
On 2014-02-14 13:22, Nicholas Marriott wrote:
> Why not just let them both through always?
Note that your patch has a slight behavior change: Originally any mouse
event would change the current pane as long as the current one is not
copy mode. In the new one we can only use DOWN and WHEEL but in a
When you increase the height of the pane and you have some history then
the last lines of it will be pulled into the visible screen's content.
This is quite annoying for me and would like to have the option of just
filling the bottom with blanks. Do you also think this is a good idea?
I'm thinking
On 2014-02-21 19:59, Thomas Adam wrote:
> I'm actually thinking this is a niche option. I wouldn't think it's
> needed.
Yeah, I have an OCD to keep my terminals mostly clear by pressing ^L.
But after a resize (e.g. reattach from a bigger screen which happens a
lot of time for me) all my panes are
Commit [1] has broken tmux 1.9 so that it leads to crash. You can
reproduce the crash the following way. Let's assume we have a tmux with
an empty configuration. Start up a new session and enter the following
commands via b:
split-window
split-window
split-window
se
On 2014-02-27 22:09, Matteo Cavalleri wrote:
> $ cat /etc/hosts | less # the pipe is important here
> [...]
> so when I create a new window with e.g. something piped to less the
> new window opens on the root directory, always.
It seems that tmux tries to determine the pane's current directory by
On 2014-03-01 08:35, Kaushal wrote:
> The script runs fine, but I get these tcsh messages in the pane where
> I enter that key-binding:
>
> --
> tcsh: No such file or directory
> tcsh: Trying to start from "/home/USER"
> --
Is it possible that you have started the tmux server in a
> I see the commit c930fd5ff696f5a60e93ed503f0ff57e0bbf6e4d "Remember
> the last active pane in the top-bottom or left-right cell..." changed
> the behavior of pane navigation. If it possible, I really want an
> option to restore the old behavior.
I agree, this is a behavior change in the new vers
On 2014-03-02 15:34, Kaushal wrote:
> BUT when I run the same through run-shell using a key-binding,
> --
> bind C-e run "tmux list-windows -F '#{session_name}:#{window_index}' |
> xargs -I SESS_WIN tmux list-panes -t SESS_WIN -F 'SESS_WIN.#{pane_index}'"
> --
> I get,
> --
On 2014-03-06 14:00, Jan Larres wrote:
> Like I said I had to restart tmux so I can't test that at the moment,
> but I could try to reproduce it.
So when I do
set -g status-right "#(sleep 30)"
set -g status-interval 1
I see that tmux starts hoarding the sockets. So it possible that
On 2014-03-06 12:55, Nicholas Marriott wrote:
> Why not getsid()?
Don't you need a pid for that? I haven't tried but I think we could use
/proc/(window_pane.pid)/cwd for this if we pass the pid down to this
function and then we don't even need the session id queries at all.
--
Balazs
--
> #!/usr/bin/env bash
> for i in {0..255} ; do
> printf "\x1b[38;5;${i}mcolour${i}\n"
> done
>
> I found out that I need "colour8" for grey.
>
> But after setting "set -g status-bg colour8" the background of the
> status bar is black.
You are enumerating the foreground colors. Try changing the
[+tmux-users@lists.sourceforge.net], let's keep the list in loop.
On 2014-03-07 12:01, Matus Kmit wrote:
> > Try changing the number from 38 to 48 to enumerate the background
> > colors. Do you still see colour8 as grey?
> yes, i still see colour8 as black
Sorry this is a bit unclear to me. When
On 2014-03-07 12:03, Balazs Kezes wrote:
> When you enumerate all the background colors via 'for i in {0..255} ;
> do printf "\x1b[38;5;${i}mcolour${i}\n"; done'
Sorry, that should say this (s/38/48/g):
When you enumerate all the background colors via 'for i in
On 2014-03-07 19:52, Jan Larres wrote:
> Are you seeing the sleep jobs in the 'Jobs:' output of 'tmux info'?
Ah, yes, I do see them in my case.
> I didn't have any jobs there, but I don't know how to test it at the
> moment since as I mentioned that section seems to be missing from my
> info outp
On 2014-03-21 23:57 +, solo-t...@goeswhere.com wrote:
> This helps when a command is running as a different user, it is common
> to be able to see its parents, but not its cwd.
I haven't tried but I think this will work for the sudo case but not for
others when the parent exits. Try creating a
> If I do: man tmux then split the screen. The directory will be
> /usr/share/man.
This is currently working as intended. The command man actually changes
directory to /usr/share/man for some reason and because it is the
foreground process leader, tmux uses that as the initial directory for
the ne
On 2014-03-22 10:10 +, starryin wrote:
> i get following config file
> neww -n nginx -c "/var/log/nginx/"
> select-pane -t 1
> split-window -h -c "#{pane_current_path}"
> send-keys "tail -f access.log" C-m
> after :source-file this file, the pane 1 will enter into the log
> directory, but pan
On 2014-03-27 13:47 -0500, Grant Welch wrote:
> If I do send-keys from either the ':' command-prompt or from the
> terminal, it will behave appropriately. I suspect that it is a timing
> issue, that the bad behavior only occurs when send-keys executes
> before the terminal's initial prompt appears.
On 2014-04-09 23:24 -0400, James Pickard wrote:
> This works with tmux 1.7 but in tmux 1.8 the "split window -h" command
> is executed and then a "K" appears in the new pane.
tmux 1.8 got a new option called assumed-paste-time:
If keys are entered faster than one in milliseconds, they are
On 2014-04-07 13:54 +0200, Pavlos Parissis wrote:
> Let me know what I else I can do in order to help troubleshooting
> this.
So I've skimmed the source again and now I've found an actual leak but
I'm not sure you are hitting this or not. If the fork() in job_run()
fails then tmux will definitely
On 2014-04-14 11:57 +1200, Jan Larres wrote:
> I usually hit the problem when my machine becomes unresponsive for a
> while due to heavy swapping when starting a memory-heavy process. I'm
> not sure if that could cause fork() to fail, but it sounds like a
> possibility.
Yeah. If you have large amo
On 2014-04-17 15:25 +0100, Nicholas Marriott wrote:
> This doesn't actually fix the problem for me on Linux, does it for
> both of you?
It does fix it for me. I actually use it for a while now and never seen
a new pane starting in /. Can you tell me how do you test it and
possibly step through the
On 2014-04-17, Nicholas Marriott wrote:
> It certainly wouldn't reliably take you to the pane "up" when you
> asked.
It actually does when you use grid layouts. I think I've already dug out
the code demonstrating this in another thread. It's relative to the
current pane's top left corner. But yeah
On 2014-04-20 15:16 +, mMontu wrote:
> The output of the third line is still truncated. I've read the man
> page but couldn't figure out how to read the full contents of that
> line.
Just to clarify: you are running list-panes from the tmux command line?
Furthermore, with 'tmux run-shell "seq
On 2014-04-25 12:30 +, mMontu wrote:
> Sometimes the select-pane for up and down movement command behaves
> incorrectly, moving in diagonal.
Yes, the pane movement behavior has changed in tmux 1.9. There's a lot
of discussions around this in ticket #122. I recommend closing this and
keeping th
On 2014-04-23 11:15 +0100, Gil Rutter wrote:
> 2 - When a pane is SSHed to a different machine, I'd like new splits I
> make while that pane is in focus to automatically SSH in.
There are many other ways to achieve this. I'm sure you can find many
solutions when you search for it. Here is one appr
Nicholas/Thomas,
I think Vardan's problem is something that a new formatting variable
called client_pid could make much simpler. Another typical scenario next
to Vardan's case is when you want to access the current client's DISPLAY
environment variable. Note that I can't use tmux's setenv/showenv
On 2014-05-01 14:31 +0200, Pavlos Parissis wrote:
> I know that Nicholas has already reported that he fixed some leaks,
> but I thought it could be useful for Kezes.
Awesome, thanks! Yes, the head version already contains the fix so we
can expect it to officially arrive in the next version.
--
B
On 2014-05-01 17:41 -0400, Kaushal wrote:
> I wanted to do "cp file.1 file.2" and I typed "fp" by mistake instead
> of "cp". So I did "Ctrl-a", "Ctrl-d", c. But before the c could
> register, that pane froze and I can't do anything to kill whatever
> froze that pane.
Is it possible that you accide
--- Begin Message ---
[+tmux-users]
On 2014-04-29 17:51 +, daemianmack wrote:
> Yes, reverting that commit [c52548f6fd311e4df3076ba4cc6f6ab8849557ac]
> fixes the problem for me.
Although I still can't test it but I think I know what happens. That
commit contained this change:
diff --git a/xt
Sorry for the inconveniences caused but my last email was weirdly
constructed and not properly viewable in the mailing list archive, so
here's the contents again:
[+tmux-users]
On 2014-04-29 17:51 +, daemianmack wrote:
> Yes, reverting that commit [c52548f6fd311e4df3076ba4cc6f6ab8849557ac]
>
On 2014-04-30 11:03 +, mMontu wrote:
> > Just to clarify: you are running list-panes from the tmux command
> > line?
> Indeed, I wasn't even aware of any other way of running this command.
Yes, you can use "tmux list-panes" from a shell instead of the tmux
command line and you won't see this s
On 2014-05-08 07:20 +0100, Nicholas Marriott wrote:
> If they are some other modifier not included in the xterm 1-8 set, then
> we don't want to convert \033[1;9A into Up if it's not actually Up but
> actually Weird-Apple-Only-Key+Up.
Actually the bit 0x08 means "meta" in xterm and apparently iTer
On 2014-05-16 09:48 +0100, Balazs Kezes wrote:
> Now that I managed to reproduce this on my machine, I realized that
> the fix is a bit more complicated than I expected. I can try to gather
> some time in the future to fix it unless you beat me to it. :)
OK, I've actually manag
On 2014-03-05 11:50 +0100, Marcel Partap wrote:
> diff --git a/input-keys.c b/input-keys.c
> index 7582a63..b76dd6c 100644
> --- a/input-keys.c
> +++ b/input-keys.c
> @@ -244,7 +260,7 @@ input_mouse(struct window_pane *wp, struct session *s,
> struct mouse_event *m)
> paste_s
Sorry, forgot to attach a simple patch to fix this:
diff --git a/input-keys.c b/input-keys.c
index 7531f22..4c4da91 100644
--- a/input-keys.c
+++ b/input-keys.c
@@ -259,7 +259,7 @@ input_mouse(struct window_pane *wp, struct session *s,
struct mouse_event *m)
paste_send_pan
When you start a selection and then move a line up, then the starting
cell isn't indicated to be in the selection. It should be and this patch
fixes that.
---
screen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/screen.c b/screen.c
index 7bfc015..3b741b2 100644
--- a/screen
applying this.
Thanks!
[1] https://github.com/dylex/xtmux/commit/14ad1
[2] https://github.com/dylex/xtmux/commit/32f78
[3] https://github.com/dylex/xtmux/commit/2dd72
--
Balazs
>From b0a4d4820bd281a70520a588c6890f4f70b30931 Mon Sep 17 00:00:00 2001
From: Balazs Kezes
Date: Sat, 17 May 2014 1
On 2014-05-23 11:58 +0100, Nicholas Marriott wrote:
> Can you give me an example? It seems fine to me.
Sure. I've attached a screenshot. In the top part you can see that I've
selected "quis nostrud" and it is highlighted correctly. But when I
press up, the selection changes to "... quis nostru". T
On 2014-05-23 11:59 +0100, Nicholas Marriott wrote:
> Shouldn't we instead reset m->button when the mouse wheel is used?
Yep, that works as well. I've chosen 3 as the reset value because that's
what I've seen in server_client_create as initialization value. Here's
the patch:
diff --git a/tty-keys
On 2014-05-23 12:48 +0100, Nicholas Marriott wrote:
> I think this can be made neater by making xterm_keys_modifiers do all
> the work directly rather than searching for the _ all over again,
> please look at this:
Yes, this approach looks much nicer, thanks! Two nits:
> + if (buf[*pos] < '0'
previous attempt.
--
Balazs
>From cc474a2d97e9062761b2a5a74b95044b4f845ef8 Mon Sep 17 00:00:00 2001
From: Balazs Kezes
Date: Sat, 17 May 2014 10:47:33 +0100
Subject: [PATCH] Implement new mouse selection mechanism
Left button starts the selection. You can double/triple click in order
to select full wor
On 2014-05-21 18:04 +, siebz0r wrote:
> To reproduce:
> echo '\x0e'
> Then try to type something, the characters will be garbled (well
> actually their different characters).
AFAIK this is working as intended. You are enabling the alternate
character set. In tmux/bash you can disable this
On 2014-05-27 14:11 +0100, Nicholas Marriott wrote:
> I see the problem but looks like this fix changes the behaviour if you
> are at EOL, moving up puts you one character in from the end.
I've tested this at EOL and it seems to be working as expected. Can you
explain how does it break for you?
A
On 2014-05-27 13:58 +0100, Nicholas Marriott wrote:
> --- tty-keys.c8 May 2014 07:54:47 - 1.66
> +++ tty-keys.c27 May 2014 12:58:40 -
> @@ -782,8 +782,8 @@ tty_keys_mouse(struct tty *tty, const ch
> m->sy = y;
> m->event = MO
On 2014-05-08 06:31 +, Timothy Allen wrote:
> Some terminals (including older versions of gnome-terminal, and PuTTY
> 0.63) also immediately send a corresponding button-release event,
> which is incorrect but an understandable mistake.
For reference I now add links where other people bumped in
On 2014-05-31 20:59 -0700, Jesse Molina wrote:
> This first bash script has a number of environmental variables which I
> need to exist in the new-session env to get passed on to the
> application/script in which the new session starts.
You can try passing the current environment to the session's
On 2014-06-02 03:53 -0700, Jesse Molina wrote:
> Because a number of my vars have spaces or special characters in them,
> I have to do this nonsense because env output doesn't quote the
> values.
Yeah, bash might not be the best thing to do this. You could for
instance create a custom "env" comman
On 2014-06-02 08:30 +0200, Michael Wild wrote:
> I am the maintainer of the Cygwin package, and I also ran into this
> issue after upgrading the cygwin.dll to 1.7.30-1.
Can you generate strace outputs for the tmux server/clients with both
the old and new DLL and post the results here?
--
Balazs
[+tmux-users]
On 2014-06-03 09:06 +0200, Michael Wild wrote:
> Also, refer to https://cygwin.com/ml/cygwin/2014-06/msg8.html.
> Perhaps this helps you tracking down what exactly triggers this
> behaviour.
That post has the following fragment:
> > Here's the strace I got:
> > cygwin-1.7.30-1:
On 2014-06-06 15:08 +0100, Nicholas Marriott wrote:
> If I have:
> abcdef
> xyz123
> With the cursor on the 1, then if I press C-Space to start the
> selection then press Up, the selection should be "def\nxyz".
> Your diff leaves me with "def\nxyz1" marked instead (although when I
> actually cop
On 2014-05-31 18:17 +0200, Paolo Bolzoni wrote:
> It is possible to replace the current pane with a deattached session?
This question is a bit unclear to me. Can you please elaborate with some
examples what exactly are you trying to achieve?
Thanks!
--
Balazs
--
On 2014-06-04 11:03 -0400, Alan Paul wrote:
> This patch (commit 353d182) broke my vim mousing. I have it turned off
> in vim (mouse=) With this patch, vim now controls my mouse regardless
> of the "mouse=" setting.
To clarify, it isn't vim who is controlling the mouse, but rather tmux
is sending
On 2014-06-06 22:28 +0100, Nicholas Marriott wrote:
> Make sure you are in emacs mode, probably VISUAL or EDITOR is changing
> it for you. It definitely works as I described. IIRC someone added
> some special cases for vi, maybe you are hitting one.
Ah, that makes sense, I'm in vi mode (mode-keys
On 2014-06-01 20:46 +, Danny wrote:
> if i use tmux select-pane it updates fine, but if i use mouse click,
> it doesn't update until another keypress happens (even non-tmux key)
It seems to be working for me. Can you try with a minimal config?
Also can you post the steps in detail what you do
On 2014-06-06 23:58 +0200, Paolo Bolzoni wrote:
> Imagine I am in the session 110 and this is the situation:
> % tmux ls
> 109: 1 windows (created Fri Jun 6 23:51:57 2014) [80x24]
> 110: 1 windows (created Fri Jun 6 23:52:06 2014) [80x24] (attached)
>
> I would like to replace the pane I am usin
ode. Please test both modes!
--
Balazs
>From 49b46f56046bf562e7de084fd6f580e4841e0fa1 Mon Sep 17 00:00:00 2001
From: Balazs Kezes
Date: Sat, 7 Jun 2014 15:05:38 +0100
Subject: [PATCH] Fix the selection behavior bugs
The two bugs:
1. In vi mode the selection doesn't include the last ch
And now I attach another followup patch for the vi mode. Can you
consider/test this one as well? Thanks!
--
Balazs
>From fb35bdaf02c7991510569abcfd690903558c9532 Mon Sep 17 00:00:00 2001
From: Balazs Kezes
Date: Sat, 14 Jun 2014 13:45:06 +0100
Subject: [PATCH] Copy newline when cursor at end
On 2014-06-17 06:50 -0400, shawn wilson wrote:
> Ugh, is there a way to isolate this without docker or some other
> virtualization software?
Yes. Try starting the server via "tmux -L test".
--
Balazs
--
HPCC Systems Ope
On 2014-06-17 21:00 +, Egmont Koblinger wrote:
> Inside tmux (current git) execute
> echo -e '\e(0lqqqk'
>
> Line drawing characters appear on the screen:
> ┌───┐
>
> Now highlight with the mouse (tmux's builtin mouse handling).
>
> Expected behavior: they stay line drawing characters.
>
> Actu
u look into that as well?
Thanks!
[1] http://sourceforge.net/p/tmux/mailman/message/32431246/
--
Balazs
>From c54fd2dad49eae576cc4c274086f9560474addaf Mon Sep 17 00:00:00 2001
From: Balazs Kezes
Date: Sat, 21 Jun 2014 12:37:06 +0100
Subject: [PATCH 1/5] Fix mouse click counting
At this po
On 2014-06-21 14:46 +0300, Juho Pohjala wrote:
> Allow selecting the whole line with 'V'.
I like the idea but your patch only selects the current line. In vim
when you press V you enter line selection mode -- pressing j/k will
still keep full lines selected whereas your patch will continue
selecti
On 2014-06-22 00:58 +0100, Nicholas Marriott wrote:
> That would work for UTF-8 but unfortunately for ACS we need to use
> smacs/rmacs so it has to be an attribute - unless you are suggesting
> sending them for every ACS cell which would be inefficient.
Ah, makes sense, thanks.
> This is probably
On 2014-06-23 08:04 +0100, Nicholas Marriott wrote:
> Well, I'm not sure what we can or should do about that. And in fact if
> we're going to copy without ACS maybe we should continue to display
> the characters without ACS.
Not sure about the "should" part but would something along these lines
wo
On 2014-06-04 11:03 -0400, Alan Paul wrote:
> This patch (commit 353d182) broke my vim mousing. I have it turned off
> in vim (mouse=) With this patch, vim now controls my mouse regardless
> of the "mouse=" setting.
On a second thought I think that commit contains a bug. It should only
affect the
.
But in any case, I'm open to suggestions.
Thanks!
--
Balazs
>From 1aeaf576993fa3773593ad36a3f4aed41aa06ada Mon Sep 17 00:00:00 2001
From: Balazs Kezes
Date: Sat, 21 Jun 2014 12:37:06 +0100
Subject: [PATCH 1/3] Fix mouse click counting
At this point this isn't used anywhere
On 2014-06-23 11:21 +0100, Nicholas Marriott wrote:
> Er, this time with pb != NULL. Doh. This is instead of "[PATCH 2/5]
> Refactor input_mouse()" of course.
I've rewritten my patches and I'm not modifying this file anymore. I
refactored because I needed one of the new variables in one of the
sub
On 2014-06-27 17:34 -0600, Jeff wrote:
> If it is possible, I want xterm's title to display tmux's current and
> previous pane titles. Ideally it would work for as many panes as there
> are, but displaying the current and previous panes would be fine.
I think displaying all of them is actually sim
On 2014-07-15 22:00 -0400, Bryan Mills wrote:
> With tmux, the escape keys aren't recognized. Presumably something in
> the screen-256color termcap is off.
$ infocmp screen-256color | grep kf
kdch1=\E[3~, kend=\E[4~, kf1=\EOP, kf10=\E[21~,
kf11=\E[23~, kf12=\E[24~, kf2=\EO
On 2014-07-17 17:32 +, eydaimon wrote:
> Similar to command such as `has-session` this command would simply
> display whether the current terminal is already in a tmux session.
How about just checking for the TMUX environment variable?
$ function tmux_in_session() { ! test -z "$TMUX";
On 2014-06-30 02:11 +, Eric Christopherson wrote:
> However, it seems that if I left-click within such a pane after having
> scrolled, the left-click down causes an additional scroll event
Some features were stripped from Marcel's original patch when it was
applied to tmux. Unfortunately the c
On 2014-07-14 18:42 -0700, Sean Hafeez wrote:
> In zsh, hitting ESC + some vim command like b (back word) works, $
> works, etc. Hitting ESC 0 does not take me to the start of the line.
> Everything else seems to work.
Just to confirm, this doesn't work only in tmux, right? If you quit tmux
and tr
On 2014-07-17 23:14 +, C_G wrote:
> Running into an issue with processes spawned by tmux; I've got "stty
> -ixon" in the environment of my parent shell, Ctrl+S is not being
> trapped, as expected, but the moment I run tmux, even if it only
> spawns my shell, this stops being respected.
I'm not
On 2014-07-21 11:05 +, Adam Carrgilson (NBI) wrote:
> When a wall or write message is sent through to a terminal inside of
> tmux, any further interaction with the terminal completely resets
> things such that it appears that the message was never there rather
> than the default terminal behavi
On 2014-07-17 18:02 +, Seth Milliken wrote:
> I'd like to create tmux bindings to "toggle" a window in and out of
> the current layout by using `join-pane` and `break-pane -d`
> respectively. The problem is that when I toggle the window out with
> `break-pane -d`, the resulting window does not
On 2014-07-22 09:21 +, Adam Carrgilson (NBI) wrote:
> I'm running on CentOS 6 and running the "wall" command, or the "write"
> command sending a message to any of the terminals listed out of the
> "who" command. Any message sent appears on the terminal but after any
> interaction with that term
On 2014-07-13 00:59 +0300, Juho Pohjala wrote:
> Please have a look at the updated patch.
Thanks, this works surprisingly well! Some nits: in mode-keys.c you
should also update the mode_key_cmdstr_copy array. Also, it would be
nice if you could leave the line mode via v (normal mode) or ^v (block
> Commit 193b6bcf36dda3754c99beb0dcc3dfdfceebdb09 looks suspect.
I don't think that commit affects this as it was committed after 1.9a
was released.
> Shift-F1 - Shift-F8 are no longer being handled properly by Tmux. A
> tilda, ~, is simply printed to the terminal, rather than the keypress
> bei
On 2014-08-04 13:44 +, Sebastian wrote:
> set-window-option -g window-status-separator ' | '
>
> and many windows open, I have problems selecting windows. At least
> when trying to click at the end of the window name, the next and not
> the clicked window is selected. When I set window-status-s
[-ticket]
On 2014-08-08 13:13 +0100, Balazs Kezes wrote:
> It seems this is a small omission in the code. I've attached a patch
> fixing it. Please test.
Now attached for real.
--
Balazs
>From c25af71569e4e14f84c498b5980559e4ae9c801a Mon Sep 17 00:00:00 2001
From: Balazs Kezes
On 2014-08-08 13:23 +0100, Thomas Adam wrote:
> Use size_t rather than int for the strlen() call, please.
Ah, of course. Fixed.
--
Balazs
>From c25af71569e4e14f84c498b5980559e4ae9c801a Mon Sep 17 00:00:00 2001
From: Balazs Kezes
Date: Fri, 8 Aug 2014 05:06:35 -0700
Subject: [PATCH] Fix
On 2014-06-07 15:16 +0100, Balazs Kezes wrote:
> OK, I've attached a patch which fixes the behavior for the vi mode and
> also fixes the left key bug for the emacs mode. Please test both
> modes!
Hi Nicholas!
I believe you missed this patch, can you reconsider?
Thanks!
--
On 2014-08-08 04:18 +, Scott Rochford wrote:
> Please add a feature similar to screen's 'log' command which allows
> you to set up log files of each window using a filename template.
I have a very experimental patch, just for myself, adding a similar
feature. The implementation is quite easy,
On 2014-10-17 17:25 -0700, Leigh Stoller wrote:
> Hi there, I have a tmux+emacs problem. Two really. The first is the ^H
> vs ^? issue. I understand that I can bind erase to ^? on all my
> machines (many, many), but I am curious as to why tmux generates ^D
> when I press the delete key (bound to ^H
On 2014-09-18 16:45 +0530, chokden wrote:
> While doing a objdump -x filename.xyz, i cant seem to scroll up or
> down. The scrolling of mouse triggers the history of command i have
> writen before.
Which version of tmux are you using? Have you tried the HEAD version?
--
Balazs
-
On 2014-09-30 09:25 +, Azrael3000 wrote:
> Tmux-resurrect apparently has a problem with restoring the layout if a
> pane was maximized.
I'm not familiar with tmux-resurrect but how about it unzooms before
saving the layout and then rezooms if the layout was zoomed? At least
until this is not f
[+tmux-users]
Please keep tmux-users posted because otherwise you'll get less help
because others don't see your responses.
On 2014-10-18 18:50 +0530, chokden wrote:
> i am using tmux 1.9a.
> i compiled it from source forge.
Have you tried the git HEAD version? There were some mouse related
chan
On 2014-10-18 07:38 -0700, Leigh Stoller wrote:
> > Also, what happens if you run "cat", press ^V Backspace, and then
> > press ^V Delete. What codes were generated outside tmux and what
> > inside tmux?
>
> Outside both say ^H but inside both say ^?
Outside ^H and inside ^? sounds fine but it's b
[+tmux-users]
Please be respectful of others and *keep* tmux-users posted! Try
pressing/clicking on reply-all in your email client.
On 2014-10-18 19:35 +0530, chokden wrote:
> here is my .tmux.conf
> ...
> set -g mode-mouse off
You have disabled the mouse mode. Most probably your terminal emulat
On 2014-10-21 10:52 +0530, chokden wrote:
> I tried setting set -g mode-mouse off, but when i open a new pane in
> terminal, the shell output doesnt show all of it. Instead the whole
> tmux screen moves up and down.
So what happens if you enable mode-mouse? Please do this in a clean a
tmux. Start
On 2014-10-28 17:42 +0100, meino.cra...@gmx.de wrote:
> I login on my Beaglebone via ssh using this command:
> ssh -t root@ screen -R -d
> ...
> What is the above ssh-command in case of tmux to acchieve the same as
> with using screen ?
Have you tried "ssh -t root@ tmux attach -d"? Or even
better:
Don't force adding spaces after/before the window list. This can rather be
achieved by changing the status-left/status-right options. In fact when
status-justify is right meaning we place the window list to the right, we will
see two separating spaces by default: one for window-status-separator and
Steps to reproduce:
1. Create a vertical split.
2. Assuming we are running bash in the left pane, enter this:
echo -e 'xy\e[D\e[@'
# or
echo -e 'xyz\e[2D\e[P'
3. Make the left pane smaller:
tmux resize-pane -L 5
4. Observe the extra newline. This is ugly.
This happens because whenever
Steps to reproduce:
1. Create a vertical split. Make the left one quite narrow.
2. Assuming we are running bash in the left pane, enter some text so
that it is at least 2-3 lines long.
3. Press home (or C-a) then enter (or escape-# to comment out the line).
4. Make the left pane bigger
tmux resi
On 2014-11-10 20:04 +, Nicholas Marriott wrote:
> I reverted the grid-view.c change because it breaks insertion. Try:
> $ tmux new 'tput ich 10'
Oh, sorry about that. What a silly mistake, the 4th parameter
underflows in grid_move_cells:
...
#1 0x0042a3f9 in log_fatal (msg=0x46e461 "
On 2014-11-14 10:42 -0800, Locane wrote:
> I've done a lot of searching around online and tried a number of
> CentOS based preferences, but they seem to be overridden by tmux,
> somehow.
>
> So back to my original question - does tmux have a powersave or screen
> time out preference? If not, can a
Hey Nick!
Sorry, but this is still broken. :(
You can reproduce it in bash, if you type "a b" then go to the beginning
press "c": you can see that the "b" has disappeared and all you can see
is "ca".
Here's a patch to fix this.
diff --git a/grid-view.c b/grid-view.c
index a34c5a0..defb86d 10064
e code isn't using it for anything. I've attached a patch for
removing the per pane open cwd.
--
Balazs
>From 2a0ad4aa4ae913e8cab2f5078774e8cf3ec8e5af Mon Sep 17 00:00:00 2001
From: Balazs Kezes
Date: Sat, 29 Nov 2014 20:05:00 +
Subject: [PATCH] Don't keep open the initial dir for
Disregard my previous patch, after a little bit of thinking I came up
with this:
diff --git a/grid-view.c b/grid-view.c
index a34c5a0..0b890d8 100644
--- a/grid-view.c
+++ b/grid-view.c
@@ -184,9 +184,10 @@ grid_view_insert_cells(struct grid *gd, u_int px, u_int
py, u_int nx)
px = grid_vi
1 - 100 of 108 matches
Mail list logo
