Posté par barmic 🦦 .
Évalué à 2.
Dernière modification le 03 juin 2024 à 11:07.
Je dirais qu'ils ont fait des choix différents pour le français par rapport au bépo et ils ont pris en compte l'anglais et les caractères les plus utilisés en code. Il ne se revendique pas en tout point meilleurs que bépo.
C’est une alternative comme il en existe des dizaines !
C’est vrai qu’il existe plein d’autres dispo plus «performante» que le Bépo, mais en générale elles ne reprennent pas toutes les contraintes qui ont été posé au moment de la conception du Bépo. Elle s’en mettre d’autre aussi.
Donc de mon point de vue seul ceux qui gère la disposition peuvent nommer son remplaçant … tous les autres ne sont que des alternatives.
Après avoir rapidement survolé le billet, il parle d’«après» pour son cas à lui … mais le titre est un peu clicapute de prime abord.
Je suis aussi sur de l’après bépo, ou plutôt je m’en éloigne doucement, mais cela vient surtout d’un changement de clavier plutôt qu’un changement de disposition.
Après plus d’une dizaine d’année avec mon typematrix, celui-ci a commencé à montrer des signes de fatigues (capuchons en silicone qui se déchirent), et j’ai commencé mes recherches pour remplacer le clavier et ait finalement monté un clavier à base de rp2040. Il utilise le firmware QMK, qui permet programmer le clavier vraiment à sa guise.
Pour faire vite, au moment où l’on presse une touche, l’évènement est transmis au rp2040, qui décide s’il :
envoie la touche au système
utilise cette information pour modifier son état interne
envoie une autre touche au système en fonction de son état interne
On retrouve un peu le même système avec la touche Fn sur les pc portables : l’activer ne change pas la disposition du clavier, mais change les effets des touches.
Et les effets sont sans limites : en gardant les doigts sur la ligne de base, avec les indexes sur les touches F et J en azerty — ou E et T en bépo) :
la touche F se transforme en Contrôle gauche quand je presse une autre touche en même temps (pareil, la touche J se transforme en Ctrl Droit)
la touche Espace se transforme en Alt
la touche Meta (mod4) active automatiquement les flèches de direction (car le raccourci mod4 + Flêche gauche est utilisé pour naviguer entre mes fenêtres)
un double C très vite produit un Ç (le C est utilisé en bépo avec l’index, et c’est moins fatiguant pour moi de faire travailler ce doigt)
et encore d’autres
Et tout ça est géré au niveau du clavier. Le gros avantage du bépo là dedans est que le pilote gère en standard beaucoup plus de touche que l’azerty. C’est beaucoup plus facile d’envoyer un caractère précis quand le système fait la différence entre É, E et È qu’avec un pilote azerty.
Au final, la disposition bépo est juste parfaite pour construire le clavier adapté à ses besoins : il y a tellement de caractères disponible sous la main qu’il suffit de piocher le sous ensemble qui nous intéresse pour construire le clavier qui nous correspond vraiment.
Un clavier mécanique custom comme c'est la "mode"1 ? Genre 60% avec des cherry-mx, etc
Et tout ça est géré au niveau du clavier. Le gros avantage du bépo là dedans est que le pilote gère en standard beaucoup plus de touche que l’azerty. C’est beaucoup plus facile d’envoyer un caractère précis quand le système fait la différence entre É, E et È qu’avec un pilote azerty.
Je comprends pas. Mon fr-oss distingue très bien ces caractères et un paquet d'autres (des espaces insécables, des guillemets français,…).
si on peu parler de mode pour un hobby de niche comme celui-ci ↩
Ah ah parler de mode de niche dans un thread sur le bépo, tu y vas fort !
Effectivement, le système gère très bien tout ces caractères, mais comme ils nécessitent des combinaisons de touches supplémentaires, cela rend les choses plus compliquées au niveau de la programmation du clavier.
Prenons l’exemple du é sur ce layout : il est en accès direct :
Si l’on souhaite avoir une touché dédiée pour envoyer ce caractère, il faut aussi envisager les variations, en restant cohérent avec le reste du clavier. Or ici, la version en capitale se fait avec la combinaison Maj+AltGr.
On peut dans le code du contrôleur détecter la combinaison Maj + é et envoyer à la place Maj + AltGr + é, mais cela demande un travail plus important pour faire les correspondance de chaque caractère. Je voulais juste dire que bépo permettait de construire plus facilement ses propres combinaisons de touche car tout est déjà uniforme.
Posté par Serge Julien .
Évalué à 3.
Dernière modification le 03 juin 2024 à 14:47.
[…] et ai finalement monté un clavier à base de rp2040
J'ai regardé du côté de QMK, ça a l'air intéressant ! Mais y a-t-il des ressources qui concernent le hardware en lui-même (schémas, PCBs, composants…)?
Le plus souvent, tu pourras trouver un kit avec le PCB et les composants de base (diodes etc), à monter toi même. Il y a quelques gammes de clavier que tu retrouveras chez tous les vendeurs (sofle, lily58) qui sont reconnus comme étant « grand public » dans ce monde de niche, et d’autres bien plus spécifiques. Certains constructeurs comme keychron proposent des clavier compatibles si tu veux rester sur un format de clavier classique tout en ayant les options pour le personnaliser.
Depuis un mois je me retrouver à utiliser linux (depuis 20 ans), windows (depuis quelques années) et Mac (depuis un mois). J'avais réussi à configurer fr-oss sur windows, mais j'ai rien trouvé pour Mac (en cherchant assez rapidement j'avoue). Mais ergo-l m'intéresse du fait de sa promesse de prendre en compte tous mes cas d'utilisations et ce sera l'occasion de passer à une frappe 100% à l'aveugle. Actuellement ça dépend, si je suis lancé je regarde pas mais quand je démarre ou que je bouge un peu trop les mains je dois regarder et peut être de temps en temps aussi (bref c'est pas clean).
Je reste assez dubitatif en regardant la disposition, notamment pour la programmation, ils reprennent la super mauvaise idée du QWERTY de gâcher tous les accès directs de la barre de chiffre, et tous les symboles ont besoin d'un modificateur (je repasse souvent en azerty quand je veux programmer chez moi, et je n'ai jamais sauté le pas au boulot).
Cela dit je vais suivre avec attention les autres retours inexpérience.
Le fait de vouloir des accès direct au chiffres vient je pense des claviers 60, 65, 70, 75 et TKL qui n'ont pas de pavé numérique.
La touche de modification se comporte un peu différemment des touches de modification classique. Tu peut l'appuyer et appuyer sur une autre touche et ça fais le symbole ou tu peux appuyer simplement dessus la relâcher et appuyer sur la touche qui te permet d'avoir le symbole (un nouvel appuie sur la touche de modification annule le changement). Il me semble que ça permet plus de liberté sur la manière d'y accéder.
Pour azerty, tu a un paquet de caractères qui ne sont pas en accès directe et les chiffres sont bien utiles aussi en programmation.
Juste pour nuancer, je tape rarement des chiffres en programmation. À part peut-être le 0. En général on utilise un chiffre, mais on ne tape pas des nombres si souvent que ça. L’accès direct aux chiffres gâche l’accès aux autres caractères, genre les parenthèses.
Posté par freem .
Évalué à 5.
Dernière modification le 03 juin 2024 à 13:23.
et les chiffres sont bien utiles aussi en programmation.
Ben en fait, pas tant que ça.
En programmation, on utilise les chiffres pour mettre une valeur précise dans un symbole, puis on manipule le symbole, ça facilite la maintenance quand on n'a pas besoin de se demander quelles autres occurrences d'un nombre doivent être modifiées.
Si je prend le cas de mon mod d'Unvanquished, par exemple, sur les 137438 lignes de code (et vides, et commentaires, et licences, certes), seules 12764 contiennent le pattern: \<[0-9].
6341 de ces lignes contiennent celui-ci: \<0\(\.\(0\)*\)*\> qui correspond à la valeur 0, flottante ou entière, utilisée pour (ré)initialiser. Donc, 6423 lignes contiennent a coup sûr des nombres pertinents, ce qui nous fais moins de 5% (à noter que, la aussi, ça inclue les commentaires et les licences!).
Donc, non, les chiffres ne sont pas très utiles en programmation. Je serais surpris que les valeurs changent tant que ça avec d'autres projets, et d'ailleurs, unvanquished est un jeu 3D, on devrais, justement, s'attendre a pas mal de chiffres, mais non.
Je pourrais faire la mesure avec les parenthèses, accolades, crochets, moins, plus, astérisque, barres obliques et droites, esperluettes, arobases, mais… est-ce vraiment utile?
Autre métrique, beaucoup plus "brute", sur la même base de code:
% find -type f -exec cat {} \+ > /tmp/concat
sed 's/[0-9]//g' /tmp/concat | wc -c
3598252
% sed 's/[^0-9]//g' /tmp/concat | wc -c
173930
% sed 's/[^&"'\''(-_)=]//g' /tmp/concat | wc -c
672044
Moins de 5% des caractères sont des chiffres, contre plus de 18% qui sont des caractères accessibles sans modificateurs d'aucune sorte. En vrai, je m'attendais quand même à moins de caractères non alphanumériques et plus d'alpha, comme quoi…
Toujours est-il que très clairement, bloquer une ligne pour les chiffres est inefficace pour de la programmation, au moins en C ou C++, et dans mon expérience. Mais honnêtement, je doute très fort que le langage change la donne tant que ça, ou que des expériences plus… digitales, je suppose, puissent faire mieux que doubler la valeur des chiffres, et dans ce cas, je doute fort qu'il y ait moins de (, ), -, =, …
Moins de 5% des caractères sont des chiffres, contre plus de 18% qui sont des caractères accessibles sans modificateurs d'aucune sorte. En vrai, je m'attendais quand même à moins de caractères non alphanumériques et plus d'alpha, comme quoi…
C'était un peu mon point sachant que perso, quand je code, je dois citer des tiquets dans le nom de mes branches et ou dans mes commits par exemple. Sachant que prendre des caractères qui ne sont pas derrière des chiffres fait gonfler ta statistique.
Toujours est-il que très clairement, bloquer une ligne pour les chiffres est inefficace pour de la programmation
Tout comme avoir éèàç (soit 40% des chiffres) et on peut parler de ù et ² qui méritent tous 2 (même pour le français, hein) d'être accessibles sans modificateurs.
Si je regarde Ergo-L je ne trouve pas de caractères primo-accessibles qui ne me paraisse pas pertinents.
Après chacun son clavier, moi je vais l'essayer on verra si j'en reviens.
Je me contentais de répondre a la partie qui suggère que les chiffres sont plus usités en programmation que les caractères "autres", rien de plus.
La gestion des tickets (et de l'historique du code) n'est techniquement pas de la programmation, ce genre de choses sont utilisées dans d'autres domaines, après tout. Et malgré tout, je serais curieux de voir le ration de chiffres vs autres dans un descriptif de commit. Si le descriptif se contente d'un numéro de ticket sans autre information, alors franchement c'est moche, ça casse le workflow de devoir aller chercher un autre outil pour avoir une info complète.
Mais je suppose qu'en effet, les caractères de la barre des chiffres en azerty n'y ont que peu d'intérêt. Malgré tout, l'écriture des textes de commit est une tâche mineure. On pourrais aussi arguer (avec une bonne dose de mauvaise foi, ça devrais passer…) que des IDs ne sont pas des nombres, et qu'un autre logiciel utilisera à la place un autre système (non, je n'en connais pas :)). Sur le papier, ça tiens.
Moins de 5% des caractères sont des chiffres, contre plus de 18% qui sont des caractères accessibles sans modificateurs d'aucune sorte
Je me suis mal exprimé ici, mais je pense que tu as bien compris que par "caractères accessibles sans modificateurs d'aucune sorte" j'entendais en azerty, d'une part, et d'autre part que je parlais des caractères dans la regex, qui sont une partie de ceux disponibles. En programmation, les autres ne me servent à rien, vu que je programme exclusivement en anglais (j'y arrive pas en français, aucune idée de pourquoi)
Je prouve juste sur un projet réel que les chiffres sont largement moins utilisés que les autres caractères utiles en prog (et plus précisément C++ ici, d'autres langages ont peut-être un ratio différent en faveur des chiffres, mais j'attend une preuve). C'est tout.
Me dire que dans les commits et les tickets on utilise des chiffres, ça c'est hors contexte, parce que les gestionnaires de tickets et de version sont loin d'être exclusifs à la programmation (cf PLM).
Qui plus est, la gestion des tickets et des commits, bien que très utile quand fait correctement, ne prend pas vraiment une part importante des frappes clavier quand on écrit du code… le déboguage et l'écriture, par contre si.
Je rappelle que le message d'origine de ce thread dit ceci (le gras est de moi):
Je reste assez dubitatif en regardant la disposition, notamment pour la programmation
On parlait de layout de clavier et des 10 touches numériques. Est-ce qu'avoir sur ces 10 touches des nombres ou les caractères que donne l'azerty est le plus pratique. Tu fais des comparaisons en ignorant des caractères de ces touches et en en prenant d'autres qui ne sont pas concernés.
Tu n'arrive même pas à couper suffisamment la citation pour cacher le fait qu'on parle de disposition de clavier. Le choix dont il parle de ergo-l met à disposition en accès direct une partie de ce que tu lui a opposé (pour rappel /\\'[]<= et le ` que je n'arrive pas à échapper).
En fait soit tu parle du sujet de base mais en comparant des dispositions imaginaires soit tu a voulu me reprendre sur le fait d'avoir dis qu'on utilise quand même pas mal les chiffres en programmation et tu me reproche de ne pas avoir était parfaitement précis en parlant de ce qu'il peut y avoir autour du code (sachant que je parlais dans le cadre d'une comparaison avec l'azerty qui encore une fois met en accès plus direct è à la place de 7 ou ç plutôt que 9).
Il y a encore beaucoup de programmeurs Cobol, et des chiffres, il y en a une pelletée.
En scripting, c’est pas rare non plus. Surtout sur du script qui ne sert qu’une seule fois ; tu fais beaucoup de code en dur.
Et développer, ce n’est pas qu’écrire du code. C’est souvent tester (et saisir des valeurs en entrée et les attendus en sortie, ça implique souvent des chiffres), préparer ou analyser des fichiers de données, de configuration, …
Perso je privilégie surtout des claviers avec pavé numérique pour développer.
Faudra que j’essaye bepo ou autre un de ces quatres.
Il semble qu'optimot a une démarche plus fermée avec des évaluations de ses qualités non reproductibles (et son concepteur refuserai de fournir les moyens de reproduire).
# Principe
Posté par cosmocat . Évalué à 6.
C'est une disposition clavier qui est censée être meilleure que le bépo pour le français, l'anglais et la programmation.
C'est un peu mieux mis en avant sur le site: https://ergol.org/presentation/
Les 2 créateurs sont sur mastodon:
https://piaille.fr/@NuclearSquid
https://piaille.fr/@fabi1cazenave@mastodon.social
Lié: https://piaille.fr/@NuclearSquid/112501415552631532
[^] # Re: Principe
Posté par BAud (site web personnel) . Évalué à 6.
et il y a une dépêche — actuellement en cours de rédaction — concernant ergo-L :
https://linuxfr.org/redaction/news/ergo-l-disposition-de-clavier-ergonomique-pour-le-francais-l-anglais-et-la-programmation
quand elle sera publiée, l'url deviendra : https://linuxfr.org/news/ergo-l-disposition-de-clavier-ergonomique-pour-le-francais-l-anglais-et-la-programmation
[^] # Re: Principe
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 03 juin 2024 à 11:07.
Je dirais qu'ils ont fait des choix différents pour le français par rapport au bépo et ils ont pris en compte l'anglais et les caractères les plus utilisés en code. Il ne se revendique pas en tout point meilleurs que bépo.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Il n’y a pas d’«après»
Posté par Mimoza . Évalué à 10.
C’est une alternative comme il en existe des dizaines !
C’est vrai qu’il existe plein d’autres dispo plus «performante» que le Bépo, mais en générale elles ne reprennent pas toutes les contraintes qui ont été posé au moment de la conception du Bépo. Elle s’en mettre d’autre aussi.
Donc de mon point de vue seul ceux qui gère la disposition peuvent nommer son remplaçant … tous les autres ne sont que des alternatives.
Après avoir rapidement survolé le billet, il parle d’«après» pour son cas à lui … mais le titre est un peu clicapute de prime abord.
# Mon après bépo à moi
Posté par chimrod (site web personnel) . Évalué à 4.
Je suis aussi sur de l’après bépo, ou plutôt je m’en éloigne doucement, mais cela vient surtout d’un changement de clavier plutôt qu’un changement de disposition.
Après plus d’une dizaine d’année avec mon typematrix, celui-ci a commencé à montrer des signes de fatigues (capuchons en silicone qui se déchirent), et j’ai commencé mes recherches pour remplacer le clavier et ait finalement monté un clavier à base de rp2040. Il utilise le firmware QMK, qui permet programmer le clavier vraiment à sa guise.
Pour faire vite, au moment où l’on presse une touche, l’évènement est transmis au rp2040, qui décide s’il :
On retrouve un peu le même système avec la touche
Fnsur les pc portables : l’activer ne change pas la disposition du clavier, mais change les effets des touches.Et les effets sont sans limites : en gardant les doigts sur la ligne de base, avec les indexes sur les touches
FetJen azerty — ouEetTen bépo) :Fse transforme en Contrôle gauche quand je presse une autre touche en même temps (pareil, la toucheJse transforme en Ctrl Droit)Espacese transforme en AltMeta(mod4) active automatiquement les flèches de direction (car le raccourci mod4 + Flêche gauche est utilisé pour naviguer entre mes fenêtres)Ctrès vite produit unÇ(leCest utilisé en bépo avec l’index, et c’est moins fatiguant pour moi de faire travailler ce doigt)Et tout ça est géré au niveau du clavier. Le gros avantage du bépo là dedans est que le pilote gère en standard beaucoup plus de touche que l’azerty. C’est beaucoup plus facile d’envoyer un caractère précis quand le système fait la différence entre
É,EetÈqu’avec un pilote azerty.Au final, la disposition bépo est juste parfaite pour construire le clavier adapté à ses besoins : il y a tellement de caractères disponible sous la main qu’il suffit de piocher le sous ensemble qui nous intéresse pour construire le clavier qui nous correspond vraiment.
[^] # Re: Mon après bépo à moi
Posté par barmic 🦦 . Évalué à 3.
Un clavier mécanique custom comme c'est la "mode"1 ? Genre 60% avec des cherry-mx, etc
Je comprends pas. Mon fr-oss distingue très bien ces caractères et un paquet d'autres (des espaces insécables, des guillemets français,…).
si on peu parler de mode pour un hobby de niche comme celui-ci ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mon après bépo à moi
Posté par chimrod (site web personnel) . Évalué à 3.
Ah ah parler de mode de niche dans un thread sur le bépo, tu y vas fort !
Effectivement, le système gère très bien tout ces caractères, mais comme ils nécessitent des combinaisons de touches supplémentaires, cela rend les choses plus compliquées au niveau de la programmation du clavier.
Prenons l’exemple du
ésur ce layout : il est en accès direct :Si l’on souhaite avoir une touché dédiée pour envoyer ce caractère, il faut aussi envisager les variations, en restant cohérent avec le reste du clavier. Or ici, la version en capitale se fait avec la combinaison Maj+AltGr.
On peut dans le code du contrôleur détecter la combinaison
Maj+éet envoyer à la placeMaj+AltGr+é, mais cela demande un travail plus important pour faire les correspondance de chaque caractère. Je voulais juste dire que bépo permettait de construire plus facilement ses propres combinaisons de touche car tout est déjà uniforme.[^] # Re: Mon après bépo à moi
Posté par Serge Julien . Évalué à 3. Dernière modification le 03 juin 2024 à 14:47.
J'ai regardé du côté de QMK, ça a l'air intéressant ! Mais y a-t-il des ressources qui concernent le hardware en lui-même (schémas, PCBs, composants…)?
[^] # Re: Mon après bépo à moi
Posté par chimrod (site web personnel) . Évalué à 2.
Le plus souvent, tu pourras trouver un kit avec le PCB et les composants de base (diodes etc), à monter toi même. Il y a quelques gammes de clavier que tu retrouveras chez tous les vendeurs (sofle, lily58) qui sont reconnus comme étant « grand public » dans ce monde de niche, et d’autres bien plus spécifiques. Certains constructeurs comme keychron proposent des clavier compatibles si tu veux rester sur un format de clavier classique tout en ayant les options pour le personnaliser.
Laisse donc un message sur le forum lemmy ou consulte la page wiki si tu veux plus d’infos pour te lancer.
# Envi d'essayer
Posté par barmic 🦦 . Évalué à 3.
Depuis un mois je me retrouver à utiliser linux (depuis 20 ans), windows (depuis quelques années) et Mac (depuis un mois). J'avais réussi à configurer fr-oss sur windows, mais j'ai rien trouvé pour Mac (en cherchant assez rapidement j'avoue). Mais ergo-l m'intéresse du fait de sa promesse de prendre en compte tous mes cas d'utilisations et ce sera l'occasion de passer à une frappe 100% à l'aveugle. Actuellement ça dépend, si je suis lancé je regarde pas mais quand je démarre ou que je bouge un peu trop les mains je dois regarder et peut être de temps en temps aussi (bref c'est pas clean).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Mouais, à voir
Posté par Lutin . Évalué à 5.
Je reste assez dubitatif en regardant la disposition, notamment pour la programmation, ils reprennent la super mauvaise idée du QWERTY de gâcher tous les accès directs de la barre de chiffre, et tous les symboles ont besoin d'un modificateur (je repasse souvent en azerty quand je veux programmer chez moi, et je n'ai jamais sauté le pas au boulot).
Cela dit je vais suivre avec attention les autres retours inexpérience.
[^] # Re: Mouais, à voir
Posté par barmic 🦦 . Évalué à 3.
Le fait de vouloir des accès direct au chiffres vient je pense des claviers 60, 65, 70, 75 et TKL qui n'ont pas de pavé numérique.
La touche de modification se comporte un peu différemment des touches de modification classique. Tu peut l'appuyer et appuyer sur une autre touche et ça fais le symbole ou tu peux appuyer simplement dessus la relâcher et appuyer sur la touche qui te permet d'avoir le symbole (un nouvel appuie sur la touche de modification annule le changement). Il me semble que ça permet plus de liberté sur la manière d'y accéder.
Pour azerty, tu a un paquet de caractères qui ne sont pas en accès directe et les chiffres sont bien utiles aussi en programmation.
Bref moi c'est un choix qui me parle.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mouais, à voir
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 6.
Juste pour nuancer, je tape rarement des chiffres en programmation. À part peut-être le 0. En général on utilise un chiffre, mais on ne tape pas des nombres si souvent que ça. L’accès direct aux chiffres gâche l’accès aux autres caractères, genre les parenthèses.
[^] # Re: Mouais, à voir
Posté par freem . Évalué à 5. Dernière modification le 03 juin 2024 à 13:23.
Ben en fait, pas tant que ça.
En programmation, on utilise les chiffres pour mettre une valeur précise dans un symbole, puis on manipule le symbole, ça facilite la maintenance quand on n'a pas besoin de se demander quelles autres occurrences d'un nombre doivent être modifiées.
Si je prend le cas de mon mod d'Unvanquished, par exemple, sur les 137438 lignes de code (et vides, et commentaires, et licences, certes), seules 12764 contiennent le pattern:
\<[0-9].6341 de ces lignes contiennent celui-ci:
\<0\(\.\(0\)*\)*\>qui correspond à la valeur 0, flottante ou entière, utilisée pour (ré)initialiser. Donc, 6423 lignes contiennent a coup sûr des nombres pertinents, ce qui nous fais moins de 5% (à noter que, la aussi, ça inclue les commentaires et les licences!).Donc, non, les chiffres ne sont pas très utiles en programmation. Je serais surpris que les valeurs changent tant que ça avec d'autres projets, et d'ailleurs, unvanquished est un jeu 3D, on devrais, justement, s'attendre a pas mal de chiffres, mais non.
Je pourrais faire la mesure avec les parenthèses, accolades, crochets, moins, plus, astérisque, barres obliques et droites, esperluettes, arobases, mais… est-ce vraiment utile?
[^] # Re: Mouais, à voir
Posté par freem . Évalué à 3.
Autre métrique, beaucoup plus "brute", sur la même base de code:
Moins de 5% des caractères sont des chiffres, contre plus de 18% qui sont des caractères accessibles sans modificateurs d'aucune sorte. En vrai, je m'attendais quand même à moins de caractères non alphanumériques et plus d'alpha, comme quoi…
Toujours est-il que très clairement, bloquer une ligne pour les chiffres est inefficace pour de la programmation, au moins en C ou C++, et dans mon expérience. Mais honnêtement, je doute très fort que le langage change la donne tant que ça, ou que des expériences plus… digitales, je suppose, puissent faire mieux que doubler la valeur des chiffres, et dans ce cas, je doute fort qu'il y ait moins de (, ), -, =, …
[^] # Re: Mouais, à voir
Posté par barmic 🦦 . Évalué à 4.
C'était un peu mon point sachant que perso, quand je code, je dois citer des tiquets dans le nom de mes branches et ou dans mes commits par exemple. Sachant que prendre des caractères qui ne sont pas derrière des chiffres fait gonfler ta statistique.
Tout comme avoir
éèàç(soit 40% des chiffres) et on peut parler deùet²qui méritent tous 2 (même pour le français, hein) d'être accessibles sans modificateurs.Si je regarde Ergo-L je ne trouve pas de caractères primo-accessibles qui ne me paraisse pas pertinents.
Après chacun son clavier, moi je vais l'essayer on verra si j'en reviens.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mouais, à voir
Posté par freem . Évalué à 3.
Je me contentais de répondre a la partie qui suggère que les chiffres sont plus usités en programmation que les caractères "autres", rien de plus.
La gestion des tickets (et de l'historique du code) n'est techniquement pas de la programmation, ce genre de choses sont utilisées dans d'autres domaines, après tout. Et malgré tout, je serais curieux de voir le ration de chiffres vs autres dans un descriptif de commit. Si le descriptif se contente d'un numéro de ticket sans autre information, alors franchement c'est moche, ça casse le workflow de devoir aller chercher un autre outil pour avoir une info complète.
Mais je suppose qu'en effet, les caractères de la barre des chiffres en azerty n'y ont que peu d'intérêt. Malgré tout, l'écriture des textes de commit est une tâche mineure. On pourrais aussi arguer (avec une bonne dose de mauvaise foi, ça devrais passer…) que des IDs ne sont pas des nombres, et qu'un autre logiciel utilisera à la place un autre système (non, je n'en connais pas :)). Sur le papier, ça tiens.
Je me suis mal exprimé ici, mais je pense que tu as bien compris que par "caractères accessibles sans modificateurs d'aucune sorte" j'entendais en azerty, d'une part, et d'autre part que je parlais des caractères dans la regex, qui sont une partie de ceux disponibles. En programmation, les autres ne me servent à rien, vu que je programme exclusivement en anglais (j'y arrive pas en français, aucune idée de pourquoi)
[^] # Re: Mouais, à voir
Posté par barmic 🦦 . Évalué à 1.
Oui mais l'enlever de son contexte est fallacieux et rend ton argumentaire peu pertinent dans la conversation à la quelle tu répond.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mouais, à voir
Posté par freem . Évalué à 3.
En quoi c'est hors sujet?
Je prouve juste sur un projet réel que les chiffres sont largement moins utilisés que les autres caractères utiles en prog (et plus précisément C++ ici, d'autres langages ont peut-être un ratio différent en faveur des chiffres, mais j'attend une preuve). C'est tout.
Me dire que dans les commits et les tickets on utilise des chiffres, ça c'est hors contexte, parce que les gestionnaires de tickets et de version sont loin d'être exclusifs à la programmation (cf PLM).
Qui plus est, la gestion des tickets et des commits, bien que très utile quand fait correctement, ne prend pas vraiment une part importante des frappes clavier quand on écrit du code… le déboguage et l'écriture, par contre si.
Je rappelle que le message d'origine de ce thread dit ceci (le gras est de moi):
[^] # Re: Mouais, à voir
Posté par barmic 🦦 . Évalué à 2.
On parlait de layout de clavier et des 10 touches numériques. Est-ce qu'avoir sur ces 10 touches des nombres ou les caractères que donne l'azerty est le plus pratique. Tu fais des comparaisons en ignorant des caractères de ces touches et en en prenant d'autres qui ne sont pas concernés.
Tu n'arrive même pas à couper suffisamment la citation pour cacher le fait qu'on parle de disposition de clavier. Le choix dont il parle de ergo-l met à disposition en accès direct une partie de ce que tu lui a opposé (pour rappel
/\\'[]<=et le ` que je n'arrive pas à échapper).En fait soit tu parle du sujet de base mais en comparant des dispositions imaginaires soit tu a voulu me reprendre sur le fait d'avoir dis qu'on utilise quand même pas mal les chiffres en programmation et tu me reproche de ne pas avoir était parfaitement précis en parlant de ce qu'il peut y avoir autour du code (sachant que je parlais dans le cadre d'une comparaison avec l'azerty qui encore une fois met en accès plus direct è à la place de 7 ou ç plutôt que 9).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mouais, à voir
Posté par Dring . Évalué à 3.
Il y a encore beaucoup de programmeurs Cobol, et des chiffres, il y en a une pelletée.
En scripting, c’est pas rare non plus. Surtout sur du script qui ne sert qu’une seule fois ; tu fais beaucoup de code en dur.
Et développer, ce n’est pas qu’écrire du code. C’est souvent tester (et saisir des valeurs en entrée et les attendus en sortie, ça implique souvent des chiffres), préparer ou analyser des fichiers de données, de configuration, …
Perso je privilégie surtout des claviers avec pavé numérique pour développer.
Faudra que j’essaye bepo ou autre un de ces quatres.
# Optimot
Posté par Simon Panay . Évalué à 0.
En me remettant à m'entrainer sur le Bépo à l'aide de https://bépoète.fr/, je suis tombé sur le layout https://optimot.fr/
J'ai l'impression qu'il tente d'adresser les même problématiques que Ergo-L (Écriture français-anglais +programmation).
Du coup, ça nous fait trois layouts concurrents et j'hésite à choisir l'un au l'autre…
[^] # Re: Optimot
Posté par Pol' uX (site web personnel) . Évalué à 2.
Moi je met un layout par ligne de caractères. Comme ça je profite d'un peu des avantages de chacun.
Adhérer à l'April, ça vous tente ?
[^] # Re: Optimot
Posté par barmic 🦦 . Évalué à 2.
Il semble qu'optimot a une démarche plus fermée avec des évaluations de ses qualités non reproductibles (et son concepteur refuserai de fournir les moyens de reproduire).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.