oui merci beaucoup pour les réponses. Ca répond plutôt bien à tout. Je rebondirai uniquement sur un seul point: l'espace insécable, qui est le seul qui me pose encore problème. Et je me rends compte en parcourant le reste du journal que je ne suis pas le seul. Pour ma part, je précise à nouveau que c'est en plus vraiment par expérience personnelle que je dis cela, puisque j'ai eu exactement cette même idée en me disant dans un premier temps que c'était vraiment une bonne idée d'avoir accès à l'espace insécable par maj-espace. En réalité perso, je ne m'embête pas vraiment avec ce caractère. Mais par exemple dans les équipes de trads de certains logiciels, ils nous demandaient de les mettre pour bien respecter la typographie française. Mais au bout d'un mois de souffrance avec cet espace insécable ainsi mappé, je l'ai jarté.
Le classique par exemple: rajouter un espace insécable après un point final (alors qu'il n'en faut pas) quand le doigt ne s'est pas relevé assez vite de maj. Dans le bépo, ce n'est plus un problème puisque le point est en accès direct, par contre le problème se pose toujours (ou nouvellement) avec ':', ';', '?' et '!'. Donc certes "avant" ces ponctuations, il faut un espace insécable (et là votre mapping réduit les efforts), mais pas après (et là ça crée des efforts supplémentaires pour supprimer, mais surtout pour se rendre compte qu'il y a un blem). Et la plupart du temps, on ne se rendra pas compte qu'on l'a rajouté.
Déjà donc ça pose problème pour la mise en page. Mais ce n'est pas mon vrai problème ni la raison pour laquelle j'ai arrêté d'utitliser ce mapping (je n'ai pas souvent l'occasion d'avoir à faire du formattage de texte de grande qualité, en plus dans beaucoup de cas, l'erreur peut ne même pas gêner la mise en page). Ce sera plus pour les traitements automatiques en réalité que ça m'a posé problème.
En effet le problème est que l'espace insécable est peut-être nécessaire typographiquement par endroit, mais ce n'est pas pour autant qu'il est accepté logiciellement là où l'espace l'est (puisque le caractère réel est différent). Par exemple, si je rentre un numéro de tél dans un site en mettant des espaces insécables, je suis sûr que certains sites diront "seuls les chiffres et les espaces sont acceptés dans ce champs".
Mais ce n'est toujours pas le pire! Là où j'ai vraiment beaucoup souffert, c'est déjà en développement. Quand un code ne compile pas bêtement parce que deux mots sont séparés par erreur d'un espace insécable et donc sont considérés comme une unique entité par le compilo qui se plaint. Ensuite va comprendre et trouver l'erreur (avant "l'habitude", il m'a fallu un temps de compréhension; et même après habitude, ça reste lourd puisqu'on s'en rend toujours compte après coup, au moment de la compilation, donc c'est particulièrement chiant).
Très classique aussi: l'ajout involontaire dans les commandes bash (même mécanisme que du code, sauf que là c'est encore plus courant puisque je suis constamment dans une console même en utilisation normale). Entre la commande et les paramètres par ex (donc bash considérant ma commande+paramètre1 comme un seul mot et me disait qu'il trouvait pas cette commande), ou bien entre 2 paramètres, etc.
Cela pouvait m'arriver après un '/' par ex, mais en bépp, ça pourrait arriver plutôt après un ';' (très courant en bash), ou un ':' (j'utilise beaucoup ssh/scp), et tout simplement en mettant des suites de chiffres en paramètres, etc.
Et même tout bêtement comme j'utilise un terminal multi-onglet avec maj-droit/gauche pour m'y déplacer, il m'arrivait de commencer une commande, puis de changer d'onglet pour vérifier qqch, puis de revenir et de continuer ma commande si vite que le doigt était encore sur maj quand je tapais espace (ou bien parce que je prévoyais de taper un caractère nécessitant maj juste après l'espace, donc je laissais le doigt sur maj sans y penser).
Enfin voilà. C'est peut-être à retester. Peut-être y a-t-il habitude à prendre, etc. Néanmoins l'espace insécable a vraiment ceci de particulier par rapport à tout le reste qu'il est invisible (ou plutôt indicernable de l'espace simple), donc qu'une erreur avec ce caractère est si fourbe qu'elle peut causer bien des soucis, des arrachages de cheveux et des pertes de temps. Donc en conclusion beaucoup d'effort perdu pour un effort gagné bien plus faible (selon moi). A mon avis, l'effort perdu doit vraiment être particulièrement considéré ici, il n'est pas comme les autres.
Pour info, utilisez-vous -- en tant que concepteurs de ce mapping -- cela de manière quotidienne et cela ne vous a jamais posé de problème? Et surtout y a-t-il des développeurs et des utilisateurs intensifs de consoles/shells parmi vous?
Merci.
Jehan
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Diverses questions
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Sortie du bépo 1.0rc1. Évalué à 2.
oui merci beaucoup pour les réponses. Ca répond plutôt bien à tout. Je rebondirai uniquement sur un seul point: l'espace insécable, qui est le seul qui me pose encore problème. Et je me rends compte en parcourant le reste du journal que je ne suis pas le seul. Pour ma part, je précise à nouveau que c'est en plus vraiment par expérience personnelle que je dis cela, puisque j'ai eu exactement cette même idée en me disant dans un premier temps que c'était vraiment une bonne idée d'avoir accès à l'espace insécable par maj-espace. En réalité perso, je ne m'embête pas vraiment avec ce caractère. Mais par exemple dans les équipes de trads de certains logiciels, ils nous demandaient de les mettre pour bien respecter la typographie française. Mais au bout d'un mois de souffrance avec cet espace insécable ainsi mappé, je l'ai jarté.
Le classique par exemple: rajouter un espace insécable après un point final (alors qu'il n'en faut pas) quand le doigt ne s'est pas relevé assez vite de maj. Dans le bépo, ce n'est plus un problème puisque le point est en accès direct, par contre le problème se pose toujours (ou nouvellement) avec ':', ';', '?' et '!'. Donc certes "avant" ces ponctuations, il faut un espace insécable (et là votre mapping réduit les efforts), mais pas après (et là ça crée des efforts supplémentaires pour supprimer, mais surtout pour se rendre compte qu'il y a un blem). Et la plupart du temps, on ne se rendra pas compte qu'on l'a rajouté.
Déjà donc ça pose problème pour la mise en page. Mais ce n'est pas mon vrai problème ni la raison pour laquelle j'ai arrêté d'utitliser ce mapping (je n'ai pas souvent l'occasion d'avoir à faire du formattage de texte de grande qualité, en plus dans beaucoup de cas, l'erreur peut ne même pas gêner la mise en page). Ce sera plus pour les traitements automatiques en réalité que ça m'a posé problème.
En effet le problème est que l'espace insécable est peut-être nécessaire typographiquement par endroit, mais ce n'est pas pour autant qu'il est accepté logiciellement là où l'espace l'est (puisque le caractère réel est différent). Par exemple, si je rentre un numéro de tél dans un site en mettant des espaces insécables, je suis sûr que certains sites diront "seuls les chiffres et les espaces sont acceptés dans ce champs".
Mais ce n'est toujours pas le pire! Là où j'ai vraiment beaucoup souffert, c'est déjà en développement. Quand un code ne compile pas bêtement parce que deux mots sont séparés par erreur d'un espace insécable et donc sont considérés comme une unique entité par le compilo qui se plaint. Ensuite va comprendre et trouver l'erreur (avant "l'habitude", il m'a fallu un temps de compréhension; et même après habitude, ça reste lourd puisqu'on s'en rend toujours compte après coup, au moment de la compilation, donc c'est particulièrement chiant).
Très classique aussi: l'ajout involontaire dans les commandes bash (même mécanisme que du code, sauf que là c'est encore plus courant puisque je suis constamment dans une console même en utilisation normale). Entre la commande et les paramètres par ex (donc bash considérant ma commande+paramètre1 comme un seul mot et me disait qu'il trouvait pas cette commande), ou bien entre 2 paramètres, etc.
Cela pouvait m'arriver après un '/' par ex, mais en bépp, ça pourrait arriver plutôt après un ';' (très courant en bash), ou un ':' (j'utilise beaucoup ssh/scp), et tout simplement en mettant des suites de chiffres en paramètres, etc.
Et même tout bêtement comme j'utilise un terminal multi-onglet avec maj-droit/gauche pour m'y déplacer, il m'arrivait de commencer une commande, puis de changer d'onglet pour vérifier qqch, puis de revenir et de continuer ma commande si vite que le doigt était encore sur maj quand je tapais espace (ou bien parce que je prévoyais de taper un caractère nécessitant maj juste après l'espace, donc je laissais le doigt sur maj sans y penser).
Enfin voilà. C'est peut-être à retester. Peut-être y a-t-il habitude à prendre, etc. Néanmoins l'espace insécable a vraiment ceci de particulier par rapport à tout le reste qu'il est invisible (ou plutôt indicernable de l'espace simple), donc qu'une erreur avec ce caractère est si fourbe qu'elle peut causer bien des soucis, des arrachages de cheveux et des pertes de temps. Donc en conclusion beaucoup d'effort perdu pour un effort gagné bien plus faible (selon moi). A mon avis, l'effort perdu doit vraiment être particulièrement considéré ici, il n'est pas comme les autres.
Pour info, utilisez-vous -- en tant que concepteurs de ce mapping -- cela de manière quotidienne et cela ne vous a jamais posé de problème? Et surtout y a-t-il des développeurs et des utilisateurs intensifs de consoles/shells parmi vous?
Merci.
Jehan
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]