Correction de CTRL- * dans vim sous l'écran GNU


10

Lors de l'exécution de vim sous l'écran GNU, je constate que les combinaisons de CTRLtouches fléchées et Pg * ne fonctionnent pas comme prévu.

J'utilise le vim-gnomepackage Ubuntu 10.10 .

Sur une machine différente, exécutant également Ubuntu, cela a fonctionné sans problème; malheureusement, je n'ai pas cette configuration à ma disposition maintenant.

Il y a une question connexe ici: Comment réparer les flèches Ctrl + dans Vim?

Cependant, la solution suggérée consiste à remapper les raccourcis clavier de vim pour qu'ils fonctionnent avec l'émulateur de terminal, dans ce cas PuTTY. Je ne me souviens pas avoir fait quoi que ce soit de ce genre, et je soupçonne qu'il existe une option de configuration d'écran qui résoudra ce problème.

Il y a aussi un fil sur la liste de diffusion gnu-screen qui suggère que l'exécution de vim via $ TERM=xterm vimest une solution ou une solution de contournement appropriée. Cela fonctionne, mais je crains un peu qu'il puisse y avoir des effets secondaires. Cela ne semble pas assez familier pour être la solution que j'ai installée sur l'autre machine (si une solution était nécessaire).


+1 - J'avais le même problème et - comme vous l'avez suggéré - l'ajout term xtermà mon ~/.screenrcfichier l'a corrigé pour moi. Merci encore!
Justin Ethier

Réponses:


4

Comme indiqué intuitivement dans sa mise à jour, l'ajout term xtermau ~/.screenrcfichier semble résoudre ce problème.


Eh bien .. oui, mais je m'attends à une sorte d'explication pour expliquer pourquoi screenne se contente pas de propager la $TERMvariable d'environnement au lieu de la remplacer "screen". Vraisemblablement, il y a des circonstances où il est important d'avoir $TERM == screen.
intuition

3
@intuited: La raison pour laquelle Screen définit TERM=screenest que les applications qui s'exécutent à l'intérieur communiquent à l'intérieur d'un terminal Screen: les séquences de contrôle qu'elles envoient et reçoivent sont celles de Screen, et non celles du terminal Screen lui-même affiché. Comme vous pouvez détacher une session Screen et la rattacher à un autre type de terminal, cette couche d'indirection est nécessaire.
Gilles 'SO- arrête d'être méchant'

@ Gilles: Merci, je soupçonnais quelque chose comme ça. À quels types de problèmes pourrait résulter sa réinitialisation xterm?
intuition

1
Pas grand-chose, car xterm et screen sont pour la plupart compatibles. Mais chacun a quelques capacités que l'autre n'a pas, et si vous mentez aux applications, elles pourraient utiliser une capacité qui ne fonctionne pas réellement. Comparez la sortie de infocmp screenet infocmp xterm, et les séquences d'échappement d'écran avec les séquences d'échappement xterm . Je n'ai pas de ventilation à proposer; la plupart des applications n'y verront pas d'inconvénient, mais quelques-unes pourraient se comporter de manière ennuyeuse.
Gilles 'SO- arrête d'être méchant'

2

Il existe deux autres façons de définir le terminal qui fonctionne dans les processus en cours d'exécution:

  • Dans une instance d'écran en cours d'exécution, en appuyant sur ^A- :et en émettant la commande term xterm, les écrans nouvellement ouverts sous cette instance commenceront avec leur $TERMvariable d'environnement définie sur xterm; cela se propagera à son tour aux viminstances invoquées . Ces instances vim afficheront un comportement correct en ce qui concerne les combos CTRL; Je n'ai pas encore découvert d'effets secondaires de cette stratégie. Cette commande n'affecte pas les écrans existants. Cette commande peut bien sûr être utilisée dans un ~/.screenrcfichier, il est donc possible que cette méthode ait été utilisée sur l'autre machine.

  • Dans une instance vim en cours d'exécution, la commande set term=xtermfera fonctionner les combos CTRL dans cette instance vim. Cela a pour effet secondaire de déconnecter le presse-papiers X (ie @*et @+) pour des raisons que je ne comprends pas encore. Fait intéressant, l'effet secondaire du presse-papiers se produit également lorsque la commande :set term=screenest exécutée dans une instance de vim commencée par $TERM=xterm.


Cette réponse est tirée des mises à jour du PO. Tout ce que j'ai fait, c'est de reformater et de reformuler un peu.
phunehehe

2

Le problème sous-jacent est que le mappage effectué screenentre le terminal réel (identifié par la TERMvariable d'environnement à l'extérieur screen) et l'émulation à l'intérieur screenest incomplet.

Si vous le testez (en utilisant vttest ou tack ), vous pouvez remarquer des

  • couleurs
  • touches spéciales

Toute tentative de résoudre ces problèmes en mettant termen .screenrca l'inconvénient qu'il ne fonctionne que pour un terminal réel donné, et n'est pas portable à d' autres implémentations terminaux. Les notes de documentation

L'utilisation du terme commande est déconseillée à des fins autres que celles par défaut.

Il existe une autre solution (avec un inconvénient différent), utilisant cette fonctionnalité de la screen documentation :

Lorsque screen essaie de trouver un nom de terminal pour lui-même, il recherche d'abord une entrée nommée screen. terme , où terme est le contenu de votre $TERMvariable. Si aucune entrée de ce type n'existe, l'écran essaie screen(ou screen-w, si le terminal est large (132 cols ou plus)). Si même cette entrée est introuvable, vt100est utilisée comme substitut.

ncurses fournit plusieurs descriptions de terminaux alternatives utiles dans ce cas, par exemple screen.xterm-new , pour réparer les problèmes de mappage de l'écran. En pratique, j'utilise TERM=xterm-new, et lors de l'exécution de l'écran, j'obtiens un mappage utilisable des touches de fonction.

En vous référant au termréglage de l'écran , lors des tests, vous remarquerez peut-être qu'il y a toujours des problèmes avec le mappage, qui sont résolus dans ces alternatives. S'il était possible d'obtenir une description précise du terminal en utilisant term, ces alternatives seraient de simples alias screen. Ils ne sont pas.

ncurses ne fournit passcreen.xterm (sic) car:

  • TERM=xtermest largement utilisé à mauvais escient pour les émulateurs terminaux qui diffèrent de xterm; l'ajout de ce mappage ne ferait qu'aggraver cette situation (voir par exemple Pourquoi ne pas simplement utiliser TERM défini sur "xterm"? dans la FAQ ncurses)
  • le nom alternatif screen.xtermest moins susceptible d'être installé sur des systèmes distants (voir le commentaire de modification de juin 2015 dans la base de données du terminal).

Dans l'ensemble, cependant, l'utilisation des noms alternatifs est une amélioration par rapport à l'utilisation termdans votre .screenrc: elle résout plus de problèmes qu'elle n'en crée. L'inverse est vrai du termréglage.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.