vim: Einfügen per Copy/Paste verlässt Input-Modus

[HumiNi]

Beim Einfügen in eine mit vi geöffnete Textdatei mittels copy/paste über die Maus verlässt der Editor nach paste ungefragt den Input-Modus.

Das würde ich gern abstellen, weiß aber nicht wie. Kann mir jemand helfen? Danke.

[rodney]

Ich verwende vim und nicht den von dir genannten vi (wo auch immer du den her hast). Dort kann ich das von dir beschriebene Verhalten beim Einfuegen (mit und ohne vorheriges :set paste) nicht nachvollziehen.

Edit:Typo

[HumiNi]

(wo auch immer du den her hast).

Gehört zum Basissystem - denke ich.

lrwxrwxrwx 1 root root 20 26. Nov 13:00 /usr/bin/vi -> /etc/alternatives/vi
lrwxrwxrwx 1 root root 17 26. Nov 13:00 /etc/alternatives/vi -> /usr/bin/vim.tiny

erno@gauner:/VMs$ dpkg -S /usr/bin/vim.tiny
vim-tiny: /usr/bin/vim.tiny

[Meillo]

Beschreibe bitte ganz genau was du machst. Schritt fuer Schritt.

Beantworte dabei u.a. folgende Fragen:
- Wie und wo markierst/kopierst du Text?
- Wie oeffnest du den vim? Was machst du dort bis du einfuegst?
- Wie genau fuegst du ein?
- Wie siehst du, dass du nicht mehr im Einfuegemodus bist?
- Passiert das egal welchen Text du einfuegst?

Poste zudem ggf. die Ausgabe von `:set' im vim.

[HumiNi]

Nehmen wir zwei Terminalfenster innerhalb einer graf. Oberfläche, hier Gnome. In A setze ich Kommandos ab, in B ist eine Protokolldatei geöffnet, sagen wir "vi konf.prot".
Hintergrund ist, gezielt Teile der Ausgabe für spärere Recherche zu speichern.
- In B: Taste i -> Inputmodus
- in A: Markieren mit der Maus
- in B: Einfügen mit mittlerer Maustaste

Hier war ich es jahrelang gewöhnt, dass ich direkt weiter schreiben/einfügen konnte. Jetzt bin ich aber im vi-Kommandomodus und muss erst wieder <i> zum Übergang in den Inputmodus drücken. Das Verhalten ist also, als hätte ich unmittelbar nach paste <ESC> gedrückt.

Wie ich es sehe? Z.B. will ich nach einem Textblock "..." einfügen. Das wird aber nicht geschrieben, sondern das letzte Kommando wiederholt.

Gearde will ich es fürs Protokoll in Ruhe nachstellen, da kann ich es nicht reproduzieren, Ich muss mich mal beobachten...

:set
--- Options ---
modified scroll=11 ttyfast ttymouse=xterm
fileencoding=utf-8
fileencodings=ucs-bom,utf-8,default,latin1
runtimepath=~/.vim,/var/lib/vim/addons,/usr/share/vim/vimfiles,/usr/share/vim/vim82,/usr/share/vim/vimf
iles/after,/var/lib/vim/addons/after,~/.vim/after

[Meillo]

Gearde will ich es fürs Protokoll in Ruhe nachstellen, da kann ich es nicht reproduzieren, Ich muss mich mal beobachten...

Klasse! Da haben wir schon den Erfolg meiner Bitte, du moegest genau beschreiben was du gemacht hast. Auf dem Weg zu einem Minimalbeispiel zur Reproduktion findet man naemlich zumeist zu der Stelle an der es haengt. Viel Erfolg!


Ich wuerde vermuten, dass du entweder irgendwelche Steuerzeichen kopiert hast, die bei Einfuegen den Moduswechsel ausfuehren, oder dass du unbewusst eine andere Art von Input (mit Maus, Tastatur, Joystick, ...) erzeugt hast.

[HumiNi]

Jetzt noch einmal für das Protokoll:
In Terminal A bin ich in der bash.
In Terminal B öffne ich eine Protokoll-Datei:

erno@gauner:~$ vi test.prot

In A:

erno@gauner:~$ ls bla
ls: Zugriff auf 'bla' nicht möglich: Datei oder Verzeichnis nicht gefunden

Diese beiden Zeilen werden mit der Maus kopiert. und nach Drücken von <i> in B mit der mittleren Maustaste eingefügt (keine weitere Maus- oder Tastaturaktion!).
Das Ergebnis in B ist:

erno@gauner:~$ ls bla
ls: Zugriff auf 'bla' nicht möglich: Datei oder Verzeichnis nicht gefunden

So weit so gut.
Als nächste Aktion (nach Drücken der mittleren Maustaste) will ich in B die nächste Zeile per Hand schreiben, Hier beginne ich mit ".".
Das Ergebnis ist:

erno@gauner:~$ ls bla
ls: Zugriff auf 'bla' nicht möglich: Datei oder Verzeichnis nicht gefunden
erno@gauner:~$ ls bla
ls: Zugriff auf 'bla' nicht möglich: Datei oder Verzeichnis nicht gefunden

Es wurde also "." als Kommando ausgeführt. Ich habe ungewollt den Eingabe-Modus verlassen.

Wieso?

[Meillo]

Poste mal die Ausgabe von:

Code: Alles auswählen

echo "$PS1" | od -c

(Ich glaube zwar nicht, dass das der richtige Weg ist, aber der Vollstaendigkeit halber wuerde ich das trotzdem pruefen wollen.)


Wiederhole dein Vorgehen und kopiere jeweils einen kleineren Ausschnitt dieses Textes und schaue, ob das Verhalten irgendwann nicht mehr auftritt, dann schaue an welcher Stelle genau es sich aendert.


Es koennte auch eine fehlerhafte Maus sein, die weitere Signale uebermittelt. Ich hatte sowas mal. Teste mal eine andere Maus.

[HumiNi]

Die Idee mit der "kaputten" Maus fand ich erfolgversprechend, half aber leider nicht weiter - keine Änderung.

Ab sofort mit getauschter Maus:
Nor den mit Doppelklick markierten Teil des bash-Promptes eingefügt ud darauf "." gedrückt, bringt folgendes Ergebnis:

erno@gaunererno@gauner

Das Verhalten kenne ich schon länger, Jetzt sitze ich aber nach der Aufrüstung meines PCs um eine SSD an einem neu installiertem, also zienlich jungfräulichem bullseye.

erno@gauner:~$ echo "$PS1"
\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
erno@gauner:~$ echo "$PS1" | od -c
0000000 \ [ \ e ] 0 ; \ u @ \ h : \ w
0000020 \ a \ ] $ { d e b i a n _ c h r
0000040 o o t : + ( $ d e b i a n _ c h
0000060 r o o t ) } \ [ \ 0 3 3 [ 0 1 ;
0000100 3 2 m \ ] \ u @ \ h \ [ \ 0 3 3
0000120 [ 0 0 m \ ] : \ [ \ 0 3 3 [ 0 1
0000140 ; 3 4 m \ ] \ w \ [ \ 0 3 3 [ 0
0000160 0 m \ ] \ $ \n
0000170

Ich bin erstaunt (nach euren bisherigen Antworten), dass dies anscheinend kein config-Verhalten ist.

[Meillo]

erno@gauner:~$ echo "$PS1"
\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
erno@gauner:~$ echo "$PS1" | od -c
0000000 \ [ \ e ] 0 ; \ u @ \ h : \ w
0000020 \ a \ ] $ { d e b i a n _ c h r
0000040 o o t : + ( $ d e b i a n _ c h
0000060 r o o t ) } \ [ \ 0 3 3 [ 0 1 ;
0000100 3 2 m \ ] \ u @ \ h \ [ \ 0 3 3
0000120 [ 0 0 m \ ] : \ [ \ 0 3 3 [ 0 1
0000140 ; 3 4 m \ ] \ w \ [ \ 0 3 3 [ 0
0000160 0 m \ ] \ $ \n
0000170

Ist das Problem auch dann vorhanden wenn du etwas anderes als den Prompt kopierst? Dieser enthaelt ja (fuer die Farben) Escape-Zeichen.

Ich bin erstaunt (nach euren bisherigen Antworten), dass dies anscheinend kein config-Verhalten ist.

Bislang antworte ja fast nur ich und ich habe keine Ahnung von dem was man im Vim so alles konfigurieren kann.

Versuche mal:

Code: Alles auswählen

vim -C datei

Das aktiviert den Kompatibiliaetsmodus. Damit sollte man einiges an Konfigurationszeug ausschliessen koennen.


Btw: Komisch, dass bislang andere Vim-User nichts dazu schreiben. Es ist wie wenn du die einzige Person mit diesem Problem waerst ...

[rodney]

Der Threadersteller nutzt das Paket vim-tiny. DIesen wuerde ich erstmal durch vim ersetzen und diesen dann mit:

Code: Alles auswählen

vim -u NONE

starten und das mit dem Einfuegen nochmal testen

[HumiNi]

Ich habe den Betreff geändert.
Es reicht bereits ein Wechsel des aktiven Fensters, um den Eingabemodus zu verlassen.

Und noch mysteriöser:
Ich habe festgestellt, dass mein Problem erstaunlicherweise nur bei Tastatureingaben auftritt. Nachträgliches Einfügen per Maus ist weiterhin möglich. Dieses Verhalten hat mich ziemlich in die Irre geführt.
Ändert aber nichts an dem nervigen Verhalten.

Bezüglich des Hinweises vim vs vim.tiny: Ich habe vim als aufgehübschte, bunte Version von vim.tiny verstanden. Die grundsätzlichen Editorfunktionen sollten sich nicht unterscheiden.

[Meillo]

Ich habe den Betreff geändert.
Es reicht bereits ein Wechsel des aktiven Fensters, um den Eingabemodus zu verlassen.

Interessant.

Und noch interessanter: Ausser dir scheint dieses Verhalten niemand zu haben oder auch nur zu kennen ...

Bezüglich des Hinweises vim vs vim.tiny: Ich habe vim als aufgehübschte, bunte Version von vim.tiny verstanden. Die grundsätzlichen Editorfunktionen sollten sich nicht unterscheiden.

Ob sie sich nun unterscheiden *sollte* oder nicht: Unterscheidet sie sich?

[rodney]

Falls der Xserver und nicht Wayland genutzt wird:

1. /usr/bin/xterm starten
2. dort ausfuehren:
2.1 xrdb -remove *
2.2 /usr/bin/xterm
3. Im neuen xterm dann: vim.tiny -u NONE und schauen ob das Verhalten immer noch auftritt.

P.S. Auch koennte mal getestet werden ob das Verhalten auch auftritt wenn anstatt einem Mittelklick (Maus) die Tastenkombination Shift-Ins zum Einfuegen verwendet wird

[HumiNi]

Und noch interessanter: Ausser dir scheint dieses Verhalten niemand zu haben oder auch nur zu kennen ...

Scheint mir auch so. Genau deshalb zerbreche ich mir seit Tagen den Kopf "Was habe ich, was ihr nicht habt?"
Vielleicht das?

Code: Alles auswählen

erno@gauner:~$ echo $DESKTOP_SESSION 
gnome-flashback-metacity

Ob sie sich nun unterscheiden *sollte* oder nicht: Unterscheidet sie sich?

Kann ich nicht beantworten. Das Paket wird standardmäßig nicht installiert. Ist mir aber auch erst jetzt aufgefallen. Alles, was ich als "gelernter" UNIX-Mensch von einem Editor kenne und erwarte, bietet mir das Teil, was sich nach dem Aufruf von "vi" öffnet.

Code: Alles auswählen

un  vim            <keine>      <keine>      (keine Beschreibung vorhanden)
un  vim-athena     <keine>      <keine>      (keine Beschreibung vorhanden)
ii  vim-common     2:8.2.2434-3 all          Vi IMproved - Common files
un  vim-gtk3       <keine>      <keine>      (keine Beschreibung vorhanden)
un  vim-nox        <keine>      <keine>      (keine Beschreibung vorhanden)
ii  vim-tiny       2:8.2.2434-3 amd64        Vi IMproved - enhanced vi editor - compact version

[hikaru]

Ich kann das Verhalten unter Buster/Xfce mit xfce4-terminal auf Xorg nicht nachvollziehen:

A.1:

Code: Alles auswählen

$ ls bla
ls: Zugriff auf 'bla' nicht möglich: Datei oder Verzeichnis nicht gefunden

B.1:

Code: Alles auswählen

$ vim.tiny

A.2: gesamten Text aus A.1 mit Maus markieren

B.2: In Eingabemodus »i« wechseln
B.3: mittlere Maustaste drücken → Text aus A.1 wird eingefügt
B.4: ».« drücken → das Zeichen ».« wird eingefügt
B.5: »Enter« drücken → Zeilenumbruch
B.6: erneut ».« drücken → Zeichen wird in neuer Zeile eingefügt

A.3: Fokuswechel mit Maus

B.7: Fokuswechel mit Maus zurück
B.8: erneut ».« drücken → Zeichen wird eingefügt

Am Ende steht in B also Folgendes:

Code: Alles auswählen

$ ls bla
ls: Zugriff auf 'bla' nicht möglich: Datei oder Verzeichnis nicht gefunden.
..

Der Text stammt aus B.3, die drei Punkte am Ende aus B.4, B.6, B.8.
Den Inhalt des zuletzt geposteten Codeblocks habe ich mit der Maus in B markiert und hier im Browser mit der mittleren Maustaste eingefügt. B steht nach wie vor im Einfügemodus.

[Meillo]

Ob sie sich nun unterscheiden *sollte* oder nicht: Unterscheidet sie sich?

Kann ich nicht beantworten. Das Paket wird standardmäßig nicht installiert. Ist mir aber auch erst jetzt aufgefallen. Alles, was ich als "gelernter" UNIX-Mensch von einem Editor kenne und erwarte, bietet mir das Teil, was sich nach dem Aufruf von "vi" öffnet.

Code: Alles auswählen

un  vim            <keine>      <keine>      (keine Beschreibung vorhanden)
un  vim-athena     <keine>      <keine>      (keine Beschreibung vorhanden)
ii  vim-common     2:8.2.2434-3 all          Vi IMproved - Common files
un  vim-gtk3       <keine>      <keine>      (keine Beschreibung vorhanden)
un  vim-nox        <keine>      <keine>      (keine Beschreibung vorhanden)
ii  vim-tiny       2:8.2.2434-3 amd64        Vi IMproved - enhanced vi editor - compact version

Was ich damit sagen wollte: Installiere den vollen Vim doch einfach mal. Teste es damit, nur um sicher zu gehen. Dann kannst du ihn wieder deinstallieren.

Was ich halt gelernt habe: Beim Debuggen solch mysterioeser Phaenomene muss man nicht nur jede Annahme hinterfragen, sondern sie alle auch durch eine Reproduktion ausschliessen. Wenn man versucht zu denken, dann uebersieht man nur weiter das vermutlich relevante Details. Also stupide alles tatsaechlich tun, weil das Tun weniger unter dem Problem von blinden Flecken in der Wahrnehmung leidet.

Versuche dabei alle Dinge, die du machst, zu variieren. Also das Einfuegen, wie rodney beschrieben hat, mit Shift+Ins machen. Oder den gvim verwenden und dort ueber das Menu einfuegen. -- Das sind Debuggingmethoden, die dich der Loesung naeher bringen.

[HumiNi]

Vorab: Als ich den Thread eröffnet habe, bin ich davon ausgegangen, dass meine Frage leicht zu beantworten ist. Wenn ich gewusst hätte...
Umso mehr möchte ich mich bei allen bedanken, die mir Tipps gegeben haben (ganz besonders dir, Meillo) oder mitgedacht haben.

Zur Sache: Ich denke, ich habs.

Ich fasse zusammen:

Code: Alles auswählen

lrwxrwxrwx 1 root root      17 26. Nov 13:00 /etc/alternatives/vi -> /usr/bin/vim.tiny
lrwxrwxrwx 1 root root      20 26. Nov 13:00 /usr/bin/vi -> /etc/alternatives/vi
-rwxr-xr-x 1 root root 1404616  2. Mär 2021  /usr/bin/vim.tiny

Ich bin darauf gestoßen, dass es einen Unterschied macht, ob ich vim.tiny direkt oder über den Alternative-Link vi aufrufe (beim Aufruf über vim.tiny war alles wie gewünscht).

Als ich dann noch in vimrc und vimrc.tiny darauf gestoßen bin:

Code: Alles auswählen

" Vim configuration file, in effect when invoked as "vi". The aim of this
" configuration file is to provide a Vim environment as compatible with the
" original vi as possible. Note that ~/.vimrc configuration files as other
" configuration files in the runtimepath are still sourced.
" When Vim is invoked differently ("vim", "view", "evim", ...) this file is
" _not_ sourced; /etc/vim/vimrc and/or /etc/vim/gvimrc are.

Code: Alles auswählen

" Uncomment the next line to make Vim more Vi-compatible
" NOTE: debian.vim sets 'nocompatible'.  Setting 'compatible' changes numerous
" options, so any other options should be set AFTER setting 'compatible'.
"set compatible

... war ich mir schon sicher.

Jetzt steht in meiner vimrc.tiny

Code: Alles auswählen

set nocompatible

... und ich bin zufrieden.

Allerdings kann ich mir das ursprünglich von der Art des Aufrufs unterschiedliche Verhalten immer noch nicht erklären - egal.

[Meillo]

Heisst das jetzt, dass wenn du vim als `vi' aufrufst und damit automatisch der Kompatibilitaetsmodus gesetzt wird, dann existiert dein Problem. Wenn du vim aber als `vim' aufrufst, bzw. `:set nocompatible' verwendest, dann existiert das Problem nicht. -- Ist es so? Hast du damit eine Loesung bzw. einen Workaround gefunden?


(Ich kann das Verhalten bei meinem vim.basic dennoch nicht reproduzieren.)

[HumiNi]

Im Originalzustand hatte ich unterschiedliches Verhalten beim Aufruf:
- vi <datei> hat über /etc/alternatives vim.tiny aufgerufen -> mein ursprüngliches Problem
- vim.tiny <datei> -> alles wie erwartet/gewünscht.

Nach der Anpassung von /etc/vim/vimrc.tiny habe ich auch mit dem Aufruf vi <datei> das gewünschte Verhalten.
Irgendwie strange, aber isso.

Mir erscheint der modifizierte Zustand sauber, der default-Zustand leicht kaputt.
(Ich erinnere daran, dass dies (auch) auf einem neu installiertem bullseye auftrat.)