(08/12/2011 11:32 AM), Julius Plenz wrote:
> Hi, Micah!
>
> * Micah Cowan [2011-08-12 20:19]:
>> IIRC, screen _can_ support it, if the host terminal does.
>
> True, setting "bce on" from within screen works just fine. Question
> remains whether it's ST
(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
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 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
(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 th
(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.
> http://teddyb.or
(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, s
(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 overw
(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
(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
> [ty
(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
(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 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
On 05/17/2011 10:46 PM, Robin Lee Powell wrote:
>> "Replaces"? No, it'll scroll it off, I'd think. Which is what you
>> said you wanted - all the backscroll intact.
>
> No, that is absolutely not what happens.
Okay, well, I don't know what to tell you, because when _I_ do it (with
alternate-scr
On 05/17/2011 10:21 PM, Robin Lee Powell wrote:
> On Tue, May 17, 2011 at 09:16:16PM -0700, Micah Cowan wrote:
>> On 05/17/2011 06:10 PM, Robin Lee Powell wrote:
>>>
>>> I came, over the years, to rely very much on screen's backscroll
>>> behaviour[1], so
On 05/17/2011 06:10 PM, Robin Lee Powell wrote:
>
> I came, over the years, to rely very much on screen's backscroll
> behaviour[1], so certain aspects of tmux's behaviour have surprised
> me, and I'm wondering if they can be changed.
>
> 1. When I quit "less", it goes away. I'm used to the outpu
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". Unfortu
On 05/10/2011 09:12 AM, Pierre Habouzit wrote:
> use-case: save-buffer "|xclip"
tmux already does this; see the "show-buffer" command. E.g.,
tmux show-buffer | xclip
-mjc
--
Achieve unprecedented app performance and
On 04/22/2011 05:26 PM, Randy Stauner wrote:
> I first tried using send-keys (bind-key -t vi-copy send-keys ^ ' ' $ Enter)
> but send-keys isn't a valid command in copy-mode.
Drop the -t vi-copy; you want to use a normal-map binding so you can use
the normal-map command (of course, this means you'
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 atta
(04/19/2011 02:02 PM), David Chanters wrote:
> hi all,
>
> when i split a window in tmux, and i select some contents in a pane, i
> can currently select beyond the boundary of the split. is there a way
> to make tmux to box the select to not go outside the split region -
> much like how selecting
(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:
> ++
> ||
> ++
> ||
> ++
> ||
> ||
> ||
> |
(04/19/2011 10:34 AM), Peter John Hartman wrote:
> Hence, I for one would love to see tmux figure out a way to work with
> normal (urxvt at least) terminal selection!
urxvt 9.06 (from Ubuntu) works fine for me. Perhaps you're using an
older version? Or perhaps Ubuntu introduced a fix, I dunno.
E
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
(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
(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
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
On 03/24/2011 11:52 PM, Walter Dnes wrote:
> On Thu, Mar 24, 2011 at 10:07:22AM -0700, Micah Cowan wrote
>
>> It isn't. If the terminal doesn't send something for the key (which
>> you would've seen in "cat"), then tmux can't see it.
>
>
(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,
Mica
(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
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/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?
--
Mica
Hey Nicholas, please check this over for me.
This patch is intended to fix the wide-chars wrapping thing. I've
attached a simple script to illustrate the problem, and a patch.
The patch is two parts: one is to let wrapping occur when the final wide
character "overlaps" the end of the line; the ot
(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
(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 compat
(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.
Yeah, that's what I got from a little further
(03/04/2011 10:37 AM), Kevin Goodsell wrote:
> On Fri, Mar 4, 2011 at 10:21 AM, Micah Cowan wrote:
>>
>> Good catch, i'd forgotten about that; that seems to be the problem (161
>> columns). Strange, I've always used a 161-column term (for side-by-side
>> 80
(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 si
On 03/04/2011 07:21 AM, Ty Haller wrote:
> I just installed libevent and still cannot find event.h
You need to install the for-development package, the one that contains
the header files. Most binary package systems split library packages
into the base package, for linking programs that have alrea
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 co
Not sure when this broke, but I just noticed today with fresh CVS, that
if I click on the right-side pane in a left-right split, it doesn't
select; selecting the left while in the right works.
Mouse mode appears to still be active (since gnome-terminal shows a
different cursor for the mouse when m
(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 speci
(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 ):
>
>> tmux github version from today (the master branch), on Linux
>> 2.6.36.3-spott i686 and rxvt-unicode-256color-9.07-10.
>>
>> I have the followin
(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 sim
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
On 12/23/2010 10:49 AM, Dan Tulovsky wrote:
> On Tue, Dec 21, 2010 at 3:56 PM, Nicholas Marriott
>> There is no reason we couldn't have a command (or an argument to
>> refresh-client) to output rs0 etc but frankly reset(1) generally does a
>> better job of it.
It can't do a better job of it _insi
(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 las
(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 +R in Terminal on the Mac. I think it's just C-a r in screen.
Default
(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 11/12/2010 08:25 PM, Nicholas Riley wrote:
>>From time to time, when I type into a window, only the cursor position
> updates; the window contents don't. I can unfreeze the window by moving
> it either to another position in the session or to a different session.
>
> I've found a few mention
Hi. The behavior you've described below doesn't strke me as odd. I get
the same results in a naked xterm, without tmux.
1. command to produce output (I used "man man | cat")
2. shrink the window so it is smaller, vertically
3. Resize it to its original form
4. The output reappears with prompt afte
So, I've encountered an interesting glitch when drawing left-right
splits, if the left pane has wide characters that start on the column
just before the split. This situation can occur if you start with a
non-split screen, cat some wide-character text to the screen, and then
create a left-right-spl
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 ( !) followed by join-pane get me approximately
similar behavior.
For th
I wouldn't; the current language implies it still works if you switch to
another pane and type something; "the current pane" could make it sound
as if it only works in the pane that was current when you set the window
option. And anyway, any pane that can receive input _is_ the current
pane at the
This patch causes bindings of C-Space (really C-@) to display as
C-Space, per Nicholas's request.
Testing: verified that bindings of C-@ and C-M-@ show up as C-Space and
C-M-Space, and that binding @ remains as @.
Note: I committed the patch that fixed the binding of C-Space directly,
because its
his lets enter work from outside because otherwise ctx->curclient is
> NULL, yes?
>
> Looks fine and works good for me, go for it.
>
>
> On Fri, May 21, 2010 at 01:17:59AM -0700, Micah Cowan wrote:
>> On 05/20/2010 08:17 PM, Micah Cowan wrote:
>>> Okay, I now
On 05/20/2010 08:17 PM, Micah Cowan wrote:
> Okay, I now understand why that is: copy-selection needs to know which
> session's paste buffers should be affected, and it gets this information
> from the passed-in instance of "struct client", which of course is NULL
> for
nformation from elsewhere; probably the TMUX env var.
-mjc
On 05/20/2010 03:34 PM, Micah Cowan wrote:
> I've been playing around with scripting certain actions in copy-mode,
> and have run into what I believe to be a bug in recent CVS tmux.
>
> If I run the command:
>
>
I've been playing around with scripting certain actions in copy-mode,
and have run into what I believe to be a bug in recent CVS tmux.
If I run the command:
tmux copy-mode \; send-keys 0 Space e Enter
(which in vi bindings should jump to the start of the line, start
selection, move to the end
Nicholas Marriott wrote:
> And it is surprising the amount of variation: I have seen others who use
> `, or function keys, quite a few seem to go for C-x or C-s, and some
> even for C-z.
Using C-s sounds like asking for trouble. :)
> So (and I know you didn't suggest this but some people might be
Martial Boniou wrote:
> I presume you're ok with C-b. If not, what other prefix can you advice?
No, personally I hate C-b: too much finger-stretching for such a
commonly-used function. I use C-a, which I became accustomed to in
screen. This works fine for me, since I use vi-mode in my shell (and v
Nicholas Marriott wrote:
> C-` generates the same sequence as C-space, bind that.
And as C-@ (which is the canonical form, I think)
Note that, if you ever use Emacs, C-space (or C-@ or C-`, however you
invoke it) is a frequently-needed keybinding.
--
Micah J. Cowan
http://micah.cowan.name/
---
Romain Francoise wrote:
> While doing some testing I found the following crash. It looks
> related to the copy/output mode rewrite:
> It can easily be reproduced by maximizing a terminal which contains
> a tmux window showing `list-keys' output.
Thanks, I believe I just fixed it in SourceForge.
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 th
Martin Roecker wrote:
> Hi,
>
> I haven't found a possibility to change the way of how window activitiy
> is notivied in the statusbar. I want to define foreground and background
> colors manually, instead of only having the current colors inverted. Is
> this possible?
Not currently. The relevant
For posterity/anyone coming across this in archives, the latest version
of this script is always at
http://micah.cowan.name/hg/wtitle/file/tip/wtitle
Micah Cowan wrote:
> Micah Cowan wrote:
>> So, I recently discovered that if automatic window-renaming is on
>> (default), it&#
clemens fischer wrote:
> On Fri-2010/03/12-03:42 Micah Cowan wrote:
>
>> I also whipped up a small shell script to help me find color values
>> I like. I've attached it here.
>
> Does "color-trans.sh" really work in your bash?
Yes, it does.
> In
Stealth wrote:
> Is there a way to load tmux using crontab?
>
> Example: I do plenty of running things in tmux (namely IRC), and would
> like the sessions created automatically when my server reboots. I did a
> test using "@hourly tmux new ", but when the hour changed I
> didn't have a new session
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® Parallel Studi
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
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 studyi
Brought the patch in-line with IRC feedback from Nicholas.
--
Micah J. Cowan
http://micah.cowan.name/
Index: mode-key.c
===
--- mode-key.c.orig 2010-03-09 09:58:37.0 -0800
+++ mode-key.c 2010-03-09 12:17:36.0 -0800
@@
Srinivasa R Chamarthy wrote:
> Here is the requested information:
>
> tmux version? -> 1.1
> What Platform? -> Its Ubuntu 9.10 >> Kernel 2.6.31-20-generic
> What Terminal -> Gnome Terminal
> TERM -> xterm (outside), screen (inside tmux)
> CVS Head -> I will try and post the results
I'm pretty sur
Srinivasa R Chamarthy wrote:
> Hello,
>
> I am facing some issues with vim when using tmux. In the vim insert mode if
> inserting empty lines in between lines the i see that the lines are
> overlapping
> or lines are getting scrambled. If i exit vim and enter again everything is
> fine.
>
> Is
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", su
Trent W. Buck wrote:
> t...@cybersource.com.au (Trent W. Buck) writes:
>
>> But: confusion! There is no "just one app" layout in tmux! My first
>> guess is that there must be some way to move apps out of the current
>> window (without killing them), such that "just one app" is simply to
>> move
Trent W. Buck wrote:
> Nicholas Marriott 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 doesn't. But Thomas Ada
clemens fischer wrote:
> Micah Cowan wrote:
>
>> 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 ty
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:
> How come?
I wrote it to apply after the last couple patches I'd recently
submitted. I figured it would apply without them
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 br
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 shor
>> >22 < >111 22
>>
>> At least in vi-copy mode on linux, the shortest 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] BU
Robin Lee Powell wrote:
> On Thu, Feb 18, 2010 at 01:39:15PM -0800, Micah Cowan wrote:
>> The following should bind J to join the current (already
>> finished) selection with spaces:
>>
>> bind-key J run-shell 'tmux save-buffer /tmp/.tmux-exchange; tr \n
>>
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 shor
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
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
but anyway, obviously dangerous code.
This new patch fixes the goof.
-mjc
Micah Cowan wrote:
> WARNING WARNING WARNING
>
> While this patch seems to work fine on two of my laptops running 32-bit
> Ubuntu Karmic Koala (9.04), there seem to be stability issues when
> running from my wo
ld off applying it in CVS until I work out what's going wrong.
Micah Cowan wrote:
> This is a code-only patch. I'll submit a separate one for the manual.
>
> This patch eliminates "output" (or "more") mode, which is used to view
> command output within a
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
=
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 loops
Nicholas Marriott wrote:
> This looks fine apart from a couple of things:
>
> - Why is the count a u_long? I don't see a need for it here, let's just use a
> u_int. Types that commonly change size depending on arch are stupid. In
> fact,
> I might go to far as to say we should put in a hard l
Nicholas Marriott wrote:
> This looks pretty good on a quick look, although why do you need a
> backing_written count? Why not write the CRLF after the line rather than
> before?
Well, not a count so much as a flag.
I just didn't like an extra empty line at the bottom. This way we don't
add a li
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,
> +/* Loop while there's a prefix (or 1, if there isn't one).
> + * Requires the variable "data", pointing at an instance of
> + * struct window_copy_mode_data. */
> +#define REPEAT_NUMPREFIX_TIMES \
> + if (data->numprefix == 0) data->numprefix++; \
> + while (data->numprefix--)
Muc
This patch allows you to supply repeat prefixes to commands in
copy-mode. For instance, to move forward 10 characters, you'd type ‘10l’
("ten ell") in vim, and ‘M-1 0 C-f´ in emacs (of course, you could use
the right arrow-key instead of ell or C-f).
The prefix keys are actually bound commands (to
Micah Cowan wrote:
> This is a code-only patch. I'll submit a separate one for the manual.
>
> This patch eliminates "output" (or "more") mode, which is used to view
> command output within an attached tmux client. It's the mode you use
> when yo
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.) *
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
1 - 100 of 144 matches
Mail list logo
