I think I've seen the error with AC_SEARCH_LIBS and m4_pattern_allow
before. Try installing pkgconf if you don't already have it
installed, and then rerun autogen.sh.
On Wed, May 6, 2015 at 3:40 PM, jungle Boogie wrote:
> Hi Nicholas,
> On 6 May 2015 at 13:31, Nicholas Marriott wrote:
>> Do yo
> I like this, don't see any other problems so far.
I applied your patch and looked it over. I don't see any problems, either.
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in a
This line in the patch for tmux.1 looks wrong:
+.Fl P ).
I think there has to be a space between the parenthesis and the
period. Without it, the parenthesis gets treated as a flag and a dash
is put before it.
If -g or -P is passed to selectp, other flags are ignored. Is that
the intended behav
> On thing that occurred to me now is that display-panes uses a
> target-client but this diff makes it need a target-pane sometimes which
> is an issue for hooks command parsing. Not sure if we can workaround it
> easily enough with extra flags for hooks or if we should try to find a
> different co
+
> + if (paste_get_name(name) != NULL)
> + paste_free_name(name);
>
> RB_INSERT(paste_name_tree, &paste_by_name, pb);
> RB_INSERT(paste_time_tree, &paste_by_time, pb);
>
>
>
> On Sun, Feb 22, 2015 at 10:54:38PM -0600, J Raynor wrote:
>> The
> I think you want only 2 or 3 arguments to be valid, 4 should be an
> error. Otherwise this looks fine.
You already can't pass 4 arguments. The check for -t in
cmd_bind_key_exec prevents anything but 2 or 3 args from getting to
that section of code.
If you'd prefer the check to be there anyway,
I've attached a patch that adds the BCE functionality I did before.
It's more concise this time. You have to apply the other patch first,
the one that does pane colors for bce terminals.
As for the other stuff, I misunderstood what you were referring to. I
thought you were looking for a differen
> You could maybe make copy-selection accept an argument like copy-pipe. I
> wouldn't make it do the full getopt dance just yet but just accepting
> "-n" or "-x" or something might work.
I've attached a patch that allows you to pass -x to the key bindings
for append-selection, copy-selection, and
There's a bug in window_copy_append_selection that causes tmux to free
memory that shouldn't be freed.
To reproduce the problem:
* Set mode-keys to vi so you can use A to append to a buffer
* Enter copy mode and copy some text
* Use lsb to note that the buffer names look normal
* Enter copy m
> You can try to make tmux itself support BCE ... or add BCE support
> back on top of this like you had before.
I don't know how to make tmux support terminals without BCE besides
what I already did. Can you give me some detail for what you mean by
"make tmux itself support BCE"?
---
Since this ticket wasn't closed quickly with a statement that the
functionality isn't wanted, does that mean there's a possibility for
change?
Three options come to mind:
1. Change tmux's default behavior so that copying a selection doesn't
exit copy mode.
2. Add an option (session option?) to
I've attached a new patch. This patch:
* Adds Thomas's fix for pane selection via the mouse
* Gets rid of nflags in cmd_display_panes_exec
* Fixes the usage of memcpy in window.c
* Leaves tty_reset unchanged
* Has the tty_cmd_* functions call tty_attributes instead of tty_reset
* Includes u
9, 2015 at 3:36 PM, Thomas Adam wrote:
> On Thu, Feb 19, 2015 at 12:21:37PM -0600, J Raynor wrote:
>> I checked back over the emails for my patch, but I don't see any
>> mention of mouse events. Was there a discussion off list? If so,
>> I'll need to know what
I checked back over the emails for my patch, but I don't see any
mention of mouse events. Was there a discussion off list? If so,
I'll need to know what else you've found wrong. I can't fix it if I
don't know about it.
> It's _still_ missing a fix in server-client. See the following:
>
>
> dif
I've attached a new patch. There are 2 new window options,
window-style and window-active-style, that allow you to set the
window's color and the window's active pane color. The display-panes
command can still be used to set an explicit pane color with -P.
tty_attributes now takes a window pane
Right now, if you try to set a style with a bad value, tmux will
return an error, but it'll set the style to default. This happens
even if the style isn't currently set.
For example:
localhost> tmux show -w
localhost> tmux set pane-border-style bg=BadValue
bad style: bg=BadValue
localhost> tmux
> Yes panes should always have colours. If the pane is set to 8, it uses
> the window, if the window is 8, it uses the default. It isn't necessary
> to have a way to set the pane directly to default, we don't have that
> for any other style - it always follows the hierarchy (like eg the status
> li
> - I don't think you need to allocate the gc with malloc, just put it
> inside the wp directly and initialize it to grid_default_cell.
I do need to allocate it with malloc. If I don't, it's always there
(not NULL), so it'll always have some value. That makes it impossible
to tell what to do w
I've attached a new patch for pane colors. You use the display-panes
command to set the colors now, and the color changes take place in
tty_reset.
There's no bce stuff in this patch.
For bce, you mentioned a TTY_NOBCE flag. Could you give a little more
detail about what you're looking for? Whe
> I've taken a very quick look at this over lunch, and have put additional
> fixes/suggestions on top of your patch. The branch is here:
>
> https://github.com/ThomasAdam/tmux/commits/jr/pane-colours
>
> Have a look, tell me what you think. The cleanups are pretty trivial, but
> reduces some of t
> This will not work as it is on terminals which do not support BCE. To
> make it do so you will pretty much have to make tmux support BCE :-).
Ok, it now works on systems that don't support BCE. I've attached a new patch.
diff --git a/cmd-display-panes.c b/cmd-display-panes.c
index 9ce8971..150b
> But might make tmux flicker quite a bit over SSH or on slower terminals.
I don't think it'll cause flicker. Tmux tries to limit how much needs
to be written to the terminal. I did a quick login test with trickle,
setting upload/download speeds to 1K, 2K, 8K, and 16K. I don't see
any flickerin
I was able to reproduce the problem. If you start tmux with the -2
flag, does the problem go away?
I've attached a new patch that fixes this problem without having to
pass the -2 flag.
On Wed, Feb 11, 2015 at 4:54 AM, Thomas Sattler
wrote:
> Am 11.02.2015 um 07:57 schrieb J Raynor:
I’ve attached a patch that allows you to set the foreground and
background color for a pane. The way it works is that, when tmux
writes to the screen, if it would have written with the terminal’s
default color, but you’ve set the pane’s default color option, then
it’ll use that color instead. Doi
The colour_fromstring function intends to accept string values “90" through “97", but doesn’t because it checks incorrectly.Here’s how it checks “91”: if (strcasecmp(s, "brightred") == 0 || (s[0] == '9' && s[1] == '1' && s[1] == '\0')) return (91);Notice it checks s[1] twice, instead of checki
I'm not seeing the problem on OS X. Did you build tmux yourself, or
did you install it via macports, homebrew, or fink?
Check your .profile (or .bash_profile) and see if you've got a "cd"
command in there.
On Sun, Oct 19, 2014 at 7:10 PM, Mark Volkmann
wrote:
>
>> On Oct 19, 2014, at 7:03 PM, T
I’m not seeing a hang, but I do see a defunct process. It appears to
be due to a race condition.
Tmux startup is a little slow on cygwin, which I think is what’s
triggering the race condition. It looks like tmux ends up setting
client_attached=1 before the child process in daemon() exits. As a
The patch compiles, but part of the change you made reintroduces the
race condition. The parent process has to close the slave before
closing the write pipe.
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analy
> Applied with some trivial style nits, check it still builds please :-).
I don't see any update in the git repository. How long after you
apply a change does it take before showing up in git?
--
Meet PCI DSS 3.0 Complia
> I think you should probably loop for EINTR from read() but otherwise
> this looks fine to me.
I've attached an updated patch.
diff --git a/compat/forkpty-aix.c b/compat/forkpty-aix.c
index db9c2e7..98119f0 100644
--- a/compat/forkpty-aix.c
+++ b/compat/forkpty-aix.c
@@ -23,16 +23,20 @@
#include
Tmux is hanging on aix, and the problem appears to be a race condition
in the implementation of forkpty.
Aix has the behavior that, if data has been written to the slave side
of a pty but has not been read yet by the master side, then the last
close of the slave pty will hang until the data is rea
pane_current_path on solaris doesn't work. I only have access to
solaris 11, so I can't tell if this is a new problem with that version
or if it hasn't worked for a while.
I've attached a patch that fixes the problem, but I can't test on
previous versions of solaris.
In osdep-sunos.c, osdep_get_
When you installed tmux via cygwin, you might’ve updated some other packages
that brought new behavior. I have to do some more checking, but it looks like
cygwin might have changed something recently so that it doesn’t set errno when
it can’t connect to an existing socket file, and this confuse
> Only need to change paste_cmp_times, paste_(get|free)_top and remove the
> RB_INSERT and REMOVE from paste_rename:
I think paste_set needs to be modified as well. When it replaces a
buffer, it frees the old one and mallocs a new one. The new one needs
to have pb->order set to paste_next_order+
> If we supported it outside tmux it would add something useful but even
> then I'm not convinced the status quo isn't good enough.
Ok. I'll drop it. It can be revisited if people start requesting the feature.
--
Is you
Do you mean order everything by time when displaying the buffers in
buffer-list and buffer-choose? Or do you mean order everything by
time in all cases, so that paste_get_top refers to the most recent
buffer, even if it is !automatic?
If it's the former, that sounds fine. If it's the latter, tha
I've attached a patch that just updates the man page. If this patch
is acceptable, let me know if you would like this combined with the
patch for the code into a single patch.
On Thu, May 8, 2014 at 2:41 AM, Nicholas Marriott
wrote:
> This looks good, it needs to go in the man page, but I'm not
My patch isn't correct. It misses the case where there's only 1 item
in find_list.
I've attached a new patch which should correctly free the memory.
On Thu, May 1, 2014 at 1:48 AM, J Raynor wrote:
> It looks like there's a memory leak in cmd_find_window_exec.
I've attached a new patch which drops the buffer_stickiness format and
includes changes to the man page.
On Thu, May 1, 2014 at 5:33 PM, Nicholas Marriott
wrote:
> Hi
>
> This looks good thanks, but I'd lose the buffer_stickiness format and just add
> buffer_name.
>
> (Even if we want it flag fo
>
>
> On Wed, Apr 30, 2014 at 10:55:49PM -0500, J Raynor wrote:
>> I've attached a patch which implements xterm's title stack
>> functionality for screens inside tmux.
--
"Accelerate Dev
It looks like there's a memory leak in cmd_find_window_exec. This
function calls cmd_find_window_match, which allocates memory to
find_data.list_ctx using xstrdup or xasprintf.
cmd_find_window_exec then uses this allocated string in a call to
format_add, but never frees it. I've attached a patch
I've attached a patch which implements xterm's title stack
functionality for screens inside tmux.
diff --git a/input.c b/input.c
index b6c27cb..c7bf0a2 100644
--- a/input.c
+++ b/input.c
@@ -1493,8 +1493,6 @@ input_csi_dispatch_winops(struct input_ctx *ictx)
/* FALLTHROUGH */
case 9:
case
Sorry, I made an off-by-one error in cmd_stringify_argv. I've
attached a new patch.
On Thu, Apr 24, 2014 at 5:42 PM, J Raynor wrote:
>> Only bit I don't like now is passing return from xstrdup() to xrealloc()
>> in cmd_stringify_argv, better just to start len = 1 and x =
I've attached a new patch. It's the patch you just recently sent with
the following modifications:
1. buffer-limit isn't passed to paste_set. paste_add is the only
paste function that needs it now, and it'll look it up itself.
2. The length and character restrictions for buffer names have been
> Yes I think we could do the same with buffer-limit now it is global too.
Ok, I'll do that.
> I think let's not limit the length or charset of names for now, if someone
> sets it to something silly it'll be a display issue only and their own fault
> anyway.
Ok, I'll remove the restrictions.
>
> Only bit I don't like now is passing return from xstrdup() to xrealloc()
> in cmd_stringify_argv, better just to start len = 1 and x = 0.
I've attached a new patch. The only difference is the implementation
of cmd_stringify_argv, which I've altered to remove what you disliked.
diff --git a/cmd-
I kept passing in global_buffers since that's what the existing code
did, and I thought there might be a reason (planned future
functionality?), so I kept it. But it makes sense to not pass it in
if you don't expect other paste_stores. But why not do the same with
buffer-limit? paste_add can loo
I've attached the 2nd part of the "--" patch.
On Fri, Apr 18, 2014 at 12:39 PM, J Raynor wrote:
> On Thu, Apr 17, 2014 at 8:04 AM, Nicholas Marriott
> wrote:
>> Applied this to OpenBSD now with the const char * thing fixed. Thanks
>
> Ok. I'll wait unt
I've attached a new patch for named buffers. There's no longer a
paste stack. There's a name-tree which stores all the buffers, and a
time-tree which just stores unsticky buffers. The time-tree only
needs to store unsticky buffers since they're the only ones which can
be aged away.
I was going
Your proposed implementation looks fine to me. I have a question about this:
> - buffer-limit is only applied to !sticky buffers
Which of these did you mean?
1. Buffer-limit limits the total number of buffers (the sum of sticky
and non-sticky), but only non-sticky buffers get aged away.
2. B
On Thu, Apr 17, 2014 at 8:04 AM, Nicholas Marriott
wrote:
> Applied this to OpenBSD now with the const char * thing fixed. Thanks
Ok. I'll wait until this shows up in the git repository and then send
in the 2nd part of the "--" patch.
In cmd-new-session.c, you've made path's type "char *", but everywhere
else it is "const char *". Was that intentional?
The parts of your patch that take the path from the global or session
env seem redundant, unless I'm missing a use case. When a new
session, window, or pane is created, a new e
e rest of the
"--" patch since the 2 parts of the patch need to modify some of the
same lines in different ways, so they'd conflict if they were just 2
unrelated patches.
On Tue, Mar 11, 2014 at 7:05 PM, J Raynor wrote:
> I&
I've attached a patch which implements named buffers.
Commands that take a buffer arg, like save-buffer and paste-buffer,
have been modified so that -b can take a number or a name. So, you
can do "setb -b myBuf someData".
buffer-limit applies to both the paste stack and the named buffers.
So if
For cygwin, you may also need to set/export CHERE_INVOKING=1 before
starting tmux, or put this in your .tmux.conf:
set-environment -g CHERE_INVOKING 1
See here for more:
http://article.gmane.org/gmane.comp.terminal-emulators.tmux.user/5920
http://article.gmane.org/gmane.comp.terminal-emulators
The following will cause a fatal error in recent tmux code:
setb ""
The empty string leads to an xrealloc in cmd-set-buffer.c with a size
of 0, which is fatal. I've attached a patch which fixes this.
diff --git a/cmd-set-buffer.c b/cmd-set-buffer.c
index 0e754bb..e7f9b95 100644
--- a/cmd-set-bu
I've attached a patch that just does the PATH bits.
diff --git a/cmd-new-session.c b/cmd-new-session.c
index 15e411d..8953820 100644
--- a/cmd-new-session.c
+++ b/cmd-new-session.c
@@ -54,11 +54,12 @@ cmd_new_session_exec(struct cmd *self, struct cmd_q *cmdq)
struct window *w;
struct environ
It looks like cygwin's /etc/profile is causing the homedir behavior.
Add this line to your tmux.conf and the behavior should stop:
set-environment -g CHERE_INVOKING 1
--
Learn Graph Databases - Download FREE O'Reilly Book
> I did not submit a patch because I could not get `tmux splitw -c
> '#{pane_current_path}'` to work properly on Cygwin. I'd love to say that the
> patch submitted by J Raynor worked for me though, but I'm still always
> getting new panes/windows opening at `~`
> I did not submit a patch because I could not get `tmux splitw -c
> '#{pane_current_path}'` to work properly on Cygwin. I'd love to say that the
> patch submitted by J Raynor worked for me though, but I'm still always
> getting new panes/windows opening at `~`
> Any chance you can split the PATH bits out so they work on the current
> code then we can apply them separately before adding --?
Let me make sure I understand what you're looking for.
The current code passes in cmd to things like session_create and
window_pane_spawn. My patch, as it is now, d
> nice, i thought they would probably be very similar but the guy who
> requested this said he tried to copy osdep-linux.c and it didn't work
Hmm. Did he supply a patch? I'm just wondering if he forgot to
update configure.ac. In that case, tmux would've continued to use
osdep-unknown.c.
--
> what i didn't like before was that setb -a w/o any buffers acts like
> setb, but i think that is actually more useful than an error
In copy mode, if you highlight some text and hit 'A', it'll set buffer
0 if it's NULL, otherwise it'll append to what's there. I figured
"setb -a" should work the
The TODO list has this item:
* get_cwd for cgywin
I've attached a patch which implements this, along with get_name.
Cygwin's /proc filesystem is similar enough to linux's that the code
could be copied from osdep-linux.c, and that's what I've done.
osdep-cygwin.c is just a copy of osdep-linux.c,
> Applied with a few changes, thanks
The changes removed a bit of functionality. If someone does "setb -a
foo", then I believe that "foo" should get appended to what's at
buffer 0, assuming it isn't NULL. That doesn't happen with the patch
that got applied.
If the removal of that functionality
> This looks good but you need to add the new flag and key to the manpage?
I've attached a new patch that includes updates to the man page.
tmux-append.patch
Description: Binary data
--
Managing the Performance of Cloud-
> Hi. Can you make this a flag to setb (-A? -a?) instead of a new command?
Sure. I've attached a new patch. There's no append-buffer command,
and passing -a to set-buffer will cause it to append.
tmux-append.patch
Description: Binary data
---
In the "copy/paste improvements" section of the TODO list there's this item:
* append to buffer
I've attached a patch that implements this. I've added a new command
called append-buffer, which works like set-buffer. I added the code
for this in cmd-set-buffer.c to avoid adding a new source fil
I suppose paste_replace could always handle the freeing of the memory.
This would preserve its fire and forget nature.
See the attached patch.
tmux-ml.patch
Description: Binary data
--
Android apps run on BlackBerry 10
> Why not this instead? Also fix some other similar problems.
I was hesitant to free the memory in window_copy_copy_buffer in case
the caller wasn't done with it. But since all current callers are
done with it, I guess it doesn't matter.
Your patch looks good.
--
It looks like there's a potential memory leak in
window_copy_copy_selection. This function calls
window_copy_copy_buffer, which calls paste_replace. If paste_replace
succeeds, it stores the data that was passed to it.
But if paste_replace fails, such as when an invalid buffer index is
specified,
> I reckon we always set PATH and yes pass it into the func. Behaviour will
> only change if someone sets PATH in global or session environment
> themselves.
I've attached a new patch with the new PATH behavior, and the patch
also fixes the 2 issues you noted with cmd_stringify_argv.
tmux-dashda
> - If we are going to call execvp we should control PATH, I think we
> should probably get it from the client if it's a command line client
> else from the session environ. In any case you'll need to pass it in
> from the caller as yet another argument.
Tmux currently runs commands by calli
I've attached a patch that allows people to specify a command to neww
and related commands without having to quote the command. Using "--"
is only needed if the command you want to run happens to start with a
dash.
tmux-dashdash.patch
Description: Binary data
> The original behaviour needs to stay if there is 1 arg.
Should there be a way to force the new behavior? This might be
desirable since quoting would be different in this one case. For
example, someone might enter:
neww "/path/x y/bin/foo"
...and their intention is to run the command "foo"
> If you want I can send you a rough diff of how I think this should look?
I think Nicholas's last email cleared up most of what I needed, but I
might try to take you up on this if it turns out I'm still not getting
it.
-
> Neww doesn't need to get -- it just needs to know how many args it has. The
> -- is to make getopt pass args to neww rather than treating as flags eg
>
> tmux neww -x -- foo -y
>
> Needs to set x flag in args but pass 2 args to neww foo and -y.
I believe the existing code already does this. New
> No, this is why "--" exists, and on BSD, getopt() does not do "--"
> scanning, unlike on Linux.
The man page for getopt in openbsd mentions checking for "--", and
tmux's compat/getopt.c, which has a lot of "BSD" in it, also checks
for "--".
>> would never see it, and so couldn't alter its beha
> I don't think you need to modify getopt, the commands just need to handle a
> variable number of args but I don't remember specifics of what needs to
> change.
I still don't see how I can get "--" passed to neww. For example,
this works fine in tmux 1.8:
tmux neww -- emacs
There's no code in
The tmux TODO list has this item:
* use "--" to mark start of command w/ neww etc to avoid quoting
I'm a little confused about this, so I'm hoping to get some
clarification. In this email:
http://article.gmane.org/gmane.comp.terminal-emulators.tmux.user/5432
...the user gets a usage error wi
> This breaks quotes, for example try:
>
> neww -n "a;neww"
I knew the patch caused this behavior.
> I know the existing code allows things like 'neww -n "a;" neww'
And that's why I didn't think it was a problem. I figured it was
established behavior that semicolons weren't safe in quotes.
> Please don't use expressions with side-effects like m++ in function
> arguments, it's too easy to miss.
Ok. I've attached a new patch that meets your request.
diff --git a/input.c b/input.c
index 259fad1..23804b9 100644
--- a/input.c
+++ b/input.c
@@ -74,6 +74,7 @@ void input_csi_dispatch_rm(s
> Take a look at this instead which a) uses a function like CSI, SM etc b)
> don't increment m inside function arguments.
This works fine. However, I noticed that just incrementing m may
cause it to skip over bad input. For example, a winop of 3 is
supposed to take 2 arguments. If someone enter
> How about WINOPS instead of WMN? This matches xterm src and seems a bit
> more readable. Otherwise looks good.
Sure. I've attached an updated patch with WINOPS instead of WMN.
diff --git a/input.c b/input.c
index 259fad1..bc4f912 100644
--- a/input.c
+++ b/input.c
@@ -154,6 +154,7 @@ enum input
Sorry, after I submitted the patch I realized it was incorrect.
Certain options take arguments and my patch didn't account for that.
I've attached a new patch which does.
On Wed, Jan 29, 2014 at 12:28 AM, J Raynor wrote:
> I've attached a patch which implements this. The &
I've attached a patch which implements this. The 't' group of escape
sequences are described as being for "window manipulation" in some
documentation, so that's why I picked WMN in the INPUT_CSI_WMN
identifier.
diff --git a/input.c b/input.c
index 259fad1..e27ecbb 100644
--- a/input.c
+++ b/input.
Ok. I'll drop it.
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quo
> I don't really see a need for this at all, especially given the
> complexity it'll add to the client
Do you not see a need for the TODO list item (anymore), or just the
proposed implementation?
If it's the latter, how about something simpler? The client could
read the config file and look for:
There's this item on the tmux TODO list:
* way to set socket path from config file
I was thinking of trying to implement it, but I thought it needed
discussion first.
I was thinking that there could be a command, like set-client or
set-flag. This could be used to set the socket path (set-clien
The tmux TODO list has this item regarding command sequences:
* don't require space after ;
I've attached a patch that does this.
diff --git a/cmd-list.c b/cmd-list.c
index 08e2067..22327cd 100644
--- a/cmd-list.c
+++ b/cmd-list.c
@@ -29,55 +29,85 @@ cmd_list_parse(int argc, char **argv, const
On Mon, Jan 6, 2014 at 9:22 AM, Nicholas Marriott
wrote:
> Hmm... I don't know, people who include periods in session names are
> probably just asking for trouble but maybe we should ban them earlier.
By "ban them earlier" do you mean never allow periods in session
names? If so, the attached pa
This works fine. However, as of 1.8, it is possible to have a period
in the session name and to attach to it. With this patch, it's no
longer possible to attach to such a session since the period is
interpreted as a pane specifier. Does that matter?
-
> Can't you just use cmd_find_pane? If the user doesn't specify a pane
> it'll default to the active pane anyway so selecting it'll be a no-op.
Your suggestion got me to look at my patch again, and I think it
could've been clearer. I've attached an updated patch. Everything
should behave the sam
> Can't you just use cmd_find_pane? If the user doesn't specify a pane
> it'll default to the active pane anyway so selecting it'll be a no-op.
Do you mean use a patch like this:
diff --git a/cmd-attach-session.c b/cmd-attach-session.c
index e4c0b23..7f7153e 100644
--- a/cmd-attach-session.c
+++
The TODO list has this item:
* attach should take a pane and select it as well as attaching
I've attached a patch that implements this. You can specify a pane
with %, or a window with @, just as before, but tmux will switch to
that pane or window. You can also specify windows and panes with th
> How about doing this the emacs way? All lowercase means case-insensitive,
> any caps means case-sensitive.
Sure. I've attached a new patch that does that. There's no window
option this time since it isn't needed.
tmux-case-insensitive-search.patch
Description: Binary data
---
I've attached a patch that implements case insensitive searching in
copy mode. The case insensitive searching only works for ascii
characters (not unicode) because that's all tmux appears to allow you
to enter when you do a search.
The patch adds a new window option called case-insensitive-search
I applied your patch and it corrects the problem.
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn mo
It looks like there's a bug in the window_copy_scroll_up and down
functions where they don't correctly highlight what's been selected
for copying.
To see the problem with window_copy_scroll_up, do the following:
1. Generate more than a screenful of text.
2. Enter copy mode.
3. Scroll up some s
I've attached a patch that implements this.
tmux-otherend.patch
Description: Binary data
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI,
1 - 100 of 132 matches
Mail list logo
