Hello,
I have also encountered same problem.
Response for DA2 split two or more packets, but tmux does not handle this
correctly.
Attached patch fixes this.
Thanks,
--
IWAMOTO Kouichi ([email protected]/[email protected]/[email protected])
On Sun, 8 Apr 2012 23:42:40 +0100
Michael Simpson <[email protected]> wrote:
> fyi please see forwarded message below.
> Issue started after recently upgrading to -current
> Term is xterm everywhere (except of course within tmux)
> Using tmux within OpenBSD having used ssh from Cygwin to get to OBSD box.
> When starting or re-attaching tmux session I get a series of numbers
> printed after the command prompt.
>
> Please let me know what info I can provide.
>
> ---------- Forwarded message ----------
> From: *Andy Koppe*
> Date: Sunday, April 8, 2012
> Subject: TERM problem with mintty and latest tmux in OpenBSD
> To: Michael Simpson <[email protected] <javascript:_e({}, 'cvml',
> '[email protected]');>>
>
>
> On 5 April 2012 23:51, Michael Simpson wrote:
> > On 5 April 2012 12:53, Andy Koppe wrote:
> >> On 30 March 2012 10:03, Michael Simpson wrote:
> >>> On 29 March 2012 06:29, Andy Koppe wrote:
> >>>
> >>>> I don't see any evidence here that this is a problem with mintty
> >>>> rather than OpenBSD's tmux or xterm terminfo entry. Can you try this
> >>>> using Cygwin's xterm?
> >>>
> >>> Cygwin's xterm works as expected
> >>
> >> Thanks for checking. Sounds like a mintty incompatibility with xterm
> >> then. I'll need your help to try to narrow down the issue though, as I
> >> haven't got access to an OpenBSD system.
> >>
> >> Can you invoke mintty with the --log option for logging output into a
> >> file, do as little as possible to reproduce the problem, and send the
> >> resulting log? The aim here is that I can cat the log file to see the
> >> issue and then try to narrow it down to the problematic control
> >> sequence.
> >>
> >> Regards,
> >> Andy
> >
> > Hi Andy
> >
> > sorry for the late response
>
> Don't be silly, it's me who's being slow here.
>
> > I have attached the log file
> > what i did was ssh to the openbsd box then startede a tmux session,
> > detached from it and reattached then ^d'd both it and the ksh shell
> > back to the originating box
>
> Thanks very much. I've had a look at this, and I don't think this is a
> mintty issue after all. Tmux is requesting the terminal's
> identification code using the control sequence "\e[>c" (where \e
> stands for the ESC character). Mintty replies with its identification
> sequence: "\e[77;10003;0c", whereby 77 is the ASCII code for M and
> 10003 is the mintty version 1.0.3 encoded as
> 10000*major+100*minor+patch.
>
> I'm assuming it's that which you're seeing on the command line, so for
> some reason tmux is letting mintty's response through to the shell as
> keyboard input instead of processing it itself. It requests the ID
> code not just on reattach but also when originally starting the
> session, so maybe it's a timing issue if this doesn't happen when
> creating the session.
>
> Please report this to the tmux developers.
>
> Regards,
> Andy
>
>
>
>
>
>
> >
> > Hope this is of use and please let me know what else i can do
>
>
>
>
> >
> > regards
> > mike
Index: tmux.h
===================================================================
--- tmux.h (revision 2761)
+++ tmux.h (working copy)
@@ -1047,6 +1047,7 @@
#define TTY_UTF8 0x8
#define TTY_STARTED 0x10
#define TTY_OPENED 0x20
+#define TTY_ESCAPE_TIMEOUT 0x40
int flags;
int term_flags;
Index: tty-keys.c
===================================================================
--- tty-keys.c (revision 2761)
+++ tty-keys.c (working copy)
@@ -526,6 +526,11 @@
size++; /* include escape */
goto found_key;
}
+ else {
+ evbuffer_drain(tty->event->input, 1);
+ key = '\033';
+ goto handle_key;
+ }
}
/* Escape and then nothing useful - fall through. */
@@ -535,7 +540,7 @@
* Escape but no key string. If have already seen an escape, then the
* timer must have expired, so give up waiting and send the escape.
*/
- if (tty->flags & TTY_ESCAPE) {
+ if (tty->flags & TTY_ESCAPE_TIMEOUT) {
evbuffer_drain(tty->event->input, 1);
key = '\033';
goto handle_key;
@@ -580,7 +585,7 @@
if (key != KEYC_NONE)
tty->key_callback(key, &mouse, tty->key_data);
- tty->flags &= ~TTY_ESCAPE;
+ tty->flags &= ~(TTY_ESCAPE|TTY_ESCAPE_TIMEOUT);
return (1);
}
@@ -594,6 +599,8 @@
if (!(tty->flags & TTY_ESCAPE))
return;
+ tty->flags |= TTY_ESCAPE_TIMEOUT;
+
while (tty_keys_next(tty))
;
}
Index: tty.c
===================================================================
--- tty.c (revision 2761)
+++ tty.c (working copy)
@@ -145,7 +145,7 @@
}
tty->flags |= TTY_OPENED;
- tty->flags &= ~(TTY_NOCURSOR|TTY_FREEZE|TTY_ESCAPE);
+ tty->flags &= ~(TTY_NOCURSOR|TTY_FREEZE|TTY_ESCAPE|TTY_ESCAPE_TIMEOUT);
tty->event = bufferevent_new(
tty->fd, tty_read_callback, NULL, tty_error_callback, tty);
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
tmux-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tmux-users
