tmux does not support "save pos" escape code
tmux version 1.5 Gentoo Linux 64-bit (but also reproduced on Ubuntu) Terminal: terminator, with $TERM=xterm (but it doesn't matter in this case) Please try this script (which is a wrapper around "ping"): https://bitbucket.org/denilsonsa/small_scripts/src/tip/prettyping.sh#cl-348 It requires bash and gawk (Gnu Awk). It uses a pair of escape codes to save the cursor position and later move the cursor back to that position. That script works fine under Terminator, under Xterm, and also under Gnu screen (and, while inside screen, it works with all terminals, as the screen program handles that escape code). However, under tmux that script fails, as tmux does not support those escape codes. Thus, it would be nice if it supported such escape codes. -- Denilson Figueiredo de Sá Belo Horizonte - Brasil -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
[PATCH] capture-pane -S/-E: accept wider range
A pane can potentially have up to INT_MAX lines of history (limited
via "history-limit"), but "capture-pane" only accepts values down to
SHRT_MIN for its "-E" and "-S" options.
To allow it to capture a pane's full history, negative numbers down
to at least -INT_MAX should be accepted for these options. Technical
users might try to use INT_MIN, so we should accept that too.
Ideally, we should use MIN(INT_MIN, -INT_MAX), but INT_MIN is less
than -INT_MAX on most platforms, so it should suffice.
The existing code already handles "below zero" unsigned overflow
situations.
The upper bound on the specified line number remains unchanged at
SHRT_MAX. Technically, a pane's height (gd->sy) could possibly be up
to USHRT_MAX (from TIOCGWINSZ, winsize.ws_row is usually "unsigned
short" or "new-session -dy N", where N is limited to USHRT_MAX), but
allowing line specifications that high would open up the possibility
of integer overflow on a platform where USHRT_MAX equals UINT_MAX.
Realistically, it seems highly unlikely that any terminal emulators
allow heights even close to the smallest conforming SHRT_MAX (much
less USHRT_MAX, whether it equals UINT_MAX or not), so SHRT_MAX is
probably an acceptable upper limit.
---
I found this issue while attempting to capture all of a pane's
history and its currently displayed lines (generically, without
knowledge of the pane's effective hlimit), by trying to use -100
as a sufficiently large, negative value with "-S". The result was
that that it only captured the displayed lines (the default, since
strtonum reported ERANGE). I had to back down to -32768 to make it
work.
I am not sure how many users ever actually put "history-limit"
anywhere between SHRT_MAX and INT_MAX, but it seemed like a minor
bug not to support such configurations.
---
trunk/cmd-capture-pane.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/trunk/cmd-capture-pane.c b/trunk/cmd-capture-pane.c
index 9f2d792..52fc792 100644
--- a/trunk/cmd-capture-pane.c
+++ b/trunk/cmd-capture-pane.c
@@ -59,7 +59,7 @@ cmd_capture_pane_exec(struct cmd *self, struct cmd_ctx *ctx)
buf = NULL;
len = 0;
- n = args_strtonum(args, 'S', SHRT_MIN, SHRT_MAX, &cause);
+ n = args_strtonum(args, 'S', INT_MIN, SHRT_MAX, &cause);
if (cause != NULL) {
top = gd->hsize;
xfree(cause);
@@ -70,7 +70,7 @@ cmd_capture_pane_exec(struct cmd *self, struct cmd_ctx *ctx)
if (top > gd->hsize + gd->sy - 1)
top = gd->hsize + gd->sy - 1;
- n = args_strtonum(args, 'E', SHRT_MIN, SHRT_MAX, &cause);
+ n = args_strtonum(args, 'E', INT_MIN, SHRT_MAX, &cause);
if (cause != NULL) {
bottom = gd->hsize + gd->sy - 1;
xfree(cause);
--
1.7.7.4
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
[PATCH] list-keys: clear flags[] for flagless bindings
The flags[] buffer should be reset for all "flagless" bindings (i.e.
those without their no-prefix or repeat "bits" set). Without this
reset, such "flagless" bindings would be displayed with the flags of
the previous "flagged" binding (if any).
---
It seemed slightly better to make this (re)initialization
unconditional, but it could also be appended to the no-prefix/repeat
if/else-if as a final else "leg" instead. Such a conditional version
might be slightly faster, but might also be more fragile in the face
of changes to the flag presentation logic.
I noticed this problem after I did `bind -n C-\ ...`, and suddenly
the bulk of the rest of the listed bindings were also shown with "-n".
This bug also shows up with the default bindings, but it is easy to
miss. The M-1/2/3/4/5/n/o/p bindings are "plain" bindings (prefix
required, no repeating allowed), so they should not have
"-r"/"-rn"/"-n" displayed for them. However, because their immediate
predecessor in the listing is a repeatable binding (Right), these
bindings are also displayed with the "-r" flag
---
trunk/cmd-list-keys.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/trunk/cmd-list-keys.c b/trunk/cmd-list-keys.c
index 8f957c8..c76389a 100644
--- a/trunk/cmd-list-keys.c
+++ b/trunk/cmd-list-keys.c
@@ -54,7 +54,6 @@ cmd_list_keys_exec(struct cmd *self, struct cmd_ctx *ctx)
return (cmd_list_keys_table(self, ctx));
width = 0;
- *flags = '\0';
SPLAY_FOREACH(bd, key_bindings, &key_bindings) {
key = key_string_lookup_key(bd->key & ~KEYC_PREFIX);
@@ -78,6 +77,7 @@ cmd_list_keys_exec(struct cmd *self, struct cmd_ctx *ctx)
if (key == NULL)
continue;
+ *flags = '\0';
if (!(bd->key & KEYC_PREFIX)) {
if (bd->can_repeat)
xsnprintf(flags, sizeof flags, "-rn ");
--
1.7.7.4
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: tmux does not support "save pos" escape code
Well, s and u are part of the private range. Where did these come from? I don't object to adding them but it would be nice to see some documentation. They don't appear to be in ECMA-48 so they are probably not ANSI. The DEC sequences to save/restore cursor position are DECSC and DECRC, which are \E7 and \E8... it's a good idea to use those instead. On Mon, Dec 26, 2011 at 02:00:36PM -0200, Denilson Figueiredo de S?? wrote: > tmux version 1.5 > Gentoo Linux 64-bit (but also reproduced on Ubuntu) > Terminal: terminator, with $TERM=xterm (but it doesn't matter in this case) > > Please try this script (which is a wrapper around "ping"): > https://bitbucket.org/denilsonsa/small_scripts/src/tip/prettyping.sh#cl-348 > It requires bash and gawk (Gnu Awk). > It uses a pair of escape codes to save the cursor position and later > move the cursor back to that position. > > That script works fine under Terminator, under Xterm, and also under > Gnu screen (and, while inside screen, it works with all terminals, as > the screen program handles that escape code). > > However, under tmux that script fails, as tmux does not support those > escape codes. > > > Thus, it would be nice if it supported such escape codes. > > -- > Denilson Figueiredo de S?? > Belo Horizonte - Brasil -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
Re: patch for mapping 16 color palettes to 256 colors
Hello Nicholas, I've fixed tabs, licensing and updated the man page. A new patch created against the subversion tree is here: http://benjamin-schweizer.de/files/tmux/tmux-colourmap2.diff Let me know if it needs more clearing up. btw: I've heard more complaints about the broken tarball, but it looks ok on my Debian-stable machine. regards, On Sat, Dec 24, 2011 at 9:48 AM, Nicholas Marriott < nicholas.marri...@gmail.com> wrote: > Hi > > Thanks. > > It looks like you managed to somehow gzip your .tar.gz twice... > > Can you send this as a unified diff against the source rather than a set > of files? > > To do this, either checkout the Subversion source from SourceForge, > modify it (in trunk/) and do "svn diff" (after using "svn add" on new > files). You'll have to run sh autoconf.sh to generate the infrastructure > (such as configure) needed for building. > > If you prefer to work on 1.5, copy your tmux 1.5 directory entire to eg > tmux.orig, make your changes in previous tmux directory, then do make > clean distclean and do: > > $ diff -rNup tmux.orig tmux >tmux.diff > > It's usually easier all round if you make the changes against the latest > Subversion source. > > On the face of it, I'm not unhappy with the idea but your code will need > a little tidying up, for example please use 8 character tabs rather than > spaces. It'll also need a manpage change. > > Please use the full ISC license in the other files for your new > cmd-map-colour.c and be more specific than "copyleft" about the license > for the themes files. If you want them to be included as well this means > explicitly saying public domain (see examples/), or the ISC license used > elsewhere. > > > > On Fri, Dec 23, 2011 at 10:53:21AM +0100, Benjamin Schweizer wrote: > >Hello, > > > >I've created a patch for mapping colors from 16 color palettes to 256 > >colors. > >This is usefull if you want to modernize old software with fixed color > >palettes, e.g. irssi or midnight commander. > > > >Here's a blog post with screenshots: > >[1] > http://benjamin-schweizer.de/colorful-terminals-theme-support-for-tmux.html > > > >Here's a sample theme: > >[2] > http://benjamin-schweizer.de/files/tmux/tmux-themes/sundevil.tmux.conf > > > >Here's a link to the source code: > >[3]http://benjamin-schweizer.de/files/tmux/ > > > >What's your opinion on this? > >How can I get this included in upstream CVS? > > > >Greetings, > > > >-- > >[4]http://benjamin-schweizer.de/contact > > > > References > > > >Visible links > >1. > http://benjamin-schweizer.de/colorful-terminals-theme-support-for-tmux.html > >2. > http://benjamin-schweizer.de/files/tmux/tmux-themes/sundevil.tmux.conf > >3. http://benjamin-schweizer.de/files/tmux/ > >4. http://benjamin-schweizer.de/contact > > > > -- > > Write once. Port to many. > > Get the SDK and tools to simplify cross-platform app development. Create > > new or port existing apps to sell to consumers worldwide. Explore the > > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > > http://p.sf.net/sfu/intel-appdev > > > ___ > > tmux-users mailing list > > tmux-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/tmux-users > > -- http://benjamin-schweizer.de/contact -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
