Incomplete/broken mouse handling in screen

Bug #113227 reported by Evan Klitzke
6
Affects Status Importance Assigned to Milestone
screen (Debian)
Fix Released
Unknown
screen (Ubuntu)
Invalid
Undecided
Unassigned
vim (Ubuntu)
Fix Released
Wishlist
Micah Cowan

Bug Description

Binary package hint: screen

GNU Screen does not properly send mouse events to terminal applications. Some applications (e.g. links/elinks) work correctly in screen, but most (e.g. vim) appear to have broken mouse handling. I'll be linking this to the Debian/Savannah bugs, which have more information.

Related branches

Revision history for this message
In , Adam Lazur (zal) wrote : merging 214083 188202

merge 214083 188202

Revision history for this message
In , Adam Lazur (zal) wrote : Re: Bug#214083: screen: Mouse click events don't work in screen

Morten Bo Johansen (<email address hidden>) said:
> This is basically a follow-up to #188202.
>
> As of 4.0.1-3 this issue is still unresolved here at my end, in that
> mouse clicks in apps such as mc, elinks etc. don't work inside of screen.
>
> This applies both to console mode and in rxvt.

I have no problem with passing mouse clicks to screen in links and
elinks when running withing either rxvt or xterm on my system. This is
with screen 4.0.2-2.

It doesn't work on the console with gpm, but I've never seen it work on
the Linux console (not to say that I've tried all that frequently).

Could you verify that the problem still exists for you in rxvt/xterm?
Thanks :)

--
Adam Lazur, Cluster Monkey

Revision history for this message
In , Morten Bo Johansen (mojo) wrote :

Adam Lazur <email address hidden> wrote:

> Morten Bo Johansen (<email address hidden>) said:
> > This is basically a follow-up to #188202.

> > As of 4.0.1-3 this issue is still unresolved here at my end, in that
> > mouse clicks in apps such as mc, elinks etc. don't work inside of screen.

> > This applies both to console mode and in rxvt.

> I have no problem with passing mouse clicks to screen in links and
> elinks when running withing either rxvt or xterm on my system. This is
> with screen 4.0.2-2.

Hi Adam,

Here is a small outline of some cases where it works and where it
doesn't. Legend: "+": works, "-": doesn't work

Application Screen/Console Screen/XFree86/Rxvt Console XFree86/Rxvt

Lynx - - - +
Elinks - + + +
W3m - - + +
Jed - - + +
Mc - - + +
Slrn - - - +

As you can see "nothing works" with screen on the console and only
with elinks in an rxvt.

> It doesn't work on the console with gpm, but I've never seen it work on
> the Linux console (not to say that I've tried all that frequently).

Should it be any different from ordinary console behaviour in this
respect? Jed, mc and elinks actually do provide mouse support on the
console (Lynx could be made to, if one recompiles ncurses with support
for mouse events and then compiles Lynx against it) so I think it ought
to work in screen too..?

Screen version: 4.00.02 (FAU) 5-Dec-03
$TERM inside screen: "screen-bce"
$TERM outside screen/console: "linux"
$TERM outside screen/rxvt: xterm-xfree86

I am available for more info and debugging if you need it.

Thanks,

Morten

Revision history for this message
In , Justin Pryzby (justinpryzby-users) wrote : moreinfo

tag 188202 moreinfo
thanks

Please close this bug if the submitter has responded by 2006-01-01.

--
Clear skies,
Justin

Revision history for this message
In , Justin Pryzby (justinpryzby-users) wrote : your bug -- screen: Mouse click events don't work in screen

Does this bug still apply to recent screen packages?

Thanks.

--
Clear skies,
Justin

References

[0] http://bugs.debian.org/214083

Revision history for this message
In , Christopher Zimmermann (madroach) wrote : screen: still applies at least to mc and w3m

Package: screen
Version: 4.0.2-4.1
Followup-For: Bug #214083

Hi,
I just tried it for w3m and mc on console and xterm.
Both work without screen and don't work in screen.
You should be able to reproduce this quiet easily. Just try to run
w3m/mc from plain console/xterm and click on directory/link. Then try it
within screen.

Regards,
Christopher

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: sparc (sparc64)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.16
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages screen depends on:
ii base-passwd 3.5.11 Debian base system master password
ii debconf 1.4.71 Debian configuration management sy
ii libc6 2.3.6-3 GNU C Library: Shared libraries an
ii libncursesw5 5.5-1 Shared libraries for terminal hand
ii libpam0g 0.79-3.1 Pluggable Authentication Modules l
ii passwd 1:4.0.14-9 change and administer password and

screen recommends no packages.

-- debconf information:
  screen/old_upgrade_prompt: false

Revision history for this message
In , Adam Lazur (zal) wrote : [jelly@srce.hr: Bug#188202: ...]

----- Forwarded message from Zoran Dzelajlija <email address hidden> -----

> Date: Thu, 18 May 2006 19:11:27 +0200
> Message-ID: <email address hidden>
> User-Agent: Mutt/1.5.11
> Resent-From: Zoran Dzelajlija <email address hidden>
> Resent-To: <email address hidden>
> Resent-Cc: Adam Lazur <email address hidden>
> Resent-Date: Thu, 18 May 2006 17:33:59 UTC
> Resent-Message-ID: <email address hidden>
> Resent-Sender: Debian BTS <email address hidden>
> Resent-Date: Thu, 18 May 2006 10:33:59 -0700
> From: Zoran Dzelajlija <email address hidden>
> To: <email address hidden>
> Reply-To: Zoran Dzelajlija <email address hidden>, <email address hidden>
> Subject: Bug#188202: ...
>
> FWIW, screen 4.0.2-4.1 (in both stable and unstable) works fine in rxvt
> and xterm with elinks. This bug can be closed.
>
>

----- End forwarded message -----

--
Adam Lazur

Revision history for this message
In , Evan Klitzke (eklitzke2) wrote : Sort of applies to 4.0.3

I don't know a lot about how mouse handling is done in console
applications, but this is definitely application-specific. The latest
screen from unstable (4.0.3-0.3+b1) _will_ pass mouse clicks to
links/elinks in gnome-terminal. It will not, however, pass mouse clicks
to vim. For example, try opening a buffer in vim, and then
entering :tabe some_new_file in command mode. This will bring up a small
tab at the top of the terminal showing all of the vim tabs open. Outside
of a screen environment, it is possible to click these tabs to switch
buffers. Within screen, clicking the tabs produces no effects
whatsoever. Likewise, it is not possible to use the mouse wheel to
scroll through a text buffer in vim when vim is being run through
screen.

It seems to me that there must be (at least) two separate ways to do
mouse events in a terminal, and screen is only handling one of them
correctly. I think we need a console programming guru to come in and
explain what is going on, and hopefully submit a patch so that screen
can handle the broken cases correctly.

Revision history for this message
Evan Klitzke (eklitzke2) wrote :

Binary package hint: screen

GNU Screen does not properly send mouse events to terminal applications. Some applications (e.g. links/elinks) work correctly in screen, but most (e.g. vim) appear to have broken mouse handling. I'll be linking this to the Debian/Savannah bugs, which have more information.

Revision history for this message
Evan Klitzke (eklitzke2) wrote :

Apparently I can't add bugs that point to GNU Savannah in LP, but the relevant Savannah bug (which is actually quite old...) is http://savannah.gnu.org/bugs/?14930

Micah Cowan (micahcowan)
Changed in screen:
status: Unconfirmed → Confirmed
Revision history for this message
Micah Cowan (micahcowan) wrote :

Note that the debbug is marked as done. It should probably be reopened if you are experiencing a problem and can show that it is screen's fault.

HOWEVER: I've found that typing ":set ttymouse xterm" from within vim fixes the issue, so it seems very likely that the problem does not reside with screen at all. 'ttymouse' is only automatically set to "xterm" if the terminal begins with one of xterm, nxterm, kterm, mlterm, or rxvt. Perhaps it can be simply fixed if vim includes "screen" in that list.

I'm rejecting the bug on screen, and opening it for vim.

Changed in screen:
status: Confirmed → Rejected
Changed in screen:
status: Unknown → Fix Released
Revision history for this message
Micah Cowan (micahcowan) wrote :
Changed in vim:
assignee: nobody → micahcowan
status: Unconfirmed → Confirmed
status: Confirmed → Unconfirmed
Micah Cowan (micahcowan)
Changed in vim:
status: Unconfirmed → In Progress
Revision history for this message
Micah Cowan (micahcowan) wrote :

It appears that the patch I've submitted to vim-dev will be accepted for inclusion: http://tech.groups.yahoo.com/group/vimdev/message/46854

For reference, here is the patch I submitted. I expect to roll a debdiff against Gutsy's vim soon.

The following known issue remains: this patch will cause vim to detect screen as supporting the "old style" xterm-style mouse protocol, (ttymouse=xterm), and send screen the appropriate control sequence to initiate that protocol. This is fine even when screen isn't running under a terminal that supports that protocol, as screen notices this and only forwards the "activate mouse" sequence to the terminal if the terminal claims to be xterm or rxvt.

However, there appears to be now way for vim to automatically detect support for the "new style" protocol (ttymouse=xterm2). The way vim does this is to send the xterm "request version" control sequence and listen for the response. Screen does not support the "request version" sequence, and will not forward it on, so there is no way for vim to know whether it should attempt to activate it or not. What this means practically, is that vim will automatically enable mouse click-and-release tracking when it sees that the terminal is "screen"; but it will never automatically enable click-and-drag tracking (which is needed to "select" things with the mouse), as it would do when directly running under a modern xterm, since it will be unable to ascertain whether it is safe to do so.

This can be worked around in the .vimrc (as indeed, the original problem could have been: but having vim just do it automatically seemed nicer :) ), by adding something like:

if &term =~ "^screen"
    set ttymouse=xterm2
endif

Of course, this will still fail if you happen to run screen under an old-style xterm that doesn't support the newer protocol.

Micah Cowan (micahcowan)
Changed in vim:
importance: Undecided → Wishlist
Revision history for this message
Micah Cowan (micahcowan) wrote :

patch is in latest upstream release vim-7.1. I'll roll a debdiff soon!
Keep in mind, though, that if you want full selection-dragging support, you still have to set ttymouse=xterm2 yourself; the best this patch can do is protocol 1 xterm, until such a time that terminfo supplies a better means for detecting mouse support.

Revision history for this message
Micah Cowan (micahcowan) wrote :

Whoops! Heh, completely the wrong bug.

Revision history for this message
Micah Cowan (micahcowan) wrote :

Er, no its not (sorry, working on another screen bug as well).

Revision history for this message
Micah Cowan (micahcowan) wrote :

*Sigh*, just ignore me. It is _not_ yet in current upstream: I was looking for the wrong text string.

Revision history for this message
Micah Cowan (micahcowan) wrote : [PATCH] Re: Incomplete/broken mouse handling in screen

A debdiff to enable mouse detection for the screen terminal, within vim. Also includes the fix for bug 86916.

The debdiff has been tested in Gutsy (under qemu); the code changes have also been tested in Feisty as direct modifications to upstream source (unpackaged).

Revision history for this message
Colin Watson (cjwatson) wrote :

vim (1:7.1-000+1ubuntu2) gutsy; urgency=low

  [ Micah Cowan ]
  * patches/screen-mouse-support.diff:
    - Enable detection of GNU screen as a mouse-capable terminal
      (LP: #113227)
  * patches/proc-filetype-detection-fix.diff:
    - Fix detection of files of type Oracle ProC (LP: #86916)

  [ Colin Watson ]
  * patches/debchangelog_launchpad.diff:
    - Highlight Launchpad bug-closing syntax in debian/changelog files.

 -- Colin Watson <email address hidden> Wed, 04 Jul 2007 04:38:55 +0100

Changed in vim:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.