Re: Two little features (and a bounty?)

[Dan Mahoney, System Admin]

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 (terminal.app 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 https://savannah.gnu.org/bugs/?17310. 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.

-Dan

--

"Station!"

-Bill & Ted's Bogus Journey

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------