[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Two little features (and a bounty?)

From: Dan Mahoney, System Admin
Subject: Re: Two little features (and a bounty?)
Date: Fri, 25 Jul 2008 00:29:02 -0400 (EDT)
User-agent: Alpine 1.10 (BSF 962 2008-03-14)

On Thu, 24 Jul 2008, Micah Cowan wrote:

Is there a way to trace if this is happening?  I've given you the
applications I use.  Micah, I've been a user and advocate of wget for
many years.  If you would like a shell, please let me know.

Well, if you activate logging in the screen window, you can check for
the presence of the "send mouse codes" request sequence. It'll be one of
\E9h, \E1000h, or \E1001h.

If that's the case, there's really nothing we can do until terminfo
supports a way of advertising DEC/xterm mouse capabilities (kmous
doesn't really cut it).

..if (windowtitle =~ /^nano/) { set sendmouseevents = 1; } would suffice
just fine.  Or just give us an option to toggle mouse events on or off
by default.  Or a ctrl-a :mouseon! My xterm doesn't know what on the
other end of an SSH session is requesting or not, it just happily sends
the click events down the pipe.  Aware applications use them.  Unaware
apps discard them.

That's unlikely to be true. The applications on the other end of the SSH
tunnel requested the click events, first (based on the TERM env var
having something like "xterm" in it: they check for that value
explicitly, but usually don't recognize "screen" as a mouse-capable term
name). Try running your ssh session under script, and check for the
\E1001h, etc, sequences, in the resulting typescript.

This is wrong. Setting the $TERM to "xterm" within screen does not cause nano -m to work for me.

As far as I know, once a terminal session is negotiated, settings don't change. Screen is particularly obnoxious about intercepting and not passing down the pipe things it doesn't understand.

You're telling me that in the following chain...

[1 local window mananger] -- [2 xterm] -- [3 ssh] -- [4 sshd] -- [5 shell] -- [6 application]

That somehow #6 can tell #2 or even #1 not to send their events? I think the "local" terminal is far dumber than that.

You've mentioned Nano, but that actually works for me (it uses ncurses,
which assumes decent mouse support if kmous is advertised, which screen
does), so long as mouse support has been enabled ("nano -m" or typing
M-m). I know that Vim and some other apps do an explicit check for the
value of TERM, though, which is why they can't be resolved without
configuration adjustments.

My current environment: Mac with Xterm ( doesn't send mouse events). Also, windows machine with putty, or Linux machine with gnome-terminal.

All have the same issue.  Before I start screen -q, nano -m works fine.

Blanket sending of mouse codes without them being requested is bad
behavior, and would result in spewing codes to the screen in some cases
(say, when you suspend nano to work in your shell). The application has
to be expecting them.

Yes, and nano is expecting them when I start it with -m (within screen or not).

..why would I suspend nano to work in my shell. That would KINDA defeat the purpose of running screen :)

I'd need more info on the printing stuff, as I never use it. I assume
we're talking about the Print Window / Redirect to Printer feature Xterm
has, that's tracked at I don't
know enough to even know whether it's even practical to "fix" screen for
use with that, but a monetary incentive for fixing it would at least
motivate me to dig in a bit more (TBH, without that incentive it drops
to the bottom of my to-do list: not enough demand AFAICT).

Expanded on in a different response.  Perhaps to be forked.




-Bill & Ted's Bogus Journey

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]