Emacs, unicode, des séquences d'échappement de la souris xterm, et terminaux large

Question

Version courte: Lorsque vous utilisez xterm-souris en mode emacs, Quelqu'un intercepte les séquences de contrôle de xterm et les remplace par \ 0 (emacs bash xterm??). Ceci est une douleur sur l'échelle moniteurs car seuls les premiers 223 colonnes ont la souris.

Quel est le coupable, et comment puis-je travailler autour d'elle?

D'après ce que je peux dire cela a quelque chose à voir avec Unicode / UTF-8 support, car il n'a pas été un problème il y a 5-6 ans quand j'ai eu enfin un grand écran.

Les détails sordides suivent ...

Merci!

xterm-souris de mode Emacs a un traitement de faiblesse bien connus des clics de souris à partir d'environ x = 95. Une solution , adoptée par les versions récentes de emacs, pousse hors du problème pour x = 223.

Il y a plusieurs années, je compris que encode xterm positions en octets 7 bits. Compte tenu de la position 'x' à encoder, avec X = x-96, envoyer:

\40+x (x < 96)  
\300+X/64 \200+X%64 (otherwise)  

Nous devons ajouter une position donnée x de emacs, parce que les positions en xterm commencent à un, zéro. D'où la magie x = nombre 95 apparaît parce qu'il est codé comme « \ 300 \ 200 » - le premier numéro échappé. Quelqu'un (emacs? Bash? Xterm?) Traite ces comme séquences de contrôle "C0" de ISO 2022 . À partir de x = 159, on change de séquences "C1" (\ 301 \ 200), qui font également partie de l'ISO 2022.

\ résultats incidents avec 302 séquences, ce qui correspond au courant x = 223 limite. Il y a quelques années, j'ai pu étendre le hack pour intercepter \ 302 et \ 303 séquences manuellement, qui a passé le problème. Avance rapide de quelques années, et aujourd'hui je trouve que je suis de retour bloqué à x = 223 parce que quelqu'un remplace ces séquences avec \ 0.

Alors, où je vous attendriez en cliquant sur la ligne 1, col 250 produits

ESC [ M SPC \303\207 ! ESC [ M # \303\207 !

Au lieu emacs rapports (pour toute colonne> 223)

ESC [ M SPC C-@ ! ESC [ M # C-@ !

Je soupçonne que le support Unicode / UTF-8 est le coupable. Certains creusement montre que la norme Unicode autorisé séquences C0 et C1 dans le cadre de UTF-8 jusqu'à novembre 2000 et je suppose que quelqu'un n'a pas obtenu la note (heureusement). Cependant, \ 302 \ 200 - \ 302 \ 237 sont Unicode séquences de contrôle , si quelqu'un les slurps vers le haut (faire qui sait quoi avec eux!) et retourne \ 0 à la place.

Quelques questions plus détaillées:
- Qui est-ce quelqu'un qui intercepte les codes avant d'atteindre emacs' tampon lossage
- Si elle est vraiment juste au sujet des séquences de contrôle, comment se caractères après \ 302 \ 237, qui sont UTF-8 encodages d'Unicode imprimable, revenir comme \ 0 aussi
? - Qu'est-ce qui emacs choisir d'afficher lossage sous forme de caractères unicode ou octal séquences d'échappement, et pourquoi ne pas les deux match? Par exemple, mon auto-construit Cygwin emacs 23.2.1 (xterm 229) rapports \ 301 \ 202 pour la colonne 161, mais mes emacs rhel5.5 fourni 22.3.1 (xterm 215) rapporte "Â" (latin A circonflexe) , qui est en fait \ 303 \ 202 en UTF-8!

Mise à jour:

Voici un patch contre xterm-261 ce qui en fait émettre des positions de la souris au format utf-8:

diff -r button.c button.utf-8-fix.c
--- a/button.c  Sat Aug 14 08:23:00 2010 +0200
+++ b/button.c  Thu Aug 26 16:16:48 2010 +0200
@@ -3994,1 +3994,27 @@
-#define MOUSE_LIMIT (255 - 32)
+#define MOUSE_LIMIT (2047 - 32)
+#define MOUSE_UTF_8_START (127 - 32)
+
+static unsigned
+EmitMousePosition(Char line[], unsigned count, int value)
+{
+    /* Add pointer position to key sequence
+     * 
+     * Encode large positions as two-byte UTF-8 
+     *
+     * NOTE: historically, it was possible to emit 256, which became
+     * zero by truncation to 8 bits. While this was arguably a bug,
+     * it's also somewhat useful as a past-end marker so we keep it.
+     */
+    if(value == MOUSE_LIMIT) {
+       line[count++] = CharOf(0);
+    }
+    else if(value < MOUSE_UTF_8_START) {
+       line[count++] = CharOf(' ' + value + 1);
+    }
+    else {
+       value += ' ' + 1;
+       line[count++] = CharOf(0xC0 + (value >> 6));
+       line[count++] = CharOf(0x80 + (value & 0x3F));
+    }
+    return count;
+}
@@ -4001,1 +4027,1 @@
-    Char line[6];
+    Char line[9]; /* \e [ > M Pb Pxh Pxl Pyh Pyl */
@@ -4021,2 +4047,0 @@
-    else if (row > MOUSE_LIMIT)
-       row = MOUSE_LIMIT;
@@ -4028,1 +4052,5 @@
-    else if (col > MOUSE_LIMIT)
+
+    /* Limit to representable mouse dimensions */
+    if (row > MOUSE_LIMIT)
+       row = MOUSE_LIMIT;
+    if (col > MOUSE_LIMIT)
@@ -4090,2 +4118,2 @@
-       line[count++] = CharOf(' ' + col + 1);
-       line[count++] = CharOf(' ' + row + 1);
+       count = EmitMousePosition(line, count, col);
+       count = EmitMousePosition(line, count, row);

Espérons que cela (ou quelque chose comme ça) apparaîtra dans une version future de xterm ... le patch rend le travail xterm hors de la boîte avec emacs-23 (qui suppose l'entrée utf-8) et corrige les problèmes existants avec xt -mouse.el aussi. Pour l'utiliser avec emacs-22 nécessite une redéfinition de la fonction qu'il utilise pour décoder les positions de la souris (la nouvelle définition fonctionne très bien avec emacs-23 aussi):

(defadvice xterm-mouse-event-read (around utf-8 compile activate)
  (setq ad-return-value
        (let ((c (read-char)))
          (cond
           ;; mouse clicks outside the encodable range produce 0
           ((= c 0) #x800)
           ;; must convert UTF-8 to unicode ourselves
           ((and (>= c #xC2) (< emacs-major-version 23))
            (logior (lsh (logand c #x1F) 6) (logand (read-char) #x3F)))
           ;; normal case
           (c) ) )))

Répartir la defun dans le cadre des .emacs sur toutes les machines vous vous connectez, et patcher le xterm sur toutes les machines que vous travaillez à partir. Le tour est joué!

ATTENTION: Applications qui modes de souris d'utilisation xterm mais ne traitent pas leur entrée en utf-8 sera perturbé par ce patch car le esca de la sourisséquences de pe rallongent. Cependant, ces applications rompent horriblement avec le xterm courant parce que les positions de la souris avec x> 95 ressembler UTF-8 codes mais ne sont pas. Je crée un nouveau mode de souris pour xterm, mais certaines applications (écran de gnu!) Filtrent les séquences d'échappement inconnues. Emacs est la seule application utilisation I terminal de la souris, donc je considère que le patch une victoire nette, mais YMMV.

Answer 1

OK, compris. Il y a en fait deux questions.

Tout d'abord, certains spectacles de plongée source que les clips xterm la région a permis la souris de la fenêtre pour 223x223 ombles, et envoie 0x0 pour toutes les autres positions.

En second lieu, emacs-23 est UTF-8 et conscient est perturbé par les événements de souris ayant x> 160 et y> 94; dans ces cas, l'encodage xterm pour x et y ressemble à un caractère UTF-8 de deux octets (par exemple 0xC2 0x80) et par conséquent la séquence de souris semble une courte de caractères.

Je travaille sur un patch pour xterm pour faire des événements de souris émettent UTF-8 (qui les unconfuse emacs-23 et permettre à des terminaux jusqu'à 2047x2047), mais je ne suis pas encore sûr comment il va tourner.

Answer 2

xterm-262 ajoute le patch inline ci-dessus, cependant, ce patch est tout à fait brisée par la conception. Les développeurs de Rxvt-unicode réalisé et ajouté une autre, l'extension beaucoup mieux de lui faire rapport coordonnées de la souris.

En ce moment je travaille sur l'obtention d'un large soutien pour cela. Rxvt-unicode et iTerm2 soutiennent déjà les deux extensions. J'ai créé des correctifs pour xterm (pour soutenir l'extension urxvt), et pour gnome-terminal, konsole et putty pour soutenir les deux nouvelle extension. En ce qui concerne les applications, j'ai ajouté le support pour l'extension urxvt à Midnight Commander.

S'il vous plaît me joindre à mes efforts et essayer de convaincre les développeurs plus terminaux et les applications à mettre en œuvre ces extensions (au moins celui de urxvt, parce que l'autre ne peut pas être correctement reconnu automatiquement par des applications).

Voir http://www.midnight-commander.org/ticket/2662 pour plus d'informations techniques et d'autres pointeurs.

Answer 3

Je pense que le problème qui a causé votre solution de contournement (et le correctif en amont qui a été inclus dans l'une des versions V22) d'arrêter de travailler à 23,2 est Emacs lui-même. 23,1 peut gérer les clics de souris après la colonne 95 à l'aide urxvt, écran gnu, mastic ou iTerm, mais 23,2 ne peuvent pas. Réglage de tout ensemble de latin-1 ne fait aucune différence. 23,1 a le même code dans xt-mouse.el. cependant src / lread.c et src / character.h changé, et un coup d'oeil je suppose que le bug est là quelque part. Quant à ce qui se passe après la colonne 223, je n'ai pas la moindre idée.

Pour le bénéfice de quelqu'un d'autre qui est agacé par la régression de la souris xt à 23,2 ici est une version modifiée de lecture xterm-souris-événement qui fonctionne avec clics de souris jusqu'à col 222 (crédit à Ryan pour la> 222 manipulation de trop-plein que ma solution d'origine manquait). Ce ne fonctionnera probablement pas 23,1 ou avant.

(defun xterm-mouse-event-read ()
  (let ((c (read-char)))
    (cond ((= c 0) #x100)  
       ; for positions past col 222 emacs just delivers
       ; 0x0, best we can do is stay at eol 
      ((= 0 (logand c (- #x100))) c) 
      ((logand c #xff))))) 

... Edit: Voici la version de Emacs 24 (tête bzr). Il fonctionne à nouveau à 23,2 jusqu'à col 222, mais n'a pas la> 222 eol manipulation Ryan de débordement suggéré:

(defun xterm-mouse-event-read ()
  (let ((c (read-char)))
    (if (> c #x3FFF80)
        (+ 128 (- c #x3FFF80))
      c)))

Answer 4

Alors que xterm fonctionne maintenant en mode utf-8 avec un patch, ce hack utf-8 se brisera de la pire façon possible dans tout autre lieu, comme les caractères unicode seront simplement abandonnée, à moins représentable.

urxvt a (dans les versions après 9,09) un mode 1015 qui envoie des réponses de la forme "ESC [code; x; y M", en utilisant des nombres décimaux. Ceci a l'avantage de ne pas avoir besoin d'un sondage à partir d'applications et de travailler aussi dans la non-linguistiques UTF-8.