(08/12/2011 11:07 AM), Julius Plenz wrote:
Hi!
I'm not quite sure what to make of this. Both screen and tmux won't
handle terminfo's el and ed (clear to end of line/display) the way
I think it should work. Consider:
echo `tput setab 2`foo`tput el`\r
I would expect to find the line
On 05/28/2011 03:28 PM, Helmut Schneider wrote:
While from a shell you can put single quotation marks around the comman when
you e.g. put your script into an alias or call it from another script there
is/seems no way to do that successfully.
Your sentence here doesn't make much sense to me,
(05/18/2011 08:01 AM), Randy Stauner wrote:
I have tried to recreate this according to your steps and it does not
happen to me,
things look as you would expect them.
I tried zsh as well--no change.
It does seem odd that even the prompt disappears in your example.
This probably won't
(05/18/2011 11:18 AM), Robin Lee Powell wrote:
Huh. My tmux.conf doesn't seem to actually *work*; I have to
manually do a :set-window-option alternate-screen when I launch
tmux for it to actually be set correctly. That's a bit odd, isn't
it? So in the tmux case there's a step for that,
(05/18/2011 11:18 AM), Robin Lee Powell wrote:
http://teddyb.org/~rlpowell/media/public/tmp/screen.txt
http://teddyb.org/~rlpowell/media/public/tmp/tmux.txt
Do you still get the same effect if you set your prompt to something
that doesn't contain any special character sequences? I don't see
(05/18/2011 01:19 AM), Robin Lee Powell wrote:
It's vim, not less, and yes, it appears to be overwriting.
The issue is that I don't have this problem in screen.
OK, screenshots of screen and tmux (in alternate-screen off mode).
Process is:
[new window]
# seq 1 100
# vim
[type some
(05/18/2011 01:28 PM), Micah Cowan wrote:
(05/18/2011 01:19 AM), Robin Lee Powell wrote:
It's vim, not less, and yes, it appears to be overwriting.
The issue is that I don't have this problem in screen.
OK, screenshots of screen and tmux (in alternate-screen off mode).
Process is:
[new
(05/18/2011 01:47 PM), Robin Lee Powell wrote:
On Wed, May 18, 2011 at 01:43:38PM -0700, Micah Cowan wrote:
(05/18/2011 01:28 PM), Micah Cowan wrote:
(05/18/2011 01:19 AM), Robin Lee Powell wrote:
It's vim, not less, and yes, it appears to be overwriting.
The issue is that I don't have
(05/18/2011 01:47 PM), Robin Lee Powell wrote:
I'm using the tmux from CVS HEAD. Perhaps you can try that out?
Certainly.
Okay, good news: I grabbed a copy of tmux 1.4 from sourceforge, built
and tested with it. I can reproduce. So it sounds like it's a problem
that has since been fixed,
(05/18/2011 02:56 PM), Robin Lee Powell wrote:
Terminal size is 80x25, because I believe that to actually be
relevant to the behaviour one gets on catting them back out.
Well, what I meant (and should have said) was, provided that the lines
all start where they're meant to.
(05/18/2011 03:55 PM), Robin Lee Powell wrote:
On Wed, May 18, 2011 at 03:27:20PM -0700, Micah Cowan wrote:
A workaround should be to alias vim to 'clear; vim' or something.
Ah. Yes, that works; with older tmux I had tested clear and it
broke in the same way vim does, but with HEAD
(05/18/2011 04:07 PM), Micah Cowan wrote:
(05/18/2011 03:55 PM), Robin Lee Powell wrote:
On Wed, May 18, 2011 at 03:27:20PM -0700, Micah Cowan wrote:
A workaround should be to alias vim to 'clear; vim' or something.
Ah. Yes, that works; with older tmux I had tested clear and it
broke
On 05/11/2011 07:32 PM, Nicolas Bigaouette wrote:
Hi all,
I'm using tmux to launch long simulations. It has served me well.
On some systems, I have set ctrl+a as the main key, while on others
it's ctrl+s. So to detach from tmux it should be either ctrl+a,d or
ctrl+s,d. Unfortunately, I
On 04/20/2011 12:49 AM, LEVAI Daniel wrote:
On Mon, Apr 18, 2011 at 20:14:09 +0100, Nicholas Marriott wrote:
if you like you can run tmux in script(1)
There is not much to see:
The key words being run _tmux_ in script. You obviously didn't, or
we'd be seeing status draws.
And then attach
(04/19/2011 05:09 AM), hubert depesz lubaczewski wrote:
hi,
have tmux (1.4), and following problem:
My tmux is split into 3 panes, like this:
++
||
++
||
++
||
||
||
||
|
On 04/18/2011 01:19 AM, LEVAI Daniel wrote:
On Wed, Feb 02, 2011 at 11:06:14AM +0100, LEVAI Daniel wrote:
On Tue, Feb 01, 2011 at 20:05:40 +, Nicholas Marriott wrote:
Are you sure it happens when the cursor blinks? If you make the
cursor
steady does it stop happening? What if you increase
(04/09/2011 09:52 AM), Tiago Resende wrote:
OK, now this is embarrassing. This time I got it right, I swear.
Still a bit wrong, I'm afraid :\
$ infocmp $screen_terminfo | sed \
-e 's/^screen[^|]*\|[^,]*,/screen-it|screen with italics
support,/'
The \| above should be |.
(04/14/2011 03:59 PM), Robin Lee Powell wrote:
I did that, and greated a new window, and set -w utf8 returns off,
and after doing set -w utf8 on it still returns off.
Well, it should, shouldn't it? set -w utf8 doesn't mean show the
value of the utf8 setting, it means toggle the value of the
On 03/25/2011 10:49 AM, Paul Grove wrote:
1. Ran xterm
2. Checked my $TERM was equal to 'xterm'
3. Checked my Ctrl-Arrow keys - they worked
4. Ran tmux (from within xterm)
5. Checked my $TERM was equal to 'screen'
6. Checked my Ctrl-Arrow keys - they dont work
Incidently, the same
(03/24/2011 01:51 AM), Walter Dnes wrote:
IANACP (I Am Not A C Programmer), so I'm not certain of this, but
{ScrollLock} is the only one of the three that is normal. I.e.
pressing it generates a one-byte scancode and releasing it generates
that one-byte scancode + 0x80. Is there a way to
(03/24/2011 10:58 AM), Paul Grove wrote:
Does anyone know the correct config to get the mouse to behave correctly
in Vim?
so far I have been have to get visual mode to work, but cannot drag the
splits between buffers.
Probably need to put ttymouse=xterm2 in your .vimrc.
--
HTH,
Micah J.
On 03/23/2011 11:50 AM, Nicholas Marriott wrote:
These are usually the keys that are changed when the keypad is put into
cursor mode, these are all treated as up, down, left and right by tmux.
Try eg
set -g terminal-overrides '*:kUP5=\eOA'
That should be \e[OA shouldn't it?
--
Micah J.
On 03/23/2011 11:43 AM, mbm329 wrote:
Thanks for the pointer.
Using PuTTY, here's the output:
$ cat
^[[A
^[OA
A
How about for: tput smkx; cat; tput rmkx? That'd be the situation tmux
would actually see them in.
--
Micah J. Cowan
http://micah.cowan.name/
On 03/04/2011 05:22 AM, Vaibhav Bedia wrote:
Setting TERMINFO manually to /usr/share/terminfo worked.
My suspicion is that the ncurses you linked against with tmux 1.4, has
the wrong set of default paths to search, while the one you linked
against with 1.3 had the right ones. Was probably a
(03/04/2011 08:53 AM), Kevin Goodsell wrote:
You're not using a very wide window by any chance, are you? The
mouse-position encoding scheme only supports a limited number of
columns, and people with high-resolution monitors have been running
into the limitation. This would make the right side
(03/04/2011 11:29 AM), Micah Cowan wrote:
(03/04/2011 11:19 AM), Kevin Goodsell wrote:
It looks like 94 would be the limit for applications that are expecting
the old mouse tracking with a terminal that is reporting extended mouse
tracking. The two modes are compatible up to that point
(03/04/2011 12:39 PM), Micah Cowan wrote:
Part of the problem I encountered during debug-time was also that tmux
set -g mouse-utf8 off doesn't work if the socket isn't default (it
sets the value in default instead). It used to check $TMUX for where
to connect (I fixed it to do so some time
(03/02/2011 09:10 PM), Vaibhav Bedia wrote:
Hi,
I am using tmux-1.4. I just started getting the error (open terminal
failed: missing or unsuitable terminal: xterm) when trying to attach
to a pre-existing session.
That error message would indicate that a terminfo database entry can't
be
You can also type (say) echo -e '\e\\' blindly. You're still getting a
prompt, it's just being sent to the window title, like everything else.
\e\\ (and its equivalent \e]0;) is a pretty special case, though, I
doubt there are other sequences that can freeze up the term so solidly.
They're
(01/24/2011 02:41 PM), clemens fischer wrote:
On Tue-2011/01/18-21:47 clemens fischer wrote
in gmane.comp.terminal-emulators.tmux.user
(MID srah08xli6@nntp.spotteswoode.dnsalias.org):
tmux github version from today (the master branch), on Linux
2.6.36.3-spott i686 and
(01/21/2011 12:38 PM), Nicholas Marriott wrote:
Perhaps from Screen, where it has the same effect as OSC 0, 1 and 2.
Probably. Don't see any harm in nuking it anyway if necessary.
I do. I'm pretty sure that there are at least a few people depending on
this behavior, and sticking with a simple
On 12/23/2010 11:11 AM, Nicholas Marriott wrote:
You mean a command to make like the output came from the application
inside tmux?
Yes, exactly! :)
--
Micah J. Cowan
http://micah.cowan.name/
--
Learn how Oracle Real
(12/21/2010 11:27 AM), Dan Tulovsky wrote:
Is there a way to send a Reset in tmux? Sometimes (for example, when
using serial consoles) the terminal gets screwed up and the only way
to fix it is to reset it.
This is cmd+R in Terminal on the Mac. I think it's just C-a r in screen.
Default
(12/21/2010 12:26 PM), Dan Tulovsky wrote:
Hmm.. so I mapped it back to the default, but it doesn't actually
work. As far as I can tell, nothing happens. The currently broken
terminal (after a reboot via serial console of the remote server) is
not scrolling. All output is on the very last
(12/07/2010 03:11 PM), Nicholas Marriott wrote:
Hi
What tmux version?
What is TERM set to outside tmux in the console?
Probably need the version of your libevent, too.
--
Micah J. Cowan
http://micah.cowan.name/
Currently, even-horizontal will split a 161-column terminal into 79
and 81, rather than 80/80; and even-vertical will split 44 lines into
20 and 22. The attached patch fixes this. Let me know if it looks
alright, and I'll commit it.
I noticed the default value for main-pane-width is set to 81,
On 06/09/2010 12:00 PM, Tomasz Pajor wrote:
Hello,
I got window split to 3 panes.
Is there a way to make current pane full screen, and after i finish working
with it, bring it back to the previous size?
break-pane (prefix !) followed by join-pane get me approximately
similar behavior.
For
clemens fischer wrote:
On Sun-2010/02/28-21:28 Nicholas Marriott wrote:
You probably want to exec tmux new-session, or use tmux new-session
-d instead.
I always use
exec /usr/local/bin/tmux ${TMUX_OPTIONS} attach-session
without checking for existing sessions on the local
I created a Debian source package for tmux 1.2, for those who are
interested. There's also a .deb for i386.
http://micah.cowan.name/tmux-debs/
--
Micah J. Cowan
http://micah.cowan.name/
--
Download Intel#174; Parallel
tilde wrote:
Simple question:
someone knows where i can find a list of colors code indexed 0-255? I
can't find it anywhere!
or maybe an alternative to this for say tmux how to set the color I want?
There's tools/256colors.pl in the tmux source tree. It doesn't give the
indexes, but studying
trapd...@trapd00r.se wrote:
On 12/03/10 02:49 +, Nicholas Marriott wrote:
This one shows the numbers too:
That was nice. Anyone know how those could be used like we use regular
colors; i.e echo \033[32m foo in an 256-color-capable terminal?
Read the source for those scripts? They're
Trent W. Buck wrote:
Nicholas Marriott nicholas.marri...@gmail.com writes:
OpenBSD is the primary repository at the moment because it is easier
for me, SF is sync'd up fairly often by tcunha.
Do you have any plans to switch to a different VCS (e.g. git, svn) for
the primary repo?
He
Trent W. Buck wrote:
It seems that tmux is more clever than I am.
I open a new window (running bash). Therein, I run emacs -Q -f ielm.
At this point, tmux says the title is emacs. Good! Now, I attempt to
have emacs set the window title to something more meaningful than
emacs, such as the
clemens fischer wrote:
High quality indeed, and works as expected! Thank you very much, Micah!
One question: it applied with offsets to portable HEAD from yesterday:
snip
How come?
I wrote it to apply after the last couple patches I'd recently
submitted. I figured it would apply without
Robin Lee Powell wrote:
On Thu, Feb 18, 2010 at 01:39:15PM -0800, Micah Cowan wrote:
The following should bind prefix J to join the current (already
finished) selection with spaces:
bind-key J run-shell 'tmux save-buffer /tmp/.tmux-exchange; tr \n
/tmp/.tmux-exchange /tmp/.tmux-exchange
line determines the
right border of the block.
I noticed too late that this problem has been adressed and possibly
fixed in:
Micah Cowan: [Patch] BUG: clipped copies on wrapped lines
Message-ID: 4b7ae24e.6020...@cowan.name
Archived-At:
http://permalink.gmane.org/gmane.comp.terminal
clemens fischer wrote:
Hi,
I am very glad that tmux has rectangular copies now! But a problem as
well: in the following, try to cut out the block
bbb from aaa bbb
y xxx y
22 111 22
At least in vi-copy mode on linux, the shortest line
Change (inspired by an IRC discussion with Nicholas):
Typing the end-of-line key once will bring you to the end of the textual
content of the current row on the screen.
If the current row contains only a portion of a line had wrapped onto
the next row, then typing the end-of-line key again will
Okay, these diffs have been rebased to before the copy-output-merge
stuff (and to the latest OpenBSD changes), and reworked a bit. They
should be applied in the order: word-separators, then cmd-prefixes.
--
Micah J. Cowan
http://micah.cowan.name/
Index: mode-key.c
This patch introduces support for the quick jump-to-char commands from
vi, for tmux's copy mode. They are bound to the same keys in both vi
mode and emacs. This patch expects to be applied after the other two
patches I recently rebased (cmd-prefixes and word-separators).
The new bindings let you
If you select some text from a wrapped line, where the selection is of
stuff before the final wrap of the line, the final chraracter gets
stripped on copy. This patch fixes the problem for me.
--
Micah J. Cowan
http://micah.cowan.name/
Index: sf/window-copy.c
Nicholas Marriott wrote:
I'll look at all your diffs in detail later tonight but I can tell you now
there is no way a macro like this is going in :-).
Better suggestion, then? ...I could dupe the for-loop a buncha times,
but the macro looks cleaner to my eyes.
Or did you just mean the first,
Next-word, when it wraps at the end-of-line, will never stop at the
first character, even if it's a word character. This tiny patch fixes that.
This patch is meant to apply after the word-separators patch, though the
glitch is from before that. The word-separators patch merged the two
search
This patch allows the user to specify what characters are considered
word separators for the purposes of the next and previous word
commands in copy mode (bound to M-b and M-f in emacs-copy; w, b and e in
vi-copy).
Since the space character is no longer guaranteed to be one of the word
separator
Micah Cowan wrote:
+ screen_write_start(ctx, wp, data-screen);
+ ox = data-screen.cx;
+ oy = data-screen.cy;
+
+ /* If the history has changed, draw the top line.
+ * (If there's any history at all, it has changed.) */
+ if (screen_hsize(data-backing
Here's a diff for the manpage to go with the diff for the code.
I've also included a convenience diff against the processed manpages,
mans.diff, for an easier view of what I've changed.
--
Micah J. Cowan
http://micah.cowan.name/
--- /tmp/old 2010-02-13 21:00:37.921671553 -0800
+++ /tmp/new
New version of the patch.
Nicholas Marriott wrote:
Hi
Thanks for the diff,
n retains the sense of the last search (repeats in the same direction), so
this
is to reverse the sense of the last search?
+if ((data-searchtype == WINDOW_COPY_SEARCHUP)
+
Nicholas Marriott wrote:
Hi
Thanks for the diff,
n retains the sense of the last search (repeats in the same direction), so
this
is to reverse the sense of the last search?
Well, it's to search in the reverse of the last actually typed search.
So, if you searched up, n will continue
Nicholas Marriott wrote:
- Any time I view a manual page, use the less pager or the vim
editor, I get a fresh screen page. This disturbs me somewhat, because
I'm used to go up in copy-mode, select some text and paste it where
it's needed.
I don't understand what you mean by this.
I
clemens fischer wrote:
Micah Cowan wrote:
I think he's referring to the alternate buffer.
clemens, one way of working around that would be to simply suspend
less or vim (or whatever) with C-z, enter copy-mode and grab what you
want, then exit copy-mode and resume your app.
Oh, I'm doing
clemens fischer wrote:
The problem I see looking at lines 1189pp @ input.c is the GRID_HISTORY
flag, which is supposed to be off after handling the sm sequence. I'm
not sure if it should stay on if a new option disables the saved_grid.
My guess would be that this flag controls whether or not
Micah Cowan wrote:
Micah Cowan wrote:
Nicholas Marriott wrote:
Hi
This is a cool idea, tmux should definitely just do the right thing.
We could call realpath() to get around the // issue. If we did it on path in
main.c and that would clean up TMUX as well.
Alright.
I'm thinking it may
G...
One word: compiz.
Didn't even realize I had it on this machine (IT provided the image).
The windows weren't doing cool desktop-effect things, so I didn't even
think about it. When I discovered it, I disabled it, and bam! It works
as expected now. Yeesh.
--
Micah J. Cowan
Nicholas Marriott wrote:
Bad memory accesses occurs when we get to the call to grid_compare()
after the out: label. Inside grid_compare(), the inner loop assumes
that both grids use their entire horizontal space on each line.
Hmm. It explicitly checks they are the same size (gla-cellsize !=
Nicholas Marriott wrote:
Ugh, another copy mode bug.
Thanks for your diff.
We need to redraw two lines because if the $ is at the end of the line it will
have been scrolled.
I think it is enough just to change window_copy_write_line, although I'll move
the check up a bit I think.
It
Since October, Ctrl-Up and Ctrl-Down allows the user to scroll up and
down by single lines. The vi-copy mode provides an additional set of
bindings for this, to K and J.
Vi has had this feature bound to C-y and C-e for ages, so I've written a
patch to use these instead. Well, instead as far as
Micah Cowan wrote:
Since October, Ctrl-Up and Ctrl-Down allows the user to scroll up and
down by single lines. The vi-copy mode provides an additional set of
bindings for this, to K and J.
Vi has had this feature bound to C-y and C-e for ages, so I've written a
patch to use these instead
67 matches
Mail list logo
