gipoisson a écrit 97 commentaires

Les touches ont la même forme. Le clavier a été surtout acheté pour des caractéristiques autres que la forme des touches ; grosso modo : AZERTY, sans fil, rétro-éclairage configurable par un bouton ON/OFF.

Quant à tes cogitations sur un éventuel bricolage avant achat, elles seraient correctes ! Voici l'origine du clavier : pendant un voyage dans l'est asiatique, une connaissance a flashé sur un modèle de claviers et a voulu m'en apporter un comme cadeau-surprise. Comme il n'y avait que des QWERTY au premier passage, une commande d'AZERTY a été effectuée. Au final, deux claviers « AZERTY » ont été achetés, le sien et le mien, même si les termes de la commande n'avaient pas été respectés à la lettre.

En effet, la personne en question n'étant pas très au fait des « geekeries », le constat fait à l'achat était que c'était des AZERTY au niveau des touches donnant des lettres et des QWERTY pour les touches des symboles. Cela était un facteur additif à l'effet de surprise, donc une raison de plus d'absolument faire l'achat !

Cependant, tout est en ordre maintenant : son clavier est utilisé en mode WYS(aisis)WYG avec une installation Fedora que je lui ai faite ; les histoires de terminaux virtuels et autres SSH sont pour mon clavier et non pas l'autre.

Solution

J'ai réussi à torcher une bonne configuration grâce à tes indications, tous mes remerciements ! Une description détaillée se trouve infra pour la postérité.

xev

J'ai commencé avec ta suggestion de xev et les caractères d’intérêt donnaient ceci :

$ xev
# a (Un # indique ce qui est marqué sur la touche dans le post initial.)
… keycode 24 (keysym 0x61, a) …
# z
… keycode 25 (keysym 0x7a, z) …
# q
… keycode 38 (keysym 0x71, q) …
# w
… keycode 52 (keysym 0x77, w) …
# m
… keycode 47 (keysym 0x6d, m) …
# ;
… keycode 58 (keysym 0x2c, comma) …

À partir de là, un fichier Xmodmap s'imposait, du genre

$ cat ~/.Xmodmap
keycode  24 = a A a A
keycode  38 = q Q q Q
keycode  47 = m M m M
keycode  52 = w W w W
keycode  58 = semicolon colon semicolon colon
keycode  25 = z Z z W

Alors, on change la disposition en QWERTY, re-démarre la session et laisse X faire sa magie ? Que nenni ! La machine fait tourner Wayland et tout ce détour par xev+xmodmap (voire xkbcomp pour tenter une migration automatique de xmodmap à la bonne façon de faire) était pour la gallérie car le ~/.Xmodmap sera ignoré par un système sous Wayland. À noter que la majorité des liens bien indexés sur le Web orientent vers cette façon de faire un peu caduque. L'exercice était quand même instructif.

xkb

Il était temps donc d’arrêter la procrastination afin de se coltiner XKB et il s'est avéré que c'est un mécanisme élégant et facile à mettre en place. Ce format :

less /usr/share/X11/xkb/symbols/us
    key <TLDE> {        [     grave,    asciitilde      ]       };
    key <AE01> {        [         1,    exclam          ]       };
    key <AD01> {        [         q,    Q               ]       };

pourrait paraître abscons de loin mais il est des plus simples. Dans <…>, si on ignore la première lettre, les rangées des touches sont numérotées en A,B,C, … en commençant par le bas (là où se trouve la touche SPACE). Donc <AE01> et <AD01> indiquent à chaque fois la première touche (01), respectivement pour les rangées E et D. Simple et élégant ! Plus besoin d'intercepter des événements à la xev à la recherche des identifiants des touches ! Ce qui est entre {}; correspond à ce que renverra une touche donnée après saisie. Alors, j'ai fait mu-muse avec ce nouveau jouet :

# root
cp /usr/share/X11/xkb/symbols/us /usr/share/X11/xkb/symbols/us.backup
vi /usr/share/X11/xkb/symbols/us # pour avoir
  key <AD01> { [ a, A, agrave, acircumflex  ] };
  key <AD02> { [ z, Z                       ] };
  key <AB02> { [ x, X, 0x10000AB, 0x10000BB ] }; // «,»
  ⋮

Après avoir ajouté de l'Unicode partout où il y avait de la place sur les touches (oui oui, j'ai joué à fond !), il restait à activer tout le bousin via systemd. Et pour cela, c'est ta suggestion de us-qwerty/us-intl qui orientait dans le bon chemin :

# root
localectl set-x11-keymap us altgr-intl && systemctl reboot

Au redémarrage, tout est nickel … du moins tant que la session ouverte est « graphique » . Ainsi, une session dans un terminal virtuel (CTRL+ALT+F(3|4|…)) replongera le clavier dans ses travers. J'imagine qu'il y a une solution pour ça aussi, peut-être un truc à appeler dans le ~/.bashrc, mais l'état actuel des choses me satisfait, donc re-bonjour la procrastination ! Quid de SSH et d'autres types de sessions ? Aucune idée pour le moment, tout baigne, on vous dit qu'on procrastine, qu'on n'aimerait pas trop abuser du clavier de peur qu'il ne se blo

Ha, les triades, même pas peur ! C'est le retour aux origines, ça ! Tous les rudiments de kanji que j'ai sont le fruit d'un apprentissage décidé après avoir lu un livre dans lequel les personnages tournent autour de samouraïs. C'était un de ces chefs-d'œuvres artistiques à séquelles : il y a de l'art qui engendre de sortes de cultes pour les aficionados ; le culte pour ce livre-là était, dans mon cas, l'apprentissage du kanji ! Auteure : Helen DeWitt ; titre : The Last Samurai ; recommendation : regarder le film Seven Samurai d'Akira Kurosawa avant de se plonger dans la lecture du bouquin.

Au moment de l'apprentissage, on nous inculquait, si je ne m'abuse, que « kanji » était aussi valable en Corée et certaines parties de la Chine mais je suis vraiment un noob sur le sujet, dont acte de tes clarifications, tu me paraît être à l'aise avec ces langues. Et merci !

Le clavier est tout neuf.

C'est une marque chinoise, écrite en kanji, avec une étiquette sous le clavier qui indique un site web dont l'URL est complètement bidonne : même si ma compréhension des différents kanji est très rudimentaire, je n'ai aucun doute que la page à laquelle renvoie l'URL n'a rien à voir avec les claviers (je n'ai même pas pris la peine d'essayer de la traduction automatique).

À part ça, je n'étais pas au courant de la distinction xkbmodel vs. xbklayout, merci du tuyau, je le tenterai et rapporterai les résultats dès que j'aurai le clavier sous la main.

Merci beaucoup, à première vue, ton explication me parait être la plus prometteuse, je n'ai pas le clavier pour le moment afin de confirmer, je te reviendrai plus tard.

P.S. C'est moi qui ai complètement merdé avec ³ au lieu de ~, à force de faire du ASCII art, les touches se sont emmêlées. Toutes mes plates !

Non, ce n'est pas du français belge car dans ce cas, on devrait avoir ceci.

Bien vu pour le ³, c'était une erreur de frappe de ma part, merci. Je l’appellerai aussi QWERTY + échange de touches, il y a une proposition plus bas dans les commentaires qui me semble prometteuse.

Ce qui saute au yeux… c'est cette histoire de date. D'où on est en 1980 ?

Apparemment, en établissant la liste des fichiers, 7-zip modifie les dates pour les ré-initialiser à l'heure Unix. Sous Windows, ce moment ne correspond pas à ce qu'on rencontre sur les systèmes *nix, du moins d'après ce blog. D'où les dates « 1980 » que tu as rencontrées.

L'option dynamic-word-wrap de Kate ne correspond absolument pas aux tabulations élastiques.

Tout à fait. J'admets que son utilisation dans mon message initial était incongrue, dont acte. La bonne doc de l'option se trouve ici. Je l'ai mentionnée parce qu'à ce moment, je venais de lire cette page (voir les commentaires) ; depuis, les choses ont changé du côté de Kate.

À noter qu'à part cette variable de document, dans les APIs de KDE demeurent les notions de dynamic vs static word wraps. Voir par exemple là-bas.

il faut plusieurs tabulations sur la ligne 10 pour arriver au niveau des lignes 11 et 12.

Euh, je ne clame pas que Kate met parfaitement en œuvre les idées de Nick. Sur son blog, que j'ai découvert hier grâce au journal de gasche, il a tenu une historique étalée sur plusieurs années pour relater les progrès qu'il observait dans l'implémentation de son idée originale. À un moment donné, il y a eu une tentative qu'il a qualifiée de “elastic tabstop lite” ; les deux images que j'ai postées visaient à montrer que Kate rentre dans cette catégorie d'implémentation édulcorée.

La discussion est partie dans tous les sens. Tentative de récapitulation : au départ (dans le journal), il est question de tabstop (taquet de tabulation) et de comment le gérer sémantiquement pour éviter des débats sans fins (comme le présent) sur les espaces dans du code.

La solution proposée était que la touche TAB, lorsqu'il s'agit d'aligner, ferait abstraction des longueurs d'espaces attendues, que l'éditeur procéderait à une réorganisation visuelle tout en insérant qu'un seul blanc.

Les deux images que j'ai postées se contentaient de montrer que Kate pouvait procéder à une part de cette abstraction mais de façon imparfaite : les longueurs des espaces insérés étaient certes dynamiques mais plusieurs espaces étaient quand même insérés.

Alors, je ne vois pas à quoi « tabulation normale » répond dans ton message. S'il fait référence aux logiciels de traitement de texte, évidemment que ceux-ci peuvent insérer des espaces de longueurs variables pour des besoins d'alignement. Seulement, aux dernières nouvelles, Kate ne fait pas de traitement de texte.

je ne suis pas sûr que dynamic word wrap soit liée aux tabulations. Plutôt, ça permet de couper automatiquement les lignes trop longues pour éviter d'avoir à défiler horizontalement pour voir les fins de lignes.

Cela existe presque dans tous les éditeurs de texte (du moins ceux qui proposent d'éditer du code). La nomenclature de Kate pour ça est “Static Word Wrap”.

C'est ce que fait Kate mais une ligne à la fois, ce qui nécessite de faire des modifications dans les lignes adjacentes lorsque la ligne de référence a changé (voir le GIF dans le fil en-bas). L'idée de Nick est de rendre l'ajustement automatique dans toutes les lignes concernées. Il appelle l'approche telle que celle de Kate “elastic tabstops lite”.

Une image animée pour compléter :

Peut-être que c'est moi qui ai raté un truc dans l'idée d'élasticité. Voici deux extraits de l'article de Nick Gavgaard.

For as long as we continue to define each tabstop as being a multiple of N characters we will never be able to solve this problem satisfactorily.
…
Rather than saying that a tab character places the text that follows it at the next Nth column, we should say that a tab character is a delimiter between table cells in a manner more reminiscent of how they're used in tab separated value (TSV) files.

D'après ma comprenette, l'idée est que la touche TAB n'est plus équivalente à un multiple donné d'espaces à placer absolument dès qu'on l'invoque. Elle s'adapte suivant le contexte environnant. Sous cette lumière, revisitons la ligne 10 :

• l'espace engendré par le premier TAB après « ; » est clairement plus petit que celui se trouvant avant « x(); », ce dernier respectant la spécification « indent-width=8 » dans l'en-tête du fichier ;
• l'espace résultant des trois TAB suivant est conforme à la longueur fixe spécifiée ;
• le dernier espace, juste avant « */ » est minuscule.

Tous ces ajustements étant faits pour s'adapter aux autres commentaires dans les lignes 11 et 12. D'après ma compréhension du concept donc, ceci est un parfait exemple d'un TAB qui se comporte comme si c'était « un marqueur de cellules à la manière d'un tableur », pour paraphraser Nick Gavgaard.

Maintenant, comme tu le fais fort bien remarquer, dans ma session neovim par exemple, j'aurai le même comportement, à une différence près : ce n'est pas le comportement par défaut et ça dépend de comment les TAB sont configurés. Dans Kate, le truc y est compilé par défaut mais reste configurable ; l'en-tête « dynamic-word-wrap » que j'ai placée dans l'exemple était redondante avec la valeur par défaut. De ce poit de vue, les développeurs de Kate ont changé la « sémantique »¹ de TAB selon la manière dont Nick le voudrait.

J'ai oublié comment embarquer (embed) une image dans un commentaire, c'était une histoire de cache, toute ma reconnaissance à une âme charitable qui pourrait m'éclairer. Peut-être que la fonctionnalité n'existe plus … Enfin, bref, l'illustration dans le message parent se trouve chez https://imgur.com/a/hO9b8Ce

Merci de mettre une nomenclature « standardisée » sur la chose, je l'ignorais.

Dans Kate, ça existe sous l'appellation “Dynamic Word Wrap” et ça se règle soit dans l'interface graphique soit dans les variables de documents.

Dans la figure, les petits marqueurs ressemblant à des guillemets fermant indiquent des tabulations. Les marqueurs des lignes 10 à 13 montrent que la longueur des tabulations est adaptative. À chaque fois, remarquez la longueur de TAB juste après le point-virgule et juste avant la fermeture du commentaire.

Après, j'imagine qu'il est très peu probable qu'il y ait des projets qui exigeraient Kate pour le développement, donc Kate c'est cool pour les elastic tabstops mais ce n'est guère « industriel ».

Je n'avais aucune idée de la dépréciation de l'extension, d'habitude Firefox affiche des avertissements quand une extension est obsolète mais pour celle-ci, il n y a rien d'affiché quand j'ouvre la page des préférences. Alors, merci du signalement !

En creusant un peu, on constate que le développeur a effectivement abandonné le projet, à l'heure actuelle le dernier commit date du 4 novembre 2017 et il y a un avertissement clair à la page liée.

Le nouveau projet est Auto Tab Discard, par le même contributeur, voir ici et là.

Une autre approche est celle de Tab Suspender qui fige la consommation des ressources de tous les N+1-ième onglets, dès que l'un de ceux-ci est ouvert depuis plus de X minutes. N et X sont bien entendu configurables. Dès que l'on bascule sur un onglet figé, il est rechargé et le cycle de gélification concernera le reste des onglets ouverts.

C'est un cauchemar de dépendences digne des pire paquets d'Haskell […] un petit nix-store -q --graph sur pandoc me donne […] un graph de + de 6500 dependances.

Il y a tout sauf de l'hyperbole dans cette citation :) Parmi les 6500 dépendances, y aurait-il la glibc ou équivalent ?

Plus sérieusement, ma réponse initiale concernait les propos d'anaseto et Ingo Schwarze qui parlaient de façon on ne peut plus claire de dépendances directes. Matthias Kilian a même dû s'assurer de désinstaller toute autre chose différente de GHC & cabal pour être sûr de ne tirer que le strict minimum Haskell requis à la compilation de Pandoc.

Dans les points qui me chagrinent un peu dans ce logiciel, c'est […] surtout le nombre de dépendances (exagéré même selon les standards Haskell, autour de 100 !) […]

Factuellement, les courriels de Matthias Kilian et d'Ingo Schwarze ne sont pas corrects quant au nombre de dépendances directes de Pandoc car celui-ci n'atteint pas la centaine :

• moins d'une soixantaine si on veut le binaire pandoc
• une dizaine de plus si on ajoute le binaire trypandoc

Néanmoins, l'histoire est tout autre si l'on ajoute les dépendances transitives ; mais dans ce cas, on arrivera à bout du compte à reprocher à Pandoc de dépendre de la glibc et équivalents :)

Au-delà de cette banale comptabilité, la vraie question consiste dans le pourquoi de toutes ces dépendances et la réponse est donnée dans l'aide du logiciel : “Pandoc includes a Haskell library and a standalone command-line program. The library includes separate modules for each input and output format, so adding a new input or output format just requires adding a new module.” que je traduis de la sorte :

« Le projet Pandoc englobe une bibliothèque et un binaire à lancer sur la ligne de commandes. La bibliothèque se sert d'un module dédié afin de traiter chaque format d'entrée (respectivement de sortie) […] »

Généralement, les modules Haskell suffisamment distincts les uns des autres se retrouvent dans des paquets différents. Vu la quantité de formats que supporte Pandoc et sans parler des extensions (à la fois celles mentionnées dans la dépêche et celles-ci), il n'est pas étonnant d'avoir des dizaines de paquets comme dépendances.

Cela dit, étant donné à qui je répond, je n'ai pas de doute que ma logorrhée supra est superflue, la personne en question étant sans doute déjà au courant de tout ça. Peut-être que la partie citée au début de ce commentaire était sarcastique. Plus important, en 2018, on ne devrait plus utiliser cabal install pandoc pour compiler Pandoc comme dans le courriel de Matthias Kilian ; il est temps de rafraichir les workflows et de passer à cabal new-build pandoc et consorts.

Oui. À ma connaissance, les premières attaques par canaux cachés visant les caches du processeur datent de cette décennie (p.ex. Gullasch et al. 2011, Hund et al. 2013, Irazoqui et al. 2015, etc.).
Si c’est réellement le cas (je ne prétends avoir fait le tour de la littérature sur la question, …

Je n'ai pas d'expertise non plus sur la question, mais divers experts disent que la problématique a été explorée bien avant les années 2010, en témoignent ces quelques discussions sur la toile :

• Colin Percival en réponse à Daniel Gruss, un des auteurs du papier « KAISER »

  My most cherished rejection: My 2005 paper demonstrating stealing RSA keys through a side channel in Intel Hyperthreading was rejected by the Cryptology ePrint Archive because "the connection to cryptology" was "rather weak".

• Alex Ionescu :

  I think everyone jumped into it too quickly without fully working out the ramifications—or worse, brushing them off. I've personally heard whispers of L3 sharing and side-channel timing attacks (as I'm sure many others have) for over a decade, always brushed off as "academic".

À mon avis, il est trop tôt pour établir si les fondeurs ont agi de bonne foi ou non. Peut-être qu'avec beaucoup plus de recul, une historique plus fournie sortira pour éclairer ce point.

Votre avis me sera utile pour savoir si le projet semble avoir du sens.

“From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Date: 25 Aug 91 20:57:08 GMT
[…] just a hobby, won’t be big and professional […]”

Pour le reste, dans l'esprit du commentaire de Michaël, je dirais que l'approche la moins bidouilleuse serait de partir sur un langage de haut niveau, statiquement typé et de le doter d'une interface adéquate par rapport à tes besoins. Ici, le domaine interface est bien défini, c'est le Shell. Je propose alors Haskell comme langage et turtle comme bibliothèque procurant une interface mimant le Shell. Gabriel Gonzalez a écrit un excellent tutoriel sur cette bibliothèque auquel je renvoie au lieu de tenter de présenter la chose ici ; voici plutôt un exemple adapté des cas d'utilisations présentés dans le journal.

#!/home/foo/.local/bin/stack
-- stack runghc --package turtle

{-# LANGUAGE OverloadedStrings #-}

import Turtle (
    ( <$> )
    , Alternative ( empty )
    , Applicative ( pure )
    , FilePath
    , MonadIO
    , Text
    , fold
    , input
    , inshell
    , lineToText
    , ls
    , output
    , unsafeTextToLine
    , view
    )
import Control.Foldl ( head, length )
import Data.Text ( concat, pack )
import Prelude ( ( . ), ( >> ), Maybe ( Just, Nothing ), Show ( show ) )

main = eg1
    >> eg2 "nb_files.txt"
    >> eg3 "ls" "ls_opts" "log_ls"

-- ls
eg1 = ( view . ls ) "."

-- ls -l | wc -l > nb_files.txt
eg2 outFile = do
    fileCount <- fold ( ls "." ) length
    outFile `output` ( pure . unsafeTextToLine . pack . show ) fileCount

-- Variation sur le thème « exécuter [un] programme externe […] prenant en paramètre une chaine de caractères [contenue dans un fichier …] »
eg3 :: MonadIO io => Text -> FilePath -> FilePath -> io ()
eg3 prog optFile logFile = do
    mayOpts <- fold ( lineToText <$> input optFile ) head
    case mayOpts of
        Nothing     -> output logFile ( inshell "Bad options" empty )
        Just opts   -> output logFile ( concat [ prog, " ", opts ] `inshell` empty )

En rendant hommage au problème de l’œuf et de la poule, testons ce script (nommé code.hs) sous Bash.

mkdir woe
pushd woe
touch ceci cela ça
printf '%s\n' '-l --human-readable --context' > ls_opts
chmod u+x code.hs
./code.hs
cat log_ls

Les sorties :

FilePath "./code.hs"
FilePath "./ls_opts"
FilePath "./\231a"
FilePath "./cel\224"
FilePath "./ceci"
-rw-r-----. 1 foo foo unconfined_u:object_r:user_home_t:s0…

Bref, cette bibliothèque et le Shell, c'est comme les chéloniens et les carapaces. Cependant, comme sous-entendu au début de ce commentaire, que rien ne t'arrête dans tes expérimentations car, après tout, un OS entier est né par bidouillage.

Oui, un de ces quatre, ré-essaie du Haskell, c'est du bon :)

[…] j'aimerais bien savoir s'il y a une quelconque recherche sérieuse [sur] l'influence du langage sur la communauté (style de la doc, outils, etc.) et les moyens de contrôler ça.

Dans mes heures perdues, je lis de la Sociologie et disciplines apparentées, il y a des spécialités dans ces domaines tournées sur les sciences et pratiques de l'Informatique. Je n'ai pas une référence bien précise à donner tout de go, mais juste la première qui me vient après quelques clics sur Google Scholar : Type Systems and Programmers. Page 39 (traduction à l'arrache) :

« Les annotations de type font partie de la documentation dans le sens où elles transmettent avec le code l'intention de son utilisation. Elles ont également un rôle normatif dans le sens où elles prescrivent ce à quoi le code ne devrait pas servir. »

Visiblement, pour les auteurs et l'échantillon considéré, entre typer et faire de la prose, le choix est vite fait :) (O.K., je trolle, c'est vendredi …) À la page suivante, les auteurs relatent les effets de partir sur des exemples : quand le public visé a des niveaux hétérogènes, il y aura toujours des individus laissés pour compte.

Je n'ai pas convenablement lu la thèse, ne pourrai donc en faire un juste résumé et place la référence ici comme un bookmark contextualisé (à mon usage). Peut-être qu'en y creusant, tu trouveras des pistes quant à ton questionnement.

Sur le fond, la réponse de gasche ci-dessus est suffisante : quand on documente une bibliothèque, on est obligé à faire des choix entre rester au niveau le plus général ou spécialiser (arbitrairement) la documentation.

Je trouve que, pour une bibliothèque livrée avec le compilateur, spécialiser un concept général n'est pas optimal : on pourrait bien mettre du texte dans MonadIO expliquant comment dériver la classe pour créer des fonctions lisant/écrivant des fichiers sur le disque, mais quid des gens qui viendront lire la doc en ayant besoin de travailler plutôt avec des bases de données ? Serait-ce une adéquate utilisation de leur temps en les promenant sur des paragraphes ne traitant pas de leurs besoins ? La voie des tutoriels, conférences, et autres postes de blogs me paraît être la bonne dans ce cas.

Par contre, quand les usages d'une bibliothèque sont presque totalement connus, illustrer la doc est tout à fait adéquat. Dans le cas des bibliothèques maintenues par GHC-HQ, on ne se prive pas de le faire.

Ceci dit, il y a des contre-exemples de bibliothèques implémentant des concepts généralistes mais dont la doc est bourrée d'exemples pour quelques restrictions d'applications ; voir par exemple la fameuse lens.

Et n'oublions pas que c'est du logiciel libre : je ne doute pas que tu as les compétences nécessaires pour rédiger un patch de la documentation que tu as potassée ; pourquoi ne pas contribuer ? Et ça tombe bien, l'outillage est en train d'être ripoliné pour faciliter les contributions.

P.S. Pour maximiser le sous-hors-sujet Haskell dans un déjà hors-sujet Go, à propos des opérateurs qui seraient horribles comme tu l'écrivais ailleurs dans les commentaires: je trouve qu'utiliser une bibliothèque en explicitant tous les éléments qu'on en importe aide énormément à rendre le code intelligible même après des années d'abandon. Ceci vaut aussi pour Prelude. Concrètement :

• Première itération d'écriture du code : mettre des import Foo dans l'en-tête, import Prelude comprise.
• Deuxième itération: dire au compilateur de nous indiquer ce qu'on a utilisé, ghc -ddump-to-file -ddump-minimal-imports
• Enfin, remplacer les imports manuels par ceux automatisés. Comme ça, des mois plus tard, quand on rencontrera un opérateur ésotérique, il suffira de voir où il se trouve dans l'en-tête et suivre la documentation du module correspondant.