Subject: Two little features (and a bounty?)

From: "Dan Mahoney, System Admin" <[email-masked]>
Date: Thu, 24 Jul 2008 18:39:47 -0400 (EDT)

Hey all,

I need two features added to screen, but I'm not a coder.  I can (and 
have) discussed on this list, as well as having seen these features 
justified and explained on mailing lists before, but I don't believe they 
work at this time.

1) Make printing work.  And by that I mean make it work JUST as it would 
work without screen, i.e. not "buffer" and send a bunch of printer 
stop/start sequences every 30 characters -- many SSH applications 
interpret that stop sequence as a page feed.

2) Make mouse work.  I haven't seen much with this.

I'm willing to toss something monetary at a developer or developers who 
can look at this and make it happen.

Any takers?

-Dan Mahoney

-- 

"It would be bad."

-Egon Spengler, "Ghostbusters"

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

_______________________________________________
screen-users mailing list
[email-masked]
http://lists.gnu.org/mailman/listinfo/screen-users

---

From: "Tom Scogland" <[email-masked]>
Date: Thu, 24 Jul 2008 17:42:29 -0500

What do you mean about the mouse? It already sends mouse codes through from
a terminal...

On Thu, Jul 24, 2008 at 5:39 PM, Dan Mahoney, System Admin <
[email-masked]> wrote:

> Hey all,
>
> I need two features added to screen, but I'm not a coder.  I can (and have)
> discussed on this list, as well as having seen these features justified and
> explained on mailing lists before, but I don't believe they work at this
> time.
>
> stop/start sequences every 30 characters -- many SSH applications interpret
> that stop sequence as a page feed.
>
> I'm willing to toss something monetary at a developer or developers who can
> look at this and make it happen.
>
> Any takers?
>
> -Dan Mahoney
>
> --
>
> "It would be bad."
>

-- 
-N
AKA:Tom Scogland
I am enough of an artist to draw freely upon my imagination. Imagination is
more important than knowledge. Knowledge is limited. Imagination encircles
the world.
-Albert Einstein
_______________________________________________
screen-users mailing list
[email-masked]
http://lists.gnu.org/mailman/listinfo/screen-users

---

From: Micah Cowan <[email-masked]>
Date: Thu, 24 Jul 2008 15:58:48 -0700

Perhaps he's referring to the fact that it won't work until the
application requests mouse tracking, and several applications don't
request mouse tracking from screen.

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).

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).

- -Micah

Tom Scogland wrote:
> What do you mean about the mouse? It already sends mouse codes through
> from a terminal...
> 
> On Thu, Jul 24, 2008 at 5:39 PM, Dan Mahoney, System Admin
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hey all,
> 
>     I need two features added to screen, but I'm not a coder.  I can
>     (and have) discussed on this list, as well as having seen these
>     features justified and explained on mailing lists before, but I
>     don't believe they work at this time.
> 
>     1) Make printing work.  And by that I mean make it work JUST as it
>     would work without screen, i.e. not "buffer" and send a bunch of
>     printer stop/start sequences every 30 characters -- many SSH
>     applications interpret that stop sequence as a page feed.
> 
>     I'm willing to toss something monetary at a developer or developers
>     who can look at this and make it happen.
> 
>     Any takers?
> 
>     -Dan Mahoney
> 
>     -- 
> 
>     "It would be bad."
> 
>     [email-masked] <mailto:[email-masked]>
> I am enough of an artist to draw freely upon my imagination. Imagination
> is more important than knowledge. Knowledge is limited. Imagination
> encircles the world.
> -Albert Einstein
> 
> 
> ------------------------------------------------------------------------
> 

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer,
and GNU Wget Project Maintainer.
http://micah.cowan.name/

---

From: "Dan Mahoney, System Admin" <[email-masked]>
Date: Thu, 24 Jul 2008 19:26:06 -0400 (EDT)

On Thu, 24 Jul 2008, Tom Scogland wrote:

> What do you mean about the mouse? It already sends mouse codes through from a terminal...

Using gnome-terminal under linux, to a FreeBSD 6.2 system.  Mouse works.

I fire up screen (with screen 4.00.02 (FAU) 5-Dec-03 built from ports) and 
it doesn't in either Alpine or Nano, both of which otherwise support it.

Unlike printing, I don't know what terminal codes to look for to know if 
the mouse is supported.

-Dan

> 
> On Thu, Jul 24, 2008 at 5:39 PM, Dan Mahoney, System Admin <[email-masked]> wrote:
>       Hey all,
>
>       I need two features added to screen, but I'm not a coder.  I can (and have) discussed on this list, as well as having seen these features justified
>       and explained on mailing lists before, but I don't believe they work at this time.
>
>       1) Make printing work.  And by that I mean make it work JUST as it would work without screen, i.e. not "buffer" and send a bunch of printer
>       stop/start sequences every 30 characters -- many SSH applications interpret that stop sequence as a page feed.
>
>       I'm willing to toss something monetary at a developer or developers who can look at this and make it happen.
>
>       Any takers?
>
>       -Dan Mahoney
>
>       --
>
>       "It would be bad."
>
> I am enough of an artist to draw freely upon my imagination. Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the
> world.
> -Albert Einstein
> 
>

-- 

"I am a professional drinker, and I know that that was NOT Jose Cuervo!"

"Well, what was it then?"

"I think it was some mixture of Rubbing Alcohol, and Desenex(TM) Foot
Powder, because my feet feel okay, and my back doesn't hurt, but my
stomach is killing me!"

-Dan Mahoney, Costa Rica, August 12th, 1994

---

From: Micah Cowan <[email-masked]>
Date: Thu, 24 Jul 2008 16:43:24 -0700

Dan Mahoney, System Admin wrote:
> I fire up screen (with screen 4.00.02 (FAU) 5-Dec-03 built from ports)
> and it doesn't in either Alpine or Nano, both of which otherwise support
> it.

Nano works for me, at least after I type M-m. It doesn't work outside of
screen unless I type M-m, either.

I don't have Alpine.

But as previously mentioned, the problem isn't that screen doesn't
support terminal mouse codes; the problem is that there is no mechanism
for screen to advertise to applications that it supports it, and so many
applications won't send the codes to request that support.

This is a terminfo issue, and I hope at some point to get together with
the ncurses folks and whoever else it might concern, to work towards
resolution of this problem, and some others. However, it's not going to
happen overnight, and every mouse-capable application will need to
adjust to that mechanism, once it exists.

I have been successfully using both Emacs and Vim under screen with
mouse support. Both required configuration adjustments to make it happen.

- --
Micah J. Cowan

---

From: "Dan Mahoney, System Admin" <[email-masked]>
Date: Thu, 24 Jul 2008 19:43:47 -0400 (EDT)

On Thu, 24 Jul 2008, Micah Cowan wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

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.

> supports a way of advertising DEC/xterm mouse capabilities (kmous

..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.

> to the bottom of my to-do list: not enough demand AFAICT).

http://www.mail-archive.com/[email-masked]/msg01387.html

Additionally to the requests I've made there -- a possible option is to 
disable the window-switching commands (in fact, disable ctrl-a entirely so 
the screen switching doesn't hose the print job -- but in reality the 
print comes over the wire so fast it's done in a second, on any modern 
connection).

Contact me out of band to discuss further if you want to pursue this 
route.

-Dan Mahoney

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFIiQko7M8hyUobTrERAlVSAKCEitiPt8GnjcZi3kMC1fF1sNi2RgCfZ8Ej
> zbV+wJGwShYvItmMt7K0nso=
> =6noM
> -----END PGP SIGNATURE-----
>

-- 

"When I'm lost, and confused, and trying to make a U-turn, nothing annoys
me more than someone telling me to watch out for the tombstone!"

"How often does that happen, Fab?"

-David Feld & Tom Fabry, sometime in High School.

---

From: Micah Cowan <[email-masked]>
Date: Thu, 24 Jul 2008 17:06:14 -0700

(My Thunderbird screws up the quoting, yours appear "deeper" than mine.)

Dan Mahoney, System Admin wrote:
>> 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.

>> 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.

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.

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.

>> http://www.mail-archive.com/[email-masked]/msg01387.html

Hm, that doesn't look unachievable. :)

- --
Micah J. Cowan

---

From: Thomas Adam <[email-masked]>
Date: Fri, 25 Jul 2008 01:08:54 +0100

On Thu, 24 Jul 2008 16:43:24 -0700
> mouse support. Both required configuration adjustments to make it

Can you share this information, please?  Sounds interesting.  :)

-- Thomas Adam

-- 
"It was the cruelest game I've ever played and it's played inside my
head." -- "Hush The Warmth", Gorky's Zygotic Mynci.

---

From: Micah Cowan <[email-masked]>
Date: Thu, 24 Jul 2008 17:15:17 -0700

> Can you share this information, please?  Sounds interesting.  :)

FWIW, I submitted a patch against Vim at one point to enable it
automatically. Bram said it looked good, but hasn't applied it yet
AFAIK. However, it has been applied against Vim in recent Ubuntu releases.

https://bugs.launchpad.net/debian/+source/screen/+bug/113227

In my .vimrc for other Vims, I have:

if &term == 'screen'
    set mouse=nic
    set ttymouse=xterm2
endif

(you might want "set mouse=a", or some other setting, above).

In my .emacs, I have:

(require 'xt-mouse)
(xterm-mouse-mode t)
(mouse-wheel-mode t)

- --
Micah J. Cowan

---

From: "Trent W. Buck" <[email-masked]>
Date: Fri, 25 Jul 2008 11:36:21 +1000

> applications interpret that stop sequence as a page feed.

I don't know what you're talking about.  Can you provide step-by-step
instructions to reproduce this bug?

> who can look at this and make it happen.

Mouse works for me within screen:

    xterm -e screen emacs -nw -Q -f xterm-mouse-mode

Note that this requires Emacs to be compiled with X enabled (i.e. it
doesn't work in emacs22-nox).  The scroll wheel also works, but
requires bindings.  From my .emacs:

    (when (and (fboundp 'xterm-mouse-mode)
               (not window-system)
               (featurep 'mouse))
      (xterm-mouse-mode +1)
      (when (fboundp 'mwheel-scroll)
        (global-set-key (kbd "<mouse-4>") 'mwheel-scroll)
        (global-set-key (kbd "<mouse-5>") 'mwheel-scroll)))

PS: note that (not window-system) has the wrong semantics in CVS Emacs
with mtty, e.g. if your first Emacs window is a native X window but
then you start an mtty emacsclient inside screen.

---

From: "Dan Mahoney, System Admin" <[email-masked]>
Date: Fri, 25 Jul 2008 00:10:36 -0400 (EDT)

> instructions to reproduce this bug?

It's right in the gnu screen man page.  Without screen, if you're in (say) 
pine, or use a program such as ansiprint to print a file, it will send, 
literally, to the screen:

[printer on code as described in termcap/terminfo]
[your file]
[possibly a formfeed]
[printer off]

Now, what screen does, is the following:

[printer on code as described in termcap/terminfo]
[small chunk of your file]
[printer off]
[printer on code as described in termcap/terminfo]
[another small chunk of your file]
[printer off]
[printer on code as described in termcap/terminfo]
[yet another small chunk of your file]
[printer off]
[printer on code as described in termcap/terminfo]
[even another small chunk of your file]
[printer off]
[printer on code as described in termcap/terminfo]
[and another small chunk of your file]
[printer off]

And so on.  And it thinks it's doing you a favor.

Screen's manpage sums this logic up:

When the `po' and `pf' capabilities are present in the terminal's term-
cap  entry,  applications running in a screen window can send output to
the printer port of the terminal.  This allows a user to have an appli-
cation  in one window sending output to a printer connected to the ter-
minal, while all other windows are still active (the  printer  port  is
enabled  and  disabled  again  for  each  chunk of output).  As a side-
effect, programs running in different windows can send  output  to  the
printer  simultaneously.   Data sent to the printer is not displayed in
the window.  The info command displays a line starting `PRIN' while the
printer is active.

---End Manpage Section---

All the above makes a whole lot of sense on, say, a line printer over 
300BPS with a 20 page document.

On programs like secureCRT (my terminal of choice), all this 
buffer/unbuffer crap causes my laser printer to eject a page because it 
sees every printer-stop sequence as the end of the sequence.  Thus I get 
one PAGE per Chunk.

SecureCRT has a workaround for this -- which basically causes me to have 
to print from my terminal, then say "eject page" in SecureCRT -- so as a 
result of Screen's buffering behavior, SecureCRT also has to buffer, and 
it causes me an extra level of necessary interaction.  Whereas, if screen 
had just passed the sequences along as-is, everything would be fine.

This is a kludge to "background printing" which only makes sense with a 
lot of data, over a slow link.  Any other time, the data is out faster 
than I can possibly even switch windows.  If I don't want my keyboard and 
screen sequences messing up the print job, then I could just have screen 
block my ability to use ctrl-a until the print is done, or I send an abort 
sequence.  That would prevent me from switching windows (and possibly 
MISSING the "printer off" sequence.)

> Mouse works for me within screen:

Then there's likely something wrong with my system or my shell, or my 
termcap, and it is best filed as an OS bug.  Please contact me out of band 
and I can arrange a shell.  It's a public server and has been used to 
test several other pieces of opensource.  Tell me if it works for you on 
my end.

-Dan

-- 

"One...plus two...plus one...plus one."

-Tim Curry, Clue

---

From: "Dan Mahoney, System Admin" <[email-masked]>
Date: Fri, 25 Jul 2008 00:29:02 -0400 (EDT)

> \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.

> 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.

> (say, when you suspend nano to work in your shell). The application has

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 :)

>> 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

---

From: Micah Cowan <[email-masked]>
Date: Thu, 24 Jul 2008 22:36:02 -0700

> cause nano -m to work for me.

It does for me, over your provided ssh access. I'll provide the full
details when I'm done exploring.

> [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.

The question is whether it can tell them _to_ send their events. And
yes, that's accurate: a program that sends the "send mouse events"
sequence to screen will have them passed along to other terms - provided
that screen itself detects that it is being run in a mouse-capable
display (determined by checking for the presence of either "xterm" or
"rxvt" in the TERM value). (This is _exactly_ why terminfo needs to be
extended to allow advertising this feature.) That list ought to be
expanded to include "screen" itself. I thought I remembered patching
that once, but maybe it was a distro-specific patch that didn't make it
upstream, or something.

- --
Micah J. Cowan

---

From: "Dan Mahoney, System Admin" <[email-masked]>
Date: Fri, 25 Jul 2008 01:48:53 -0400 (EDT)

> details when I'm done exploring.

Wait, where are you running screen?  My assumption was that you be running 
it ON prime.gushi.org, not before you ssh in.

When I ssh from my mac to prime, nano -m works.

When I ssh from my mac to prime and start screen -q, nano -m doesn't.

I haven't tried it with screen on the LOCAL end of the SSH connection 
(kinda defeats the point of being able to detach, eh?)

-Dan

> Version: GnuPG v1.4.6 (GNU/Linux)
> iD8DBQFIiWZC7M8hyUobTrERAnGiAJ9zY+YiHDxWfc0gWAoEyYUOoOHJaACfShN+
> +BE7X3/FIP0zx8gmrWtYgC8=
> =B7V2

-- 

"Don't try to out-wierd me.  I get stranger things than you free with my
breakfast cereal."

-Button seen at I-CON XVII (and subsequently purchased)

---

From: Micah Cowan <[email-masked]>
Date: Thu, 24 Jul 2008 22:55:42 -0700

Dan Mahoney, System Admin wrote:
>> Wait, where are you running screen?  My assumption was that you be
>> running it ON prime.gushi.org, not before you ssh in.

Right. I'm doing both.

>> When I ssh from my mac to prime and start screen -q, nano -m doesn't.

When you set TERM=xterm? (That was what we were talking about)

Within screen running on gushi, "TERM=xterm nano -m" gives me mouse
capabilities (but isn't a great idea long-term, as it may well screw up
other things subtly).

- --
Micah J. Cowan

---

From: Micah Cowan <[email-masked]>
Date: Fri, 25 Jul 2008 00:07:45 -0700

Okay, so here's what I've found.

I confirmed that nano and alpine get mouse events outside screen (duh).

I confirmed that alpine _works_ with mouse inside screen, no problems. I
have to set DISPLAY to a fake value, but I had to do that to make it
work outside of screen, too.

I confirmed that nano does _not_ work by default inside of screen. It
doesn't send the "send mouse events" sequence (it sends the \E[?1000h
sequence outside of screen). If I tell screen to send mouse events
anyway, nano -m doesn't process them correctly (clicking in the editor
pane brings up the help screen, instead of just moving the cursor). To
get screen to send mouse events, I did:

  $ printf '\033[?1000h'; nano -m

You'll want to do a

  $ printf '\033[?1000l'

Sometime afterwards to disable the mouse events again.

BTW, I confirmed that, on my home system, nano under screen doesn't work
for me either. However, when I was at work, it worked fine. I just ssh'd
in and verified it works fine. The version for the one that worked is
1.3.<something> on RedHat, yours is 2.0.7, and mine is 2.0.6.

Running

  $ TERM=xterm nano -m

works fine for me in screen.

- --
Micah J. Cowan

---

From: "Trent W. Buck" <[email-masked]>
Date: Fri, 25 Jul 2008 17:32:33 +1000

On Thu, Jul 24, 2008 at 10:36:02PM -0700, Micah Cowan wrote:
> sequence to screen will have them passed along to other terms -
> provided that screen itself detects that it is being run in a
> mouse-capable display (determined by checking for the presence of
> either "xterm" or "rxvt" in the TERM value).

Please clarify: what are the semantics when using screen -x, say with
one TERM=xterm and one TERM=linux ?

Also, does this work correctly with xterm -e screen ssh fooserv screen
emacs -nw -- that is, when the "inner" screen sees TERM=screen rather
than TERM=xterm?  It seems to me that TERM=screen should be included
in the list of term types that screen expects to support mouse inputs.

> (This is _exactly_ why terminfo needs to be extended to allow
> advertising this feature.) That list ought to be expanded to include
> "screen" itself.  I thought I remembered patching that once, but
> maybe it was a distro-specific patch that didn't make it upstream,
> or something.

Oops, I guess that answers my second question :-)

---

From: Micah Cowan <[email-masked]>
Date: Fri, 25 Jul 2008 00:42:25 -0700

> one TERM=xterm and one TERM=linux ?

The one with TERM=xterm will get the mouse-enable sequence passed
through to it (assuming it was attached at the time that sequence was
sent); the TERM=linux one won't.

- --
Micah J. Cowan

---

From: "Trent W. Buck" <[email-masked]>
Date: Fri, 25 Jul 2008 17:52:51 +1000

> sent); the TERM=linux one won't.

Would it be better to have screen "remember" if an enable sequence was
sent, so that if I *later* do

    xterm -e screen -xRR

the *new* xterm will also know about mousiness?  (IIUC, currently the
xterm has to be connected when you do M-x xterm-mouse-mode.)

---

From: Micah Cowan <[email-masked]>
Date: Fri, 25 Jul 2008 00:57:48 -0700

> xterm has to be connected when you do M-x xterm-mouse-mode.)

That's what I thought. However, I just tried it, and I was surprised to
find that it worked fine, even though the xterm connected after Vim had
been started.

- --
Micah J. Cowan

---

From: "Dan Mahoney, System Admin" <[email-masked]>
Date: Fri, 25 Jul 2008 13:50:24 -0400 (EDT)

On Fri, 25 Jul 2008, Micah Cowan wrote:

Yes, I'm top-posting...but it's relevant.

So from Micah's findings, it would almost appear that based on the 
application, there's a number of things that one needs to do to make this 
work.  (xterm value, fake display, manually send the escape sequence, 
etc).

This is definitely something that fits well into some kind of 
documentation grid as to what-setup-requires-what...

I'm not sure if there's anything in screen that can fix it (although I 
think the window-title hack is a neat answer).  I am also not sure if this 
should be brought to the nano/alpine/whatnot developers -- there are at 
LEAST a couple situations where you want a mouse without a display, i.e. 
console-access, where screen is ideal (but then, you have multiple virtual 
consoles).

Let me think on this a bit more -- there's GOT to be a clean way to handle 
this -- Micah, do you think it's relevant to open bugs with the 
appropriate projects?

Or better still, can we come up with a way to define a "test case" for 
mouse under screenable events?

(I had a coworker tell me I should run gpm in my ssh session, to fix 
this...I wonder how right he might have been...other than that I'm under 
freeBSD).

> iD8DBQFIiXvA7M8hyUobTrERAiGEAJ0SD/WQYhtJXFNKH3rHKv+fWWqelgCfeTyY
> 8ZRQh4JTWHzuTEmT9F7wzK0=
> =EDbP

-- 

"You're a thucking reyer!"

-Richard Bozzello, who believed tongue piercing was painless.

---

From: Micah Cowan <[email-masked]>
Date: Fri, 25 Jul 2008 10:59:16 -0700

Dan Mahoney, System Admin wrote:
> application, there's a number of things that one needs to do to make
> this work.  (xterm value, fake display, manually send the escape
> sequence, etc).

No; to my knowledge, the only program I've ever seen require DISPLAY to
be set is alpine, which is kind of retarded.

Manually sending the escape sequence will _not_ work, as I mentioned
previously. It will get screen to send the sequences, to be sure, but it
will not put the application into an accepting state (nano -m would not
accept them properly, despite being in "mouse enabled" mode, unless the
term was "xterm").

> documentation grid as to what-setup-requires-what...

Probably should go on the wiki. http://aperiodic.net/screen/

> think the window-title hack is a neat answer).

Won't work: that'll be equivalent to what I did with "sending the escape
sequence first"; nano still doesn't interpret them.

Even if it did work, it'd be a bad idea, except for your own personal
use. Even if you never suspend nano to work in the shell, other people
certainly may.

> I am also not sure if
> this should be brought to the nano/alpine/whatnot developers -- there
> are at LEAST a couple situations where you want a mouse without a
> display, i.e. console-access, where screen is ideal (but then, you have
> multiple virtual consoles).

AFAICT, nano doesn't explicitly look for xterm; it may well be an
ncurses issue, rather than nano.

> Let me think on this a bit more -- there's GOT to be a clean way to
> handle this -- Micah, do you think it's relevant to open bugs with the
> appropriate projects?

It can't hurt; I had some success with that in Vim. But adding "screen"
to the list of approved terminals is not a good general solution; it
really needs to be addressed in ncurses/terminfo.

> this...I wonder how right he might have been...other than that I'm under

Does gpm work that way? I wouldn't have thought so, but I don't really
know that much about gpm.

I thought it's intended to work on the actual console terms, though,
with the local mouse.

- --
Micah J. Cowan