Your message dated Thu, 8 Oct 2009 11:53:52 -0400
with message-id <[email protected]>
and subject line Re: Bug#550237: vim: mouse clicks produce bogus, if clicked
too far to the right.
has caused the Debian Bug report #550237,
regarding vim: mouse clicks produce bogus, if clicked too far to the right.
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
550237: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550237
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: vim
Version: 2:7.2.245-2
Severity: normal
Hi.
I am using quite a large screen (1920x1200) and if I enable mouse support in
vim (:set mouse=a, in my case its in ~/.vimrc), I get wierd results, when I try
to use the mouse on the far right side of the screen. By wierd I mean, that the
clicks are not registred as clicks but as key presses. The keys pressed are
mostly harmless, but it inserts text or deletes lines or does things according
to which key was just recognized.
To reproduce this, open vim on a wide screen (two screens will do, too) or with
a very tiny (narrow) font. And write a long line. On my screen the clicks are
no longer correctly registered after the 223rd column of text, so clicking on
the 224th or any later column brakes the mouse support.
It has obviously something to do with the 223 columns, because, when I increase
the font size, to something, so no 223 columns have room on the screen, the
error is no longer there. When i decrease the size, the limit for the mouse
moves further to the left.
By the way: I had the sam eproblem on an x86 32Bit machine, but I thought it
was a problem with my dual head setup. Now I am using only one screen and get
the same problem.
Greetings
Andre
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-rc2nautsch (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages vim depends on:
ii libacl1 2.2.48-1 Access control list shared library
ii libc6 2.9-27 GNU C Library: Shared libraries
ii libgpm2 1.20.4-3.2 General Purpose Mouse - shared lib
ii libncurses5 5.7+20090803-2 shared libraries for terminal hand
ii libselinux1 2.0.85-4 SELinux runtime shared libraries
ii vim-common 2:7.2.245-2 Vi IMproved - Common files
ii vim-runtime 2:7.2.245-2 Vi IMproved - Runtime files
vim recommends no packages.
Versions of packages vim suggests:
pn ctags <none> (no description available)
pn vim-doc <none> (no description available)
pn vim-scripts <none> (no description available)
-- no debconf information
--- End Message ---
--- Begin Message ---
On Thu, Oct 8, 2009 at 11:19, Andre Naujoks <[email protected]> wrote:
> I am using quite a large screen (1920x1200) and if I enable mouse
> support in vim (:set mouse=a, in my case its in ~/.vimrc), I get wierd
> results, when I try to use the mouse on the far right side of the
> screen. By wierd I mean, that the clicks are not registred as clicks
> but as key presses. The keys pressed are mostly harmless, but it
> inserts text or deletes lines or does things according to which key
> was just recognized.
This is a limitation of terminal emulators. The way they communicate
mouse position only allows for communicating the position up to column
223[0].
Parameters (such as pointer position and button number) for all mouse
tracking escape sequences generated by xterm encode numeric parameters
in a single character as value+32. For example, ! specifies the value
1. The upper left character position on the terminal is denoted as 1,1.
There's nothing Vim can about that.
[0] - http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#Mouse%20Tracking
--- End Message ---