Re: How to escape in tmux?

[Nicholas Marriott]

Hi

What is shown when you run "cat" and type Escape/Escape or Home or End?

Home and End may not work right for some reason but Esc/Esc will always
work.



On Mon, Feb 20, 2012 at 08:53:10PM +0800, Bill Sun wrote:
> On Mon, Feb 20, 2012 at 07:27:22AM +, Nicholas Marriott wrote:
> > What is TERM set to outside tmux and what terminal are you using?
> >
> $TERM outside tmux: xterm-256-color
> $TERM inside tmux: screen
> 
> I use xterm. I mentioned it in my first email, under "My system
> information" section. Maybe I didn't make important information clear, sorry 
> ;-)
> 
> Regards

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users

Re: Patch - add -F to display-message command

[Nicholas Marriott]

This will core if you give it -F w/o -t.

Also, looking at it again: since jobsflag is 0 to status_replace so it
won't run jobs, a format is enough I think (it will replace #W etc too).

Perhaps this... I left -F to match the other formats but maybe it's
unnecessary.

Index: cmd-display-message.c
===
RCS file: /cvs/src/usr.bin/tmux/cmd-display-message.c,v
retrieving revision 1.10
diff -u -p -r1.10 cmd-display-message.c
--- cmd-display-message.c   6 Apr 2011 11:36:26 -   1.10
+++ cmd-display-message.c   21 Feb 2012 09:13:28 -
@@ -30,8 +30,8 @@ int   cmd_display_message_exec(struct cmd 
 
 const struct cmd_entry cmd_display_message_entry = {
"display-message", "display",
-   "c:pt:", 0, 1,
-   "[-p] [-c target-client] [-t target-pane] [message]",
+   "c:pt:F:", 0, 1,
+   "[-p] [-c target-client] [-t target-pane] [-F format] [message]",
0,
NULL,
NULL,
@@ -48,26 +48,39 @@ cmd_display_message_exec(struct cmd *sel
struct window_pane  *wp;
const char  *template;
char*msg;
+   struct format_tree  *ft;
+   char out[BUFSIZ];
+   time_t   t;
 
if ((c = cmd_find_client(ctx, args_get(args, 'c'))) == NULL)
-   return (-1);
+   return (-1);
 
-   if (args_has(args, 't') != 0) {
+   if (args_has(args, 't')) {
wl = cmd_find_pane(ctx, args_get(args, 't'), &s, &wp);
if (wl == NULL)
return (-1);
} else {
-   s = NULL;
-   wl = NULL;
-   wp = NULL;
+   wl = cmd_find_pane(ctx, NULL, &s, &wp);
+   if (wl == NULL)
+   return (-1);
}
 
-   if (args->argc == 0)
-   template = "[#S] #I:#W, current pane #P - (%H:%M %d-%b-%y)";
-   else
+   template = args_get(args, 'F');
+   if (args->argc != 0)
template = args->argv[0];
+   if (template == NULL)
+   template = "[#S] #I:#W, current pane #P - (%H:%M %d-%b-%y)";
+
+   ft = format_create();
+   format_client(ft, c);
+   format_session(ft, s);
+   format_winlink(ft, s, wl);
+   format_window_pane(ft, wp);
+
+   t = time(NULL);
+   strftime(out, sizeof out, template, localtime(&t));
 
-   msg = status_replace(c, s, wl, wp, template, time(NULL), 0);
+   msg = format_expand(ft, out);
if (args_has(self->args, 'p'))
ctx->print(ctx, "%s", msg);
else






On Sun, Feb 05, 2012 at 10:06:04PM -0800, George Nachman wrote:
> As we discussed earlier, this patch adds -F format to display-message.
> If -F is passed then that format is used in preference to the
> 'message' argument.
> 
> Index: tmux.1
> ===
> --- tmux.1(revision 2697)
> +++ tmux.1(working copy)
> @@ -2648,6 +2648,7 @@
>  .El
>  .Sh FORMATS
>  The
> +.Ic display-message ,
>  .Ic list-clients ,
>  .Ic list-sessions ,
>  .Ic list-windows
> @@ -2979,6 +2980,7 @@
>  .Op Fl p
>  .Op Fl c Ar target-client
>  .Op Fl t Ar target-pane
> +.Op Fl F format
>  .Op Ar message
>  .Xc
>  .D1 (alias: Ic display )
> @@ -2988,9 +2990,16 @@
>  is given, the output is printed to stdout, otherwise it is displayed in the
>  .Ar target-client
>  status line.
> -The format of
> +If
> +.Fl F
> +is given, then
> +.Ar format
> +defines the message as described in the
> +.Sx FORMATS
> +section.
> +Otherwise,
>  .Ar message
> -is as for
> +defines the message. Its format is as for
>  .Ic status-left ,
>  with the exception that #() are not handled; information is taken from
>  .Ar target-pane
> Index: cmd-display-message.c
> ===
> --- cmd-display-message.c (revision 2697)
> +++ cmd-display-message.c (working copy)
> @@ -30,8 +30,8 @@
> 
>  const struct cmd_entry cmd_display_message_entry = {
>   "display-message", "display",
> - "c:pt:", 0, 1,
> - "[-p] [-c target-client] [-t target-pane] [message]",
> + "c:pt:F:", 0, 1,
> + "[-p] [-c target-client] [-t target-pane] [-F format] [message]",
>   0,
>   NULL,
>   NULL,
> @@ -48,6 +48,7 @@
>   struct window_pane  *wp;
>   const char  *template;
>   char*msg;
> + struct format_tree  *ft;
> 
>   if ((c = cmd_find_client(ctx, args_get(args, 'c'))) == NULL)
>   return (-1);
> @@ -62,12 +63,22 @@
>   wp = NULL;
>   }
> 
> - if (args->argc == 0)
> - template = "[#S] #I:#W, current pane #P - (%H:%M %d-%b-%y)";
> - else
> - template = args->argv[0];
> + template = args_get(args, 'F');
> + if (template != NULL) {
> + ft = format_create();
> + format_session(

Request: add support for version blocks in tmux.conf

[Joel Johnson]

I maintain a vcs repository with my collection of dotfiles, which 
includes tmux.conf. As I like to use a common set of dot files on most 
machines I use, the config changes in the 1.6 release have left me stuck 
with pre-1.6 and 1.6 config entries to achieve the desired result on all 
machines, some of which use 1.6 and others which I have less control 
over and have not yet been updated.

I would like to request that the tmux.conf syntax include something 
similar to vim's config file evaluation, which allows conditional 
inclusion of config lines based on evaluation. The has(capability) of 
vim seems overkill, but being able to specify app versions (<,=,>) seems 
adequate.

The effected snippets of what I had:
 set -g prefix `,"C-B"
 setw -g window-status-alert-fgcolour228
 setw -g window-status-alert-attr  dim

The new content to try and cover both cases
 set -g prefix `
 set -g prefix2 "C-B" # tmux 1.6+ only
 bind ` send-prefix
 bind "C-B" send-prefix -2 # tmux 1.6+ only

 # Pre tmux 1.6
 setw -g window-status-alert-fg colour228
 setw -g window-status-alert-attr dim
 # tmux 1.6
 setw -g window-status-activity-fg colour228
 setw -g window-status-activity-attr dim
 setw -g window-status-bell-fg colour228
 setw -g window-status-bell-attr dim
 setw -g window-status-content-fg colour228
 setw -g window-status-content-attr dim

The problem is that know I am guaranteed to get error messages for the 
statements for the incorrect version, which I would like to be able to 
exclude with something like:

 set -g prefix `
 bind ` send-prefix

 if tmuxver < 1.6
 set -g prefix `,"C-B"
 setw -g window-status-alert-fgcolour228
 setw -g window-status-alert-attr  dim
 endif

 if tmuxver = 1.6
 set -g prefix2 "C-B"
 bind "C-B" send-prefix -2

 setw -g window-status-activity-fg colour228
 setw -g window-status-activity-attr dim
 setw -g window-status-bell-fg colour228
 setw -g window-status-bell-attr dim
 setw -g window-status-content-fg colour228
 setw -g window-status-content-attr dim
 endif

Joel

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users

Re: support for version blocks in tmux.conf

[Nicholas Marriott]

Config files and commands are line-based so it would be easiest to do
this so you had to prefix the command with a minimum version, eg:

>1.6:setw -g window-status-alert-fg colour228
<1.5:setw -g window-status-activity-fg colour228

Although personally I'm not entirely convinced this happens often enough
and with enough impact for it to be worth it. How many boxes do you use
tmux for long periods and need status bell colours? I have three, all
the others I use it just for long running jobs with a minimal config.


On Mon, Feb 20, 2012 at 11:13:05PM -0700, Joel Johnson wrote:
> I maintain a vcs repository with my collection of dotfiles, which 
> includes tmux.conf. As I like to use a common set of dot files on most 
> machines I use, the config changes in the 1.6 release have left me stuck 
> with pre-1.6 and 1.6 config entries to achieve the desired result on all 
> machines, some of which use 1.6 and others which I have less control 
> over and have not yet been updated.
> 
> I would like to request that the tmux.conf syntax include something 
> similar to vim's config file evaluation, which allows conditional 
> inclusion of config lines based on evaluation. The has(capability) of 
> vim seems overkill, but being able to specify app versions (<,=,>) seems 
> adequate.
> 
> The effected snippets of what I had:
>  set -g prefix `,"C-B"
>  setw -g window-status-alert-fgcolour228
>  setw -g window-status-alert-attr  dim
> 
> The new content to try and cover both cases
>  set -g prefix `
>  set -g prefix2 "C-B" # tmux 1.6+ only
>  bind ` send-prefix
>  bind "C-B" send-prefix -2 # tmux 1.6+ only
> 
>  # Pre tmux 1.6
>  setw -g window-status-alert-fg colour228
>  setw -g window-status-alert-attr dim
>  # tmux 1.6
>  setw -g window-status-activity-fg colour228
>  setw -g window-status-activity-attr dim
>  setw -g window-status-bell-fg colour228
>  setw -g window-status-bell-attr dim
>  setw -g window-status-content-fg colour228
>  setw -g window-status-content-attr dim
> 
> The problem is that know I am guaranteed to get error messages for the 
> statements for the incorrect version, which I would like to be able to 
> exclude with something like:
> 
>  set -g prefix `
>  bind ` send-prefix
> 
>  if {tmuxver} < 1.6
>  set -g prefix `,"C-B"
>  setw -g window-status-alert-fgcolour228
>  setw -g window-status-alert-attr  dim
>  endif
> 
>  if {tmuxver} = 1.6
>  set -g prefix2 "C-B"
>  bind "C-B" send-prefix -2
> 
>  setw -g window-status-activity-fg colour228
>  setw -g window-status-activity-attr dim
>  setw -g window-status-bell-fg colour228
>  setw -g window-status-bell-attr dim
>  setw -g window-status-content-fg colour228
>  setw -g window-status-content-attr dim
>  endif
> 
> Joel
> 
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> tmux-users mailing list
> tmux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tmux-users

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users

Re: patch to support 256 colors in fbterm

[Nicholas Marriott]

Hi

Sorry for the delay.

On Sat, Feb 11, 2012 at 01:51:15PM -0500, Peter Lustig wrote:
> On 2/9/2012 4:00 AM, Nicholas Marriott wrote:
> >I'd rather not translate aixterm colours on terminals that support them:
> >
> >- They are fewer bytes than the 256 colour equivalents.
> >
> >- We can't predict what configuration options terminals have - some may
> >   have the ability to alter the palette for aixterm colours independent
> >   of the 256 colour palette.
> >
> >I'd rather they were passed through unaltered except on 8 colour
> >terminals.
> 
> I see your reasoning with the second point:  tmux should make as few
> assumptions as possible regarding the underlying terminal.  But, if
> you decide to accept my (original) patch, wouldn't tmux then be
> making the implicit assumption that all 256-colour terminals use the
> same palette as xterm-256 (and all 88-colour terminals the same as
> xterm-88)?  For example, that the indices 8-15 correspond to the
> aixterm colours?  (Actually, this assumption is still there in the
> current version of tmux; all the patch does is remove another
> assumption regarding the actual _format_ of the 256/88-colour escape
> sequences.)

At the moment tmux assumes that 256 colours are set using
\033[38;5;Xm. This is definitely not ideal.

However it is definitely fine to assume that the 256 colour palette is
fixed.

But I'm not sure it's fine to assume the aixterm colours are fixed or
that they are the same as colours 8-15. And definitely not ok to assume
the standard ANSI colours are the same as colours 0-7 in the 256 colour
palette.

Of course you're right it's not ideal to assume that aixterm sequence is
\033[9Xm either.

Dunno, might be best to just map everything to setaf and assume it'll do
the right thing with colours 0-15.

> 
> That being said, perhaps the better way of resolving the issue would
> be for tmux to have its own termcap/terminfo entries (I see from the
> TODO file that you have been considering this).  As it stands right
> now, tmux assumes that all 256/88/16-colour terminals support
> aixterm colours.  At least one 256-colour terminal (i.e. fbterm)
> does not.  This wouldn't be an issue if not for the fact that
> 256-colour tmux relies on the 'screen-256color' termcap/terminfo
> entry, which yields ANSI colours for indices 0-7, aixterm colours
> for indices 8-15, and xterm-256 colours for indices 16-255 (for the
> sake of saving characters).  Were tmux to have its own 256-colour
> termcap/terminfo entry it would seem best to use the same set of
> escape sequences (i.e. xterm-256) for all colours (or at least for
> non-ANSI colours).  Then applications running in tmux and relying on
> termcap/terminfo would not be coerced into using aixterm colours,
> but the aixterm colours would be still be available for explicit
> use.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users

Re: support for version blocks in tmux.conf

[Matthias Lederhofer]

Maybe you could use a shell script wrapper around tmux to run `tmux -f
~/.tmux-1.6.conf` and `tmux -f ~/.tmux-1.5.conf`?  These files could
include a comman .tmux.conf too to keep the version specific files
small.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users

Re: How to escape in tmux?

[Frank Terbeck]

Nicholas Marriott wrote:
[...]
> Home and End may not work right for some reason but Esc/Esc will always
> work.

Indeed. (Though, ESC may register with a delay.)

IIRC, the OPs issue was with zsh. If so, the `$terminfo' solution on
this page is the most-portable, fully-automatic way to make special keys
work reliably in zsh's line editor:

  


Regards, Frank

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users