On Fri, Mar 25, 2011 at 2:29 AM, Paul Grove wrote:
> Kevin,
>
> According to the tmux man page, TERM must be set to screen.
You have misunderstood. tmux is a terminal which must be identified as
screen. gnome-terminal is a terminal which must also be identified by
TERM, but "screen" is incorrect
On Thu, Mar 24, 2011 at 10:56 AM, Paul Grove wrote:
> Hi, I hope you can help,
>
> my problem is that outside of tmux cat -vt followed by Alt-Up produces
> ^[[1;3A where as inside tmux the same thing produces ^[[1;;A I beleive
> that this is the cause of misbehavior of some of my key bindings in
>
On Sun, Mar 13, 2011 at 6:46 PM, Nicholas Marriott
wrote:
>>
>> The current patch has been tested with xterm and a custom version
>> of Putty. As mentioned in the patch header, the reset sequence
>> only works on xterm when you set a default cursor colour, (by
>> command line "xterm -cr blue" for
On Thu, Mar 10, 2011 at 10:14 AM, Chas. Owens wrote:
> I want to sent an escape code to my controlling terminal. tmux seems
> to be eating them. Is there some method of asking tmux to send an
> escape code for me?
>
Not in any released version. Reportedly this was checked in a few days
ago, but
On Fri, Mar 4, 2011 at 10:42 AM, Micah Cowan wrote:
> (03/04/2011 10:37 AM), Kevin Goodsell wrote:
>>
>> Huh, I thought the limitation was 200-and-something columns. Actually,
>> in gnome-terminal I get 223 as the last responsive column, which would
>> map to the byte
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-col panes), but don't recall running into it before.
Huh, I thought the limitation was 200
On Thu, Mar 3, 2011 at 5:41 PM, Micah Cowan wrote:
> 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
2011/3/3 Nicholas Marriott :
>
> I can't test offhand so I might be wrong but IIRC gnome-terminal only
> does this when the application hasn't enabled the mouse? When it does,
> gnome-terminal sends standard xterm mouse input.
>
I believe VTE (gnome-terminal) converts mouse wheel events to up/down
On Thu, Mar 3, 2011 at 12:08 PM, Nicholas Marriott
wrote:
> Oh hmm. Remind me why we need to do that?
>
What would the alternative be? There are a lot of escaping schemes
that could be used, but surely some form of escaping is necessary if
arbitrary strings are to be passed through (or an alterna
On Thu, Mar 3, 2011 at 1:07 AM, Nicholas Marriott
wrote:
> This doesn't seem to work, I'm trying this in xterm:
>
> printf '\033Ptmux;\033]12;blue\007\033\\'
>
> Looks like it is trimming out the second \033. I don't really
> have time to investigate much further now, I guess you need a different
On Mon, Feb 14, 2011 at 12:19 PM, Nicholas Marriott
wrote:
> I haven't forgotten about this I've just been busy, sorry.
>
OK, good. Thanks for letting me know -- I was about ready to send a
"hey what happened to this" email. I'll be patient.
-Kevin
--
On Fri, Jan 28, 2011 at 12:36 PM, Nicholas Marriott
wrote:
> input_dcs_dispatch should log the input string but otherwise this looks
> fine on a quick read.
Here's an updated patch with logging of the string. No other changes.
By the way, while testing I noticed that the logging in
input_csi_dis
On Fri, Jan 28, 2011 at 12:36 PM, Nicholas Marriott
wrote:
> input_dcs_dispatch should log the input string but otherwise this looks
> fine on a quick read.
>
This was something that occurred to me, but the string is likely to
include non-printable characters. Should it be logged as-is in spite
o
This patch allows applications to send control sequences to the
underlying terminal by using DCS. It adds the dcs_escape state to the
input state machine, allowing ESC characters in the dcs_handler state.
Following an ESC, a backslash is interpreted as the end of the DCS
string and any other charac
In input.c, several of the input_enter_* functions do this:
ictx->input_len = 0;
This is intended to be the number of characters in ictx->input_buf.
However, a few functions use input_buf without checking input_len. You
can see the effect of this in the following example:
$ echo -e '\e]1;Ran
I've noticed that tmux can be "frozen" by doing something like this:
$ echo -e '\e_'
This probably shouldn't be much of a surprise given the definition of
the state machine used in input.c, and maybe it's considered OK. A
quick test show that xterm also has this problem, but VTE
(gnome-terminal
On Fri, Jan 21, 2011 at 12:38 PM, Nicholas Marriott
wrote:
> On Fri, Jan 21, 2011 at 11:04:06AM -0800, Kevin Goodsell wrote:
>>
>> The second approach would require allowing all characters except ESC
>> (and possibly the C1 ST character, but it looks like tmux does not
>&
On Fri, Jan 21, 2011 at 2:10 AM, Nicholas Marriott
wrote:
> I like this idea, DCS or APC with some tmux prefix would seem obvious
> but you'll need a way to escape stuff.
What would such a tmux prefix look like? Is this a standard way of
adding a terminal-specific extension, or do we have to figu
Hello, list.
GNU Screen supports a way to send escape sequences to the underlying
terminal via the Device Control String sequence (though there's some
indication that it may be buggy). I'd like to know if there's a way to
accomplish this in tmux, and if not whether such a feature would be
welcome.
19 matches
Mail list logo
