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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jul 22, 2024 at 11:20 AM Greg Wooledge <greg@wooledge.org> wrote:

On Mon, Jul 22, 2024 at 17:08:15 +0200, Thomas Schmitt wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jul 22, 2024 at 17:08:15 +0200, Thomas Schmitt wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Greg Wooledge wrote:

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.


Justin Piszcz wrote:

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jul 22, 2024 at 11:23:19 -0400, Justin Piszcz wrote:

On Mon, Jul 22, 2024 at 11:20 AM Greg Wooledge <greg@wooledge.org> wrote:

On Mon, Jul 22, 2024 at 17:08:15 +0200, Thomas Schmitt wrote:

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Greg Wooledge wrote:

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-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Greg Wooledge wrote:

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.

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

Balasubramanian Ravuthan wrote:
> > 5. What will be the impact for upgrading Debian 10 with Kernel 4.19 to
> > Debian 11 with Kernel 5.10.
I wrote:
> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Max Nikulin wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)