Bonjour,

En voulant remapper ctrl+é en ctrl+w dans vim, j'ai remarqué que la combinaison de touche ctrl+z était envoyé en console (mettre la commande courante en pause). Je vous avoue que c'est assez génant.
Je suis sous archlinux avec gnome-shell. Le problème se pose avec au moins gnome -terminal et terminologie, et autant en bépo qu'en qwerty. Dans les deux cas, l'appuie de la touche ctrl + la touche ayant l'emplacement z en azerty envoie ctrl+z.

Une idée ?
Salut robin

On dirait un problème avec gtk : tu as testé dans xterm ? Les pilotes étant différents entre les tty et le serveur graphique, tu ne devrais pas rencontrer ce soucis dans un tty, je me trompe ?
Tu peux toujours supprimer le raccourci Ctr-z pour vim avec quelque chose comme
unmap <C-z>
dans ton .vimrc (essaie d’abord :unmap <C-z> en mode commande)

Mais je n’ai pas très bien compris le message (j’avais d’abord cru que tu étais en tty et je n’ai pas compris si le Ctr-z intervenait quand tu tapais Ctr-w)
@XavierC : Je n'ai pas redémarré mon Linux aujourd'hui, donc pas moyen de tester. Je vérifie demain.
@Damien : C'est l'inverse, je veux mapper ctrl+é, mais je ne peut pas le faire car ctrl+é met l'application en pause (comme si j'avais tapé sur ctrl+z).
Je ne pensais pas à un redémarrage : installe le paquet xterm (ou un autre terminal en GUI indépendant de GTK) et lance-le de suite pour tenter de reproduire le bug.
@XavierC : je me suis mal exprimé, j'était sur mon windows pour jouer et je n'avais pas redémarré mon linux.

Après tests, le bug se produit sur xterm, terminologie, gnome-terminal, rxvt, kde-konsole, testé en utilisant les commandes vim et man (pour m'assurer que ce n'est pas un bug étrange de vim) mais ne se produit pas en tty.
Forcément si tu ne donnes pas toutes les infos… 🙂
D'ailleurs c'est quelle distribution ton Linux ?
Est-ce que la procédure donnée ici donne qqchose ?
Malheureusement, ça ne change rien.
Comme je l'avais mis dans le premier post (je ne l'avais pas oublié ça ! ), je suis sous archlinux. Est ce que quelqu'un d'autre à ce problème ?
Chez moi (Arch actualisé hier), Ctr-é agit normalement, il ne se passe rien, donc le bépo n’est pas interprêté comme un azerty.
Puisque tu es sur Arch, tu dois avoir nano d’installé. Est-ce que Ctr-é y est interprếté comme un Ctr-Z? Si oui, le problème vient de X11 et d’un bépo qui ne passe pas, sinon il vient de vim. Dans ce cas, je soupçonne un plugin de mettre le bazar. Est-ce que tu as des plugins d’installés? Si tu les desactives, est-ce que l’erreur se repête?

Tu as quand même essayé le unmap <C-z>? Cela pourrait quand même lever quelques obstacles…
Je viens de refaire le test, maintenant je n'ai plus de problème en qwerty avec ctrl+w (le w du qwerty est le z de l'azerty).
Si je fais «man truc ctrl+é», le programme man est mis en pause.
Si je fais «vim truc ctrl+é», vim est mis en pause
Si je fais «more truc ctrl+é», more est mis en pause
Si je fais «less truc ctrl+é», less est mis en pause.

Mais :
Si je fais «nano truc ctrl+é», nano ne bronche pas.
???

Là je ne vois pas trop. Si au moins nano flanchait…
J’ai un temps pensé au shell avec un problème d’inputrc. Mais dans ce cas-là, cela devrait planter en tty aussi, non?
Est-ce que ces trucs bizarres se reproduisent sur un compte standard (tu créés un compte sans fichier de config, et une fois dans X après un setxkbmap fr bepo tu reproduis ces commandes)?
J'ai créé un compte vierge, (login uniquement avec un su, sans fermer ma session courante, je n'ai pas approfondit) même problème.

J'ai également testé sous différents environnements :
gnome-shell -> problème
cinnamon -> problème

xmonad -> ok (le ctrl+é ne fait rien, comme il se doit)
awesome -> ok (idem)

On dirais donc bien un bug de gtk. J'ai pourtant fait comme le disais XavierC « sudo echo "export GTK_IM_MODULE=xim" >> /etc/profile » et j'ai vérifié, le contenu le la variable GTK_IM_MODULE.
Bonjour,
robin_moussu a écritEn voulant remapper ctrl+é en ctrl+w dans vim, j'ai remarqué que la combinaison de touche ctrl+z était envoyé en console (mettre la commande courante en pause). Je vous avoue que c'est assez génant.
J’ai le même phénomène, sur une Arch comme sur une Fedora… mais je ne m’en étais jamais aperçu.
damien thiriet a écritSi oui, le problème vient de X11 et d’un bépo qui ne passe pas, sinon il vient de vim. Dans ce cas, je soupçonne un plugin de mettre le bazar.
Ctrl+z est une commande du shell, qui suspend le programme de premier plan quand il la reçoit. Les programmes qu’on lance depuis le shell ne la gèrent pas eux-mêmes, ils se contentent de subir. Au mieux, peut-être certains réussissent-ils à intercepter toutes les frappes clavier, mais encore faut-il une raison pour qu’ils le fassent.
robin_moussu a écritUne idée ?
Je n’ai pas assez d’informations pour savoir pourquoi ça te le fait, mais je sais très bien pourquoi ça me le fait : j’ai paramétré deux dispositions, dont Azerty, avec la touche Arrêt défilement pour basculer entre les deux, mais ainsi elles ne sont pas complètement indépendantes. L’Azerty bénéficie de l’AltGr symétrique du Béop et manifestement, à une position où il n’y a pas une lettre ASCII en Béop, le caractère de contrôle de l’Azerty s’impose (j’ai vérifié avec xev).

Si je supprime l’Azerty, Ctrl+é ne rend plus Ctrl+z (caractère de code 26 en décimal), mais juste un « é » (en UTF-8 sur deux octets, pas étonnant que la logique de Ctrl ne sache pas quoi en faire). Donc pour pouvoir utiliser Ctrl+é comme raccourci avec une application, il faut de toute façon qu’elle considère les codes de touches et pas la chaîne rendue pour ses raccourcis.
Attention, pour le login avec le su, il faut un su --login si tu veux annuler tes options d’environnement: cf man su
For backward compatibility su defaults to not change the current directory and to only set the environment variables HOME and SHELL (plus USER and LOGNAME if the
target user is not root). It is recommended to always use the --login option (instead of its shortcut -) to avoid side effects caused by mixing environments.
Donc pour tester avec un utilisateur vierge, su n’est apparemment pas optimal. Je pense que le message de Laurent confirme qu’il y a quelque chose à voir avec les options de config. Je ne vois pas trop ce que gtk aurait à voir là-dedans pour des programmes comme less ou more…
Et comme tu as des problèmes sous X, je pense que cela vaut le coup de tester avec un utilisateur standard
Quel sont tes dispositions de claviers configurées dans le fichier de conf de X.org? Dans GNOME Shell?
@sinma : Autant il y 6 mois quand j’étais encore sous ubuntu et que j'avais tout changé moi-même, j'aurais pu te répondre exactement 'quels fichiers sont utilisés, mais là j'utilise juste le sélecteur de clavier de gnome-shell.
@damien : j'ai refait le test, mais cette fois-ci avec un vrai utilisateur, et je n'ai pas rencontré ce bug. Ce qui était surprenant, c'était dans le selecteur de clavier de mon compte de tests, il n'y avais pas de clavier sélectionné, comme si le bépo était ma source par défaut, alors que sous le login robin, j'ai bien bépo + qwerty + azerty

J'ai également fait le test de retirer l'azerty de mes disposions, mais le bug persiste.

Encore un test : création d'un nouveau compte. La langue par défaut est la même que celle de mon compte (le bépo), et aucune langue ne se trouve dans le sélecteur de disposition (comme vu au dessus). Pas de présence du bug.
Ajout de la dispo FR-VARIANTE. Le clavier est désormais uniquement en azerty.
Ajout de la dispo bépo. Je peut passer d'une dispo à l'autre. Le bug refait surface.
Suppression de la dispo azerty, le bug reste.

J'ai voulu aller encore plus loin dans les idées bizarre :
création d'un nouveau compte. La langue par défaut est la même que celle de mon compte (le bépo), et aucune langue ne se trouve dans le sélecteur de disposition (comme vu au dessus). Pas de présence du bug.
Ajout de la dispo QWERTY. Le clavier est désormais uniquement en qwerty.
Ajout de la dispo bépo. Je peut passer d'une dispo à l'autre. Le bug refait surface (oui oui, le bug du ctrl+é) => c'est plutôt étrange

Et donc dernier test :
création d'un nouveau compte. La langue par défaut est la même que celle de mon compte (le bépo), et aucune langue ne se trouve dans le sélecteur de disposition (comme vu au dessus). Pas de présence du bug.
Ajout de la dispo BÉPO. Théoriquement, rien n'a donc changé. Et pourtant le bug refait surface (oui oui, le bug du ctrl+é) => c'est plutôt étrange

J'en conclue donc que c'est la config de gnome shell qui est en tord, et qui doit être partagé avec cinnamon.
Conclusion : si quelqu'un sait ou trouver une doc pour sélectionner entièrement à la main toutes les options de xorg, je suis preneur (et je sais que c'est compliqué à trouver, d'où ma demande).

PS, j'espère qu'avec le passage sous Wayland, des bugs de ce type ne se reproduiront plus. Est ce que quelqu'un à des infos la dessus ?
Pour le fichier de conf de gnome shell, je ne peux pas t’aider

[troll] C’est pour éviter ce genre de problème que je n’ai pas d’environnement de bureau. Plus on met de couche, plus il y a risque de bug… [/troll]
robin_moussu a écritPS, j'espère qu'avec le passage sous Wayland, des bugs de ce type ne se reproduiront plus. Est ce que quelqu'un à des infos la dessus ?
Les infos que j’ai laissent penser qu’avec Wayland, on perdra le copier-coller à la souris (clarification pour les utilisateurs de Windows : on sélectionne du texte avec le bouton gauche, on le colle avec le bouton du milieu), et sauf sous KDE, les applications géreront elles-mêmes leurs fenêtres, donc on peut s’attendre à ce qu’une application qui part en sucette ait sa fenêtre bloquée au milieu de l’écran. Tout pareil que sous Windows ! Un progrès formidable !

Par contre, il est question qu’ils conservent Xkb (le système actuel) pour la gestion du clavier. C’était justement la raison du travail qui a été fait pour le séparer du reste d’X.org.

Tant mieux, j’aime mieux conserver des bugs mineurs que perdre des fonctionnalités (une mode initiée par les développeurs de Gnome)…
@damien : pas de problème pour le troll, j'aime moi aussi en lancer des velus. Mais plus sérieusement, le problème est que l'absence d'environnement de bureau rend très difficile la navigation à la fois en tilling au clavier (ça c'est facile à trouver), et à la souris (ça c'est beaucoup plus dur), de manière à avoir un mode boulot (au clavier) et un moment moule (avec la souris et une pomme dans l'autre main).

@Laurent : Ça me semble être globalement une mauvaise nouvelle. Pour le clic milieu, il me semble qu'il va finalement être implémenté, et j'espère que ce sera le cas, car à mes yeux c'est une fonctionnalité majeure (au même titre que le clic droit). Et pour xkb, je ne sais pas comment tu peux considéré le truc stable. Dès que tu sort de l'azerty/qwerty les bugs arrivent par milliers.
robin_moussu a écrit@damien : pas de problème pour le troll, j'aime moi aussi en lancer des velus. Mais plus sérieusement, le problème est que l'absence d'environnement de bureau rend très difficile la navigation à la fois en tilling au clavier (ça c'est facile à trouver), et à la souris (ça c'est beaucoup plus dur), de manière à avoir un mode boulot (au clavier) et un moment moule (avec la souris et une pomme dans l'autre main).
Je pense que damien parlait non pas de DE versus tty mais de DE versus WM : Est-ce l'outil de paramétrage de disposition de clavier inclu dans Gnome Shell qui merde ou carrément xkb ? Est-ce que ça merde avec un script à base de setxkbmap ? il existe des WM combinant TM et navigation à la souris (AwesomeWM par exemple)
@Laurent : Ça me semble être globalement une mauvaise nouvelle. Pour le clic milieu, il me semble qu'il va finalement être implémenté, et j'espère que ce sera le cas, car à mes yeux c'est une fonctionnalité majeure (au même titre que le clic droit). Et pour xkb, je ne sais pas comment tu peux considéré le truc stable. Dès que tu sort de l'azerty/qwerty les bugs arrivent par milliers.
Pour le clic du mileu ma foi mon orbit trackball n'a que deux boutons mais je comprends la gène de ceux qui l'utilise (moi même je pourrai l'émuler sur mon clavier). On a aussi de gros problèmes avec la SDL et les caractères non ascii, cf la page bépo-friendly du wiki.