Il y a des débats sans fin sur l'usage de tabulations ou d'espaces pour indenter et aligner son code. Chaque approche a ses avantages et des inconvénients, ses fidèles et ses ennemis.
(Indenter, c'est mettre de l'espace au début des lignes pour montrer visuellement les relations d'emboîtement logique des différentes lignes de code. Aligner, c'est mettre de l'espace avant un morceau de texte, pas forcément en début de ligne, pour créer un lien visuel entre plusieurs morceaux sur des lignes voisines qui est logiquement lié.)
L'approche des "fins de tabulations élastiques" (elastic tabstops) est clairement la meilleure solution à ce problème—j'explique en quoi elle consiste ci-dessous, je vous laisse vous convaincre que c'est la solution ultime. Elle a un seul défaut : elle n'est pas utilisable en pratique parce qu'elle n'est pas disponible dans les éditeurs que nous utilisons. C'est un défaut qui ne peut se régler qu'en communicant à son sujet pour que plus de gens y pensent et l'adopte, pour créer un environnement où elle est utilisable.
Qui, Quand
Les tabulations élastiques ont été inventées en 2006 par Nick Gavgaard, et le document explicatif de référence (en anglais) est son site web, http://nickgravgaard.com/elastic-tabstops/.
Il y recense aussi des plugins pour quelques éditeurs de texte (il maintient un plugin pour Visual Studio), mais les éditeurs libres sont assez mal lotis (Nick Gavgaard a écrit un plugin Gedit, mais il n'est pas maintenu et plus compatible avec des changements d'API). Il y a par contre des bibliothèques de formatage de texte qui ont adopté ce concept, par exemple le paquet tabwriter de la bibliothèque standard Go.
Quoi
La "fin de tabulation", c'est l'endroit où un éditeur de texte va mettre le curseur après l'usage d'un caractère de tabulation.
La façon standard de calculer, c'est qu'il met le curseur à la colonne dont le numéro prochain multiple de N, la "largeur de tabs" choisie par l'utilisateur. Typiquement N=8, donc si on n'a rien écrit et qu'on appuie sur tab on se retrouve à la colonne 8, et si on écrit un mot de 4 lettres (donc on est en 12) et qu'on ré-appuie sur tab, on se retrouve à la colonne 16.
012345678901234567890123456789
\t foo\t bar
\t foo2\t baz
\t long word\t rest
Ça permet d'aligner facilement des fragments de texte… tant qu'ils font moins de 8 caractères. Mais dès qu'on dépasse 8 caractères, ou dès qu'on commence un peu trop près du prochain multiple de 8, c'est la galère. En pratique les gens s'entendent pour dire que si on veut utiliser des tabulations, il ne faut les utiliser qu'en début de la ligne (pour indenter), car en milieu de ligne c'est trop imprévisible, et aligner avec des espaces. Mais aligner, c'est joli et souvent utile, et avec des espaces c'est galère—sauf si notre éditeur a un mode spécial pour cela.
L'idée des "fins de tabulation élastique", c'est qu'au lieu de fixer pour chaque ligne la position des fins de tabulation, on les positionne en fonction des lignes adjacentes pour préserver l'alignement. Concrètement, si deux lignes sont adjacentes, on regarde combien de tabulation elles ont en commun (elles n'ont pas forcément le même nombre de tabulations), et on demande à ce que ces tabulations communes, comptées à partir du début de la ligne, soit alignées verticalement. Enfin, on demande une largeur minimale de blanc (choisie par l'éditeur ou l'afficheur de texte) pour chaque tabulation. Dans l'exemple précédent, si on demande une largeur minimale de 4 (par exemple), et qu'on écrit le texte ligne par ligne, on a d'abord
012345678901234567890123456789
\t foo\t bar
puis on ajoute la deuxième ligne; la deuxième tabulation finit un peu plus loin (pour respecter la largeur minimale), donc la deuxième tabulation de la première ligne se décale aussi
012345678901234567890123456789
\t foo\t bar
\t foo2\t baz
pareil, quand on ajoute la troisième, les fins de tabulations des deux premières lignes se décalent de façon élastique:
012345678901234567890123456789
\t foo\t bar
\t foo2\t baz
\t long word\t rest
Pour la même chose en plus clair et plus joli, Nick Gravgaard a fait des animations plus visuelles:
# Bientôt dans Vim ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10.
C'est une fonctionnalité que j'aimerais bien avoir depuis longtemps. Suite à ton journal j'ai fait une rapide recherche, et je tombe sur ça :
https://vi.stackexchange.com/a/16856
Apparemment, depuis Vim 8.1.105 il y a une nouvelle option de compilation (
+vartabs) qui permet l'implémentation de cette fonctionnalité, à suivre donc.# Automatiser l'indentation
Posté par kp . Évalué à 5.
Pour moi, la bonne façon d'indenter du code, c'est d'utiliser un outil pour ça et de l'imposer. clang-format est très bien pour ça (mais ce n'est pas le seul). C'est assez facile de forcer ça dans une intégration continue.
L'avantage, c'est qu'une fois que c'est en place, on peut oublier toutes ces questions d'indentation.
[^] # Re: Automatiser l'indentation
Posté par gasche . Évalué à 6.
Un outil d'alignement comme post-processing comme clang-format n'est pas aussi pratique qu'un support natif dans les éditeurs et rendus de texte :
# Rarement utile
Posté par Colin Pitrat (site web personnel) . Évalué à 6.
Les seuls cas où ça me paraît utile, c'est quand on a un tableau de structures (au sens large: struct, sous-tableaux …) à initialiser. Pour la majeure partie du code, une indentation automatique (clang-indent, go fix, …) est le mieux pour éviter incohérences et perte de temps.
# aligner tabuler
Posté par Lutin . Évalué à 5.
En alignant avec des espaces et en indentant avec des tabulations on n'a pas besoin de ce genre d'outillage.
Et il n'y a pas que l'éditeur de texte qui est concerné, il faudrait aussi adapter les tail, head et autres cat.
[^] # Re: aligner tabuler
Posté par gasche . Évalué à 5.
… sauf qu'aligner avec des espaces est très chiant sans support spécifique de l'éditeur. Là l'idée c'est de donner une meilleure sémantique à un caractère qui existe, et donc d'avoir un espoir à terme d'un comportement standard, portable, et pas de devoir trouver la commande / le raccourci différent chez chacun.
Tu veux dire adapter le terminal ? Parce que ces commandes ne dépendent pas de la sémantique d'affichage des tabs.
[^] # Re: aligner tabuler
Posté par gouttegd . Évalué à 4. Dernière modification le 29 juillet 2018 à 17:27.
Sachant qu’en quarante ans les différents OS n’ont pas été fichus de se mettre d’accord sur le(s) caractère(s) à utiliser pour représenter une fin de ligne, j’ai beaucoup de doutes sur la possibilité de voir cette proposition devenir un « standard » (officiel ou de facto)…
Et de tous les innombrables débats sur l’indentation et l’usage des tabulations (grand sujet de bikeshedding s’il en est), j’ai pour ma part retenu une règle absolue : quel que soit votre style d’indentation, ne changez jamais la signification du caractère \t.
Autrement dit, si vous choisissez d’indenter sur 4 colonnes au lieu de 8, utilisez 4 espaces au lieu de configurer votre éditeur pour changer la valeur du tab stop de 8 à 4.
La solution proposée ici viole cette règle et conduira donc à un affichage du code variable selon l’éditeur utilisé (selon qu’il possède cette fonctionnalité ou non, selon qu’elle soit implémentée de la même manière que dans l’éditeur d’origine, et selon que les réglages — nombre de lignes considérées pour décider de l’alignement par exemple — soient les mêmes). J’ai beaucoup de mal à voir ça comme une bonne idée.
[^] # Re: aligner tabuler
Posté par Thomas Debesse (site web personnel) . Évalué à 8. Dernière modification le 29 juillet 2018 à 18:08.
Depuis quand « remplacer 1 caractère
\tpar 4 caractères» ne change pas la signification du caractère\t? Il est carrément supprimé et donc la signification de ce caractère est retirée du document ! Au lieu de supprimer la fièvre on casse le thermomètre !Une tabulation c’est une tabulation, pas « un caractère large de 8 espace dans une police mono ». C’est comme ça que je suis déjà arrivé devant du code indenté à 4 caractères où les indentations de second niveau (à 8 caractères) étaient indentés avec des tabulations, en gros :
Et ça c’est entièrement compatible avec ce que tu dis.
La tabulation n’est pas un caractère de substitution pour des longues chaînes d’espace, elle a un autre sens.
C’est d’ailleurs pourquoi il est dommage de voir tant de projets (et même des standards) utiliser des espaces pour indenter le code alors qu’il y a à disposition un caractère avec une sémantique différente de l’espace !
La sémantique est importante ! C’est utile d’avoir une sémantique différente entre ces deux espaces :
Le premier peut être supprimé par le préprocesseur/minifieur, pas le second, et ce sans aucune forme d’analyse syntaxique.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: aligner tabuler
Posté par gouttegd . Évalué à 1.
Ben oui, précisément. Si on veut indenter sur quatre colonnes (ou deux, ou trois, ou ce qu’on veut), au lieu de continuer à utiliser un caractère \t en décrétant qu’il vaut 4 espaces de large, on le remplace par quatre espaces.
(Ce qui n’empêche pas de continuer à utiliser la touche Tabulation si on veut pour indenter, tous les éditeurs de texte dignes de ce nom permettant de changer la signification de cette touche — la touche, pas le caractère ! — pour signifier « indente d’un niveau » au lieu de « insère un caractère \t ».)
[^] # Re: aligner tabuler
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
Je crois que t’es passé à côté de l’essentiel : changer la largeur de la tabulation ne change pas sa signification : être un caractère de positionnement, pas être un séparateur de mot.
La tabulation n’a pas pour signification « espace de la taille de N espace ». La touche « tabulation » est une touche pour écrire le caractère de positionnement appelé « tabulation ». La touche tabulation n’est pas non-plus une touche raccourci pour taper 8 espaces. Ce genre de touche existe, il est courant par exemple d’avoir des pavés numériques avec une touche [00] pour taper deux zéros d’un coup (pratique pour les centimes) mais personne n’a encore pensé à mettre une touche [8 caractères] et la touche tabulation ça n’est pas ça du tout.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: aligner tabuler
Posté par plusdespace . Évalué à 10.
N'importe quoi il y a une touche pour insérer exactement 6 espaces sur tous les claviers!
(mais bon, c'est logitech, ça marche une fois sur six)
[^] # Re: aligner tabuler
Posté par barmic . Évalué à 5.
C'est très bizarre comme principe. Si tu utilise des tabulation c'est justement pour pouvoir changer sa taille. C'est le principe de ce caractère et il est tout à fait possible de coder et que ça reste lisible quelque soit la taille de ta tabulation et c'est tant mieux parce que 8 c'est énorme et qu'avec make tu n'a pas vraiment le choix.
[^] # Re: aligner tabuler
Posté par gouttegd . Évalué à 3. Dernière modification le 29 juillet 2018 à 20:42.
Ben oui, c’est justement ça le problème. Si tu indentes ton code à coup de tabulation en partant du principe que, chez toi, 1 tab = 4 espaces (parce que c’est comme ça que tu as réglé ton éditeur), le formatage de ton code ne ressemblera plus à rien quand il sera ouvert dans un éditeur réglé différemment. A fortiori si ton style d’indentation implique de mélanger tabs et espaces, ce qui est semble-t-il assez fréquent (en tout cas j’ai vu ça assez souvent pour m’en tenir désormais au principe énoncé plus haut).
[^] # Re: aligner tabuler
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
Ça s’appelle de l’accessibilité. Le code ce n’est pas de l’ascii art. Quand t’as besoin de faire de l’ascii art OK, c’est pour ça que beaucoup de monde (et moi le premier) recommande les tabulations en début de ligne et les espaces après car c’est juste une autre manière de dire « les tabulations pour indenter et les espaces pour dessiner ».
Mince quoi, ce caractère a été inventé exprès pour être souple et s’adapter à la mise en forme du rendu. C’est d’ailleurs pour cela que les traitements de textes permettent en un glissé de changer la largeur de l’indentation, d’ailleurs le symbole utilisé dans Word ou Libroffice Writer est celui qui était sur les machines à écrire parce que oui ça date de la machine à écrire. Même sur une machine à écrire la largeur de la tabulation était modifiable par celui qui écrivait. La tabulation est une information, la largeur de la tabulation c’est un style !
Indenter son code avec des espaces c’est comme faire des titres dans Word en sélectionnant le texte et en cliquant sur « gras ». La sémantique c’est important !
Ça s’appelle de l’accessibilité, ou comme on le dit pour se faire mousser, c’est responsive.
Et puisque la tabulation a une valeur sémantique on pourrait même demander aux éditeurs de code d’aligner les césures selon la tabulation ! Je rêve éveillé !
Mais non, à la place on demande aux gens de faire du ASCII art au lieu de se focaliser sur leur code (merci PEP8). Et pour obtenir un alignement des césure de ligne trop longue il faudrait demander à l’éditeur de code de parser le langage (et de connaître tous les langages) parce qu’on a supprimé la sémantique !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: aligner tabuler
Posté par gorbal . Évalué à 7.
C'est bien gentil mais dans la vraie vie, quand une dizaine de personnes travaillent sur le même code avec des éditeurs différent, il n'est pas rare que chacun reformate l'indentation pour rendre le code plus "lisible".
Conséquences:
- Faire un diff sur le code devient très pénible, car les outils de reformatage automatiques des éditeurs vont modifier toutes les lignes, donc pour retrouver le code qui a réellement été modifié …
- 30% des "merges conflicts" proviennent juste de l'ajout ou le remplacement d'un espace par une tabulation et vice-versa.
Donc maintenant notre règle c'est zéro tabulation
[^] # Re: aligner tabuler
Posté par Dr BG . Évalué à 10.
Euh non, si tout le monde utilise une tabulation pour une profondeur d'indentation, je ne vois pas où peut être le problème. Les soucis arrivent quand les gens utilisent aussi des espaces pour indeter.
[^] # Re: aligner tabuler
Posté par dyno partouzeur du centre . Évalué à 2.
Non, les problèmes arrivent quand on mélange tabulations et espaces. D'ailleurs t'as qu'à essayer en python, tu vas bien t'amuser.
[^] # Re: aligner tabuler
Posté par Dr BG . Évalué à 6.
C'est ce que j'ai dit : « Les soucis arrivent quand les gens utilisent aussi des espaces » et pas « Les soucis arrivent aussi quand les gens utilisent des espaces ».
Pour ce qui est de Python, c'est un cas exceptionnel où l'indentation fait partie de la sémantique du langage, mais ce n'est pas le cas en général.
[^] # Re: aligner tabuler
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
Parce qu’au lieu de configurer la largeur de la tabulation comme sur la machine à écrire de grand-mère, ils font de l’ASCII art !
S’ils utilisaient la tabulation ils n’auraient à changer le style dans leur éditeur selon leur critère de lisibilité ! Ça s’appelle précisément « séparation du contenu et de l’apparence ». La largeur d’une tabulation c’est une propriété qui appartient à une feuille de style. Cette largeur peut varier selon les personnes et les usages, code en cours d’édition, code imprimé, un handicap personnel… Tout ça c’est du style !
C’est vraiment exactement le même problème que la secrétaire qui fait ses titres en mettant du gras sur du texte et qui a la fin tire la langue pour faire une table des matières à la main, et qui râle quand elle doit renuméroter sa table des matières dès qu’elle ajoute une page au milieu de son document !
Oh punaise ! Le problème était déjà résolu avant l’avènement de la micro informatique et les gens ils continuent à faire des documents alignés avec des espaces ! Misère ! On a encore combien de décennies à tirer ?
Vous vous rendez-compte que tous ces ingénieurs ils n’ont même pas les bases du traitement de texte ? Le truc de base où on t’apprend la différence entre sémantique et mise en forme ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: aligner tabuler
Posté par Faya . Évalué à 9.
M'en fous. Mon salaire en dépend \s
Je précise pour les esprits chagrins qui vont hurler avant même d'avoir lu, l'auteur sait qu'il y a sûrement un (des) biais et il fournit même les données brutes pour qui veut :
[^] # Re: aligner tabuler
Posté par Lutin . Évalué à 5.
La le soucis ce sont les gens qui ne savent pas utiliser leur gestionnaire de sources. On ne tape pas "git commit -a" dans toutes les situations.
[^] # Re: aligner tabuler
Posté par barmic . Évalué à 2.
Tu confond avec l'absence de règles de codage.
[^] # Re: aligner tabuler
Posté par gouttegd . Évalué à 7.
Sauf qu’à part dans du code Python ou dans un Makefile, dans la quasi-totalité des cas l’indentation n’a pas de sémantique.
C’est en pensant que l’indentation veut dire quelque chose qu’on en arrive à ce que quelqu’un écrive du code comme ça :
… et que le bug passe inaperçu (mais à part ça pas de problème, le code est bien indenté avec des tabulations, l’intention du développeur est bien exprimée… ou pas).
[^] # Re: aligner tabuler
Posté par gasche . Évalué à 4.
Je me demande un peu où va ton argument là… si on arrêtait d'indenter le code, on aurait plus de bugs à cause du fait qu'on ne comprend pas sa structure, pas moins.
[^] # Re: aligner tabuler
Posté par gouttegd . Évalué à 9.
Nulle part je ne propose de ne plus indenter… Je voulais seulement faire remarquer que l’indentation n’a pas de signification particulière dans la plupart des langages (Python et Make étant les deux seules exceptions que je connaisse). Partant de là, je ne comprends qu’on puisse faire un caca nerveux sur le fait que c’est horrible de ne pas respecter la soi-disant sémantique d’un caractère que quasiment tous les langages traitent de la même façon qu’un espace.
Pour la lisibilité du code, c’est l’indentation proprement dite qui est importante, pas la manière de marquer l’indentation. Pour ma part j’ai choisi une manière qui fait que l’indentation ne dépendra pas d’un réglage d’affichage de l’éditeur.
[^] # Re: aligner tabuler
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
C’est ce que je développe dans mon autre commentaire, mais il n’y a pas que le compilateur/interpréteur qui traite le code : il y a le codeur (la personne elle-même), l’éditeur (vim…), l’éventuel outil de documentation (doxygen…). Il y a plein de trucs dans le document source qui se destinent à l’un ou l’autre.
C’est facile de détourner la conversation, mais ça n’est qu’une fuite.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: aligner tabuler
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
Tu ignores (volontairement ?) de répondre précisément à ce qui suit immédiatement mon affirmation « la sémantique c’est important ».
Je le remets :
C’est un peu comme les commentaires de documentation, ça n’a aucun sens pour le code exécuté, mais ça un un sens pour la documentation.
De même, la tabulation dans l’exemple ci-dessus n’a aucun sens pour le code exécuté, mais elle a du sens pour l’éditeur, et il pourrait avoir du sens pour un préprocesseur.
Le rôle du compilateur c’est de transformer ton code. Le rôle de l’éditeur est d’afficher le code et permettre sa saisie. Dans mon exemple la sémantique de la tabulation ne concerne que l’éditeur, et c’est très bien comme ça. D’ailleurs l’indentation elle-même n’a pas de sens pour le compilateur ou l’interpréteur dans la majorité des cas comme tu l’as précisé, si on le fait quand même c’est bien que ça sert à autre chose qu’au compilateur ou interpréteur. C’est pour une raison similaire qu’on demande d’écrire des noms de fonctions et des noms de variables « qui ont du sens », pourtant le compilateur ou l’interpréteur n’en a rien à carrer.
Je n’ai jamais parlé dans ce fil de discussion de la sémantique de la tabulation sur le plan fonctionnel (ce qui sera exécuté par le code). Ce que tu fais là est un homme de paille et tu dois savoir que si c’est intentionnel c’est malhonnête.
Je parle de sémantique de la tabulation pour l’éditeur qui fait le rendu de ton code.
Il est par exemple pratique de faire ceci :
Même python avec ses indentations qui ont un sens fonctionnel n’en a rien à cirer de cette indentation-là, mais cette indentation a du sens pour le codeur et elle peut avoir du sens pour l’éditeur. De même la dernière virgule n’a aucun sens fonctionnel mais elle a un sens pour l’outil de diff qui peut voir chacune des lignes clé-valeurs comme un ensemble qui peut se traiter indépendamment des autres lignes et grandement faciliter les fusions.
On n’est pas des machines, il y a plusieurs niveaux de sémantique et pas seulement celui du compilateur/interpréteur. Le meilleur exemple étant le commentaire de code, complètement inutile sur le plan fonctionnel mais tellement utile que l’éditeur a une règle de style spécifique pour cela.
C’est très précieux d’avoir un caractère dédié à l’indentation, ça évite de devoir faire de la divination pour appliquer le style, parce que contrairement au commentaire n’y a pas de balise autour de l’indentation ! Sans le caractère tabulation les développeurs de moteur de rendu de code doivent traiter les espaces comme s’ils parsaient du whitespace ! C’est du masochisme !
C’est aussi parce qu’on refuse de considérer la sémantique sur ce plan-là qu’on n’a toujours pas de moteur de rendu de code potable après tant d’année et malgré toutes les supers choses dont on rêverait comme celle présentée dans ce journal ! On a des moteurs CSS de la mort qui tue sur le web mais pour faire le rendu de code on continue de demander aux codeurs de faire la mise en page à la main avec des espaces !
Perso j’aime bien coder avec une fonte mono, mais je me rends bien compte que c’est surtout une contrainte qu’on se donne et qu’on donne à tout le monde pour se permettre d’être compatible avec les cro-magnons qui sont resté à la mise en forme à base d’espace !
C’est incroyable qu’on soit resté à la mise en forme à base d’espace après tant de décennies, et ce qui est incroyable c’est que ce soit le domaine le plus à la pointe qui en soit resté là. Mais même les fontes mono que j’affectionne bien montrent leur limites, parce que dans le code on met aussi du vrai texte, ne serait-ce qu’entre deux guillemets d’un
printfet que l’espace fine insécable ou l’émoji ou l’idéogramme et bien ils bouleversent un peu tout ça.ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: aligner tabuler
Posté par gouttegd . Évalué à 2.
Si je te suis bien, tu décides que le caractère tabulation sert à indenter exclusivement, et donc qu’un outil (autre que le compilateur, qui ne distingue pas ce caractère des autres caractères blancs) peut se permettre de les supprimer sans aucune analyse ?
Je pense que c’est une très mauvaise idée.
Imaginons que j’ai le code suivant :
et que je souhaite (ou que le style de code du projet impose) aligner les variables sur une même colonne :
Présentement, je fais ça… à coups d’espace, ce qui apparemment est mal, très mal (ce serait même une des causes de tous les maux de l’informatique moderne, tous ces développeurs qui perdent leur temps à faire de l’ASCII art au lieu d’utiliser les bons caractères pour la bonne tâche).
Heureusement, depuis ce journal, j’ai vu la lumière, je suis passé à un éditeur qui supporte les fins de tabulations élastiques, et désormais chaque fois que je veux aligner quelque chose (que ce soit des commentaires à droite du code ou des déclarations de variable), j’utilise une tabulation et une seule.
C’est formidable, tout va pour le mieux dans le meilleur des mondes.
Jusqu’à ce que mon code passe à la moulinette d’un outil écrit par quelqu’un qui a décidé que le sens du caractère tabulation, c’était d’indenter et non pas de séparer les noms de variable de leur type, et qui conséquemment se permet de supprimer toutes les tabulations sans faire aucune analyse syntaxique pour vérifier qu’il a bel et bien le droit de les supprimer. Et le compilateur derrière de se retrouver avec des
unsignedi,size_tlenetcharbuffer[4]dont il se demande bien que faire…La sémantique, c’est bien joli, mais si toi ou un de tes outils donne à des caractères une sémantique distincte de celle spécifiée par le langage et attendue par le compilateur, je pense que tu vas au devant d’ennuis.
Libre à toi de le regretter, mais le fait que dans beaucoup de langages une tabulation a la même signification qu’un espace ou même qu’une fin de ligne, c’est un séparateur de tokens et rien d’autre. Partant, je n’ai aucun scrupule à utiliser l’un ou l’autre (et donc, à utiliser par exemple des espaces pour indenter ou aligner), et je n’ai pas le sentiment de causer la perte de l’informatique. Que ça me fasse passer pour un cro-magnon à tes yeux est le dernier de mes soucis.
Sur ce, j’arrête là, il est évident que la discussion ne mènera nulle part et que ce garage à vélo n’est pas prêt d’être peint.
[^] # Re: aligner tabuler
Posté par barmic . Évalué à -3.
T'es génial. Tu commence par venir avec tes gros sabots expliquer ta règle intouchable et maintenant tu te pleins que d'autres sont comme toi mais pas avec les même idées.
Et maintenant tu t'enerve alors qu'en vrai, on s'en fou. Ton langage te donne une règle, tu l'applique, sinon tu en choisie une et tu la décrit comme une règle de ton projet. Ça marche et le monde ne s'arrête pas parce que tu va utiliser \t (de 4 ou de 8), des espaces ou bien un caractère que tu choisi dans les tables unicodes privées.
Faut arrêter de se prendre la tête pour ce genre de considération. Il y a largement plus important.
[^] # Re: aligner tabuler
Posté par gouttegd . Évalué à 5. Dernière modification le 30 juillet 2018 à 23:42.
OK, donc énoncer une opinion en prenant bien soin de la présenter comme une opinion personnelle (« j’ai pour ma part retenu une règle absolue », c’est « arriver avec des gros sabots avec une règle intouchable ». Je prends note.
Par contre celui qui s’offusque de cette opinion et qui en réponse affirme péremptoirement qu’une tabulation ça sert à indenter et pas à autre chose, parce que la sémantique c’est important !, lui ne fait sans doute qu’exprimer un point de vue tout relatif sans aucunement émettre de jugement sur ceux qui ne sont pas d’accord (« les cro-magnons qui sont resté à la mise en forme à base d’espace », c’est sans doute une formule de politesse).
Bien, bien.
Là-dessus je te donne entièrement raison, et je me serai bien gardé d’avoir l’outrecuidance de donner mon opinion qui ne concerne que moi si j’avais pu prévoir qu’elle susciterait une réaction pareille. Leçon apprise, désormais je m’en tiendrais à tout ce qui touche à GnuPG.
[^] # Re: aligner tabuler
Posté par barmic . Évalué à 4.
Ou juste respirer un bon coup et faire la part des choses. Le communication asynchrones en publish-subscribe te permet :
Ce qui est dit ici ne changera pas le cours de ta vie. Si quelqu'un a tort ça n'est pas grave, c'est même son droit. C'est l'été (dans l'hémisphère nord), il faut chaud. Aller se baigner (ou à minima prendre une douche) est bien plus pertinent que tout ce qui peut être dis ici. Faut remettre les choses dans leur contexte et arrêter de dramatiser tout et n'importe quoi.
Ce message te répond car tu as l'air particulièrement affecté, mais il concerne aussi bien les malins qui vocifèrent plus haut. Quand on en vient à faire s'autoexclure quelqu'un parce que les tabulations ne sont pas de la bonne taille, je pense qu'il peut être intéressant de se poser la question du sens de ce que l'on est entrain de faire.
[^] # Re: aligner tabuler
Posté par Aluminium95 . Évalué à 3.
J'arrive un peu tard dans cette conversation mais je ne comprends pas ton argument du tout … Pourrais-tu le développer s'il te plaît ?
De ce que j'ai compris, le journal ne parle que de l'affichage d'une tabulation… Donc ça ne change strictement rien aux autre outils qui lisent le texte non ? Un peu comme le CSS qui est interprété légèrement différemment selon les navigateurs (padding/margin/border dans mon souvenir).
D'ailleurs, quelle est la sémantique d'un caractère unicode dans un éditeur de texte ? Autant le côté "visualisation" je comprends, on peut "visualiser" n'importe quelle suite de bits avec de l'ASCII*, mais la "sémantique" dont tu sembles parler c'est plutôt "comment dois-je travailler avec ce caractère spécial", chose qui semble être du ressort de tout sauf d'un éditeur.
Par la suite, tu expliques que les caractères de séparation de token (tabulation, fin de ligne, espaces) sont tous traités de manière identique par les programmes d'analyse lexicale/syntaxique dans les compilateurs/minifiers … Et donc je ne vois pas la différence entre
int\scoucouetint\tcoucouà ce niveau …J'ai certainement loupé quelque chose, mais je n'arrive pas à trouver quoi !
*On a choisi une sémantique d'affichage pour chaque octet
[^] # Re: aligner tabuler
Posté par Thomas Debesse (site web personnel) . Évalué à 1.
Je ne dis pas que les compilateurs existants de langages existants devraient faire ça, mais qu’il est possible qu’un langage et un compilateur fasse ça puisqu’on constate la possibilité de coder une information (la fameuse « sémantique ») dans la diversité des caractères employés. Perso (mais c’est mon avis) je recommanderai de ne jamais coder une information fonctionnelle ainsi (sinon on fait du Whitespace) mais pour coder de la mise en forme ça va très bien et l’indentation c’est exactement ça. Encore une fois je ne parle de sémantique que pour l’éditeur pas pour le compilateur, quand je parle de compilateur c’est pour dire qu’il pourrait se dire « ah ça ce n’est pas pour moi¹ ».
________
¹ ce qui n’est pas du tout ce que fait Python justement.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: aligner tabuler
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Établir une convention pour travailler en équipe et transformer le document d’un autre sont deux choses vraiment différentes… D’autres ont relevé la confusion mais je remarque ce que ce n’est toujours pas si évident.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: aligner tabuler
Posté par robin . Évalué à 1.
C'est méga nul d'écrire ça comme ça, mais le seul moyen que ça s'affiche comme il faut c'est d'utiliser des espaces.
Et je ne parle même pas de
void foo()
{
if (bar()) {
myFunction(1,
2);
}
}
void baz(
char a,
char b)
{
if (bar()) {
myFunction(
1,
2);
}
}
baret demyFunction), y compris par les co-workers distraits !PS - mmm, on dirait que le formatage fait des truc bizarre.
bépo powered
[^] # Re: aligner tabuler
Posté par Anonyme . Évalué à 4.
En python ça se fait beaucoup, et personnellement, c'est quelque chose que j'aime bien faire, ça a l'avantage de laisser le bloc intenté plus visible en dessous quand la liste des arguments font dépasser la ligne de 79 caractères.
Ici on pourrait croire en regardant rapidement que les deux arguments font parti du scope de la fonction.
[^] # Re: aligner tabuler
Posté par Thomas Debesse (site web personnel) . Évalué à 2. Dernière modification le 31 juillet 2018 à 21:11.
C’est pratique aussi pour consulter un diff, si un élément est ajouté ou retranché c’est simplement une ligne en plus ou en moins.
Personnellement c’est pour moi la seule raison valable pour scinder des lignes longues. Les autres raisons c’est de l’ASCII art et ça amène les mêmes problèmes que ceux qui ralent dans les commentaires parce que les messages alignés à 80 colonnes dessinés ainsi :
s’affichent ainsi :
>_<
Le rendu de texte ça fait longtemps que l’humanité a appris à faire faire à la machine, pourquoi devrait-on encore placer les types à la main en 2018 ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: aligner tabuler
Posté par barmic . Évalué à 4.
Non tant que tu utilise une police monospace.
Tu place
fooa une tabulation et le paramètre b à une tabulation et 5 espaces (l'exemple est mouche mais ça illustre bien le propos). Que tu utilise une tabulation à 1, 4, 8 ou 11 caractères ça ne posera pas de problème.Quand tu fais ce genre de choses le nombre de tabulations décrit ton niveau d'indentation et les espaces servent uniquement à aligner. Comme l'alignement se fait par rapport à des caractères qui ont une taille fixe (hypothèse : on utilise du monospace et par définition on n'aligne pas par rapport à un niveau d'indentation mais par rapport à la gueule de la ligne précédente). Dans tout ça la taille de ta tabulation n'entre pas en jeu.
Ça fait bizarre de le changer. Ce qui fait qu'on peut être sortis du on lui le code dans une sortie autre que son éditeur, mais la forme du code ne sera pas cassé pour autant.
Après moi j'utilise des espaces parce que c'est ce qui est utilisé dans les équipes où je travaille (et que je me fou de ce détail). Mais je n'ai vu de problème que lorsque des tabulations étaient utilisé pour faire l'alignement et là oui ça ne marche pas. C'est logique.
Je n'ai pas utilisé de vraies tabulations dans mon exemple car je suis sur téléphone.
[^] # Re: aligner tabuler
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
Chaque langage devrait avoir un programme pour rendre joli. Et comme le monde a plusieurs points de vu sur ce qui est joli, il y a des règles de codage par projet.
Perso pour Perl, je prends la règle suivante :
perltidy -i=3 -ci=3 -pt=2 -icb -cti=3 -sbt=2 -bt=2 -bbt=2 -nsfs -bar -otr -olc -nolq -l=132 -vmll -msc=1 -iscl -nbbc -nola -st
Normalement, on fait cela avant de commiter ou via l'intégration continue…
[^] # Re: aligner tabuler
Posté par Psychofox (Mastodon) . Évalué à 9. Dernière modification le 29 juillet 2018 à 23:02.
Euh tu nous dis plus haut que les fins de tabulations élastiques ne sont en pratique pas utilisables car aucun éditeur ne les supporte et maintenant tu dis qu'aligner des espaces est chiant si c'est pas supporté…sauf qu'en pratique tous les éditeurs de codes décents supportent les alignement avec espaces. C'est déjà un point de plus par rapports aux fins de tabulations élastiques.
[^] # Re: aligner tabuler
Posté par gasche . Évalué à 4.
Euh, tous les éditeurs supportent l'indentation avec les espaces, mais pour les alignements avec des espaces tu as une source ? Parce que je connais assez peu d'éditeurs qui gèrent ça bien. (Emacs est passable avec l'édition rectangulaire.)
La différence c'est qu'un support dans l'éditeur des espaces pour l'alignement, ce sera toujours une macro, tu appuies sur un bouton et ça fait plein de trucs (rajoute et enlève des espaces aux lignes). Le support des tabs élastiques dans l'éditeur, ça ne change pas le buffer, c'est juste la bonne façon de le visualiser qui est utiliser. C'est beaucoup plus propre conceptuellement, et une solution plus robuste sur le long terme.
[^] # Re: aligner tabuler
Posté par barmic . Évalué à 1.
En quoi c'est un problème cette histoire de macro ? Ajouter CR+LF quand tu appuie sur entrée c'est douloureux ? De même pour les diacritiques ? Fait arrêter la mauvaise fois de temps en temps. Ton ordinateur fais toujours pleins de choses pour chaque événement qui lui arrive et c'est plutôt cool (c'est pour ça que c'est fait !).
L'option s'appelle smarttabs dans intellij qui le gère très bien.
[^] # Re: aligner tabuler
Posté par Dr BG . Évalué à 2.
Parce que le but est de ne pas toucher au code source pour changer visuellement l'apparence des tabulations.
[^] # Re: aligner tabuler
Posté par barmic . Évalué à 3.
Alors… Euh… Comment expliquer ?
Qui à dit qu'il ne fallait pas avoir de standard de code? Tu peux choisir ce que tu veux si tu ne le standardise pas au sein de ton projet ça va être la galère. Dans ton standard, il faut indiquer :
Si tu ne défini pas ça quelque soit l'outil tu va souffrir, si tu le fais quelque soit ce que tu va choisir ça va fonctionner.
[^] # Re: aligner tabuler
Posté par Dr BG . Évalué à 3. Dernière modification le 30 juillet 2018 à 11:17.
Personne, juste que l'affichage de la tabulation n'a rien à voir avec.
[^] # Re: aligner tabuler
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 30 juillet 2018 à 14:20.
Je suis sysadmin et pas developeur donc peut-être pas le meilleure spécialiste mais quand j'édite du code puppet avec vim + le plugin vim-puppet il indente et aligne automatiquement avec des espaces. Et ce genre de plugin est dispo pour à peu près tous les langages connus.
Je ne nie pas qu'une implémentation des tabs élastiques telles que tu les décris serait une bonne idée, je réfute juste ton arguement que l'alignement avec des espaces n'est pas possible actuellement car les éditeurs ne le supporte pas. Certe out of the box pas tous mais la plupart des éditeurs que je connaisse supportent des systèmes de plugins qui permettent de le faire en pratique.
# Ce serait pas mal, oui
Posté par anaseto . Évalué à 4.
Le seul défaut que je vois — mais on en a un similaire pour la coloration syntaxique —, c'est pour les gros fichiers, où comme pour la coloration syntaxique dans plein d'éditeurs, j'imagine que l'idée serait de ne regarder, lors du calcul, qu'une fenêtre d'une certaine hauteur et ne pas analyser tout le fichier. Du coup, on pourrait, dans le cas d'une liste très longue, se retrouver à avoir des longueurs de ligne qui changent au fur et à mesure que l'on se déplace dans l'éditeur. Ceci dit, c'est sans doute moins gênant que la coloration syntaxique qui part en vrille.
[^] # Re: Ce serait pas mal, oui
Posté par gasche . Évalué à 2.
Oui, d'ailleurs en fait un recalcul dynamique, en fonction de ce qui est montré dans la fenêtre d'affiche (en ne prenant pas en compte les zones hors-champ), me paraît pas mal du point de vue de l'utilisabilité, en tout cas tant que ton éditeur est assez proprement fait pour pouvoir changer les alignements avec une animation continue pour ne pas créer d'accrocs visuels.
# Et Python ? Et Emacs ?
Posté par Astaoth . Évalué à 6.
La vraie question avec ce système est : est-ce que ca sera compatible avec Python ? :p
Emacs a une gestion des tabulation s'approchant de ce système, mais en beaucoup plus simple, en fonction du mode. Pour l'édition de fichiers de conf, il aligne ses tabulations par rapport à la ligne précédente. En revanche, modifier les tabulations d'une ligne ne modifie pas celles des autres lignes. Je ne sais pas si il gère ca dans d'autres modes que ceux d'éditions de fichiers de conf.
Emacs le fait depuis 30 ans.
[^] # Re: Et Python ? Et Emacs ?
Posté par Anonyme . Évalué à 8.
Je pensais à la même chose, perso je fais du python, le langage interdit de mélanger tabulations et espaces dans le code, et la pep8 indique que la bonne pratique pour l'indentation du code est de faire avec des espaces et non pas avec des tabulations, car justement, l'affichage des tabulations est dépendant de la configuration de l'éditeur ou du visualiseur de fichier texte.
Perso, je pense que le \t devrait juste retourner dans les limbes de la tables ascii aux cotés de tout les autres caractères de contrôles dont on ne se sert plus aujourd'hui et qui sont les reliques des télétypes et autres cartes perforées, et que les espaces ça fait très très bien le taff tant qu'on code avec une font monospace (ce que font à priori tout les développeurs du monde).
C'est quoi le délire à utiliser les tabs pour indenter du code ?
[^] # Re: Et Python ? Et Emacs ?
Posté par Dr BG . Évalué à 8.
Que chacun puisse choisir le rendu visuel de l'indentation ? Certains trouvent que 2 espaces c'est bien suffisant, la majorité 4, et d'autres 8. Avec des tabulations, tu n'utilises qu'un seul caractère que chacun peut faire interpréter selon son goût dans son éditeur de texte préféré.
Dans l'absolu, je pense qu'un fichier source ne devrait pas représenter la mise en forme du code, il faudrait séparer celle du fichier de celle qui est présentée à l'utilisateur par l'intermédiaire de son éditeur. Je vois bien l'intérêt d'avoir du code dans un fichier texte simple, donc on peut imaginer un formatage fait par un outil pour l'enregistrement du fichier, mais que l'éditeur de texte n'en tienne pas compte et mette en forme le contenu présenté par l'utilisateur suivant ses préférences. Tout le monde serait content et chacun aurait le formatage de ses rêves.
[^] # Re: Et Python ? Et Emacs ?
Posté par Anonyme . Évalué à 2.
Sauf que dans les faits, ça ne marche pas, dès l'instant que tu dois indenter des structures par exemple, bah voilà c'est la merde.
Du coups un code dont la mise en forme fait parti intégrante de la syntaxe, comme à tout hasard python, t'en fait quoi ?
[^] # Re: Et Python ? Et Emacs ?
Posté par Dr BG . Évalué à 4.
Peux-tu donner un exemple, que je vois bien de quel genre de souci tu veux parler ?
Pour Python, c'est sûr que ce n'est pas adapté, mais c'est un peu une exception.
[^] # Re: Et Python ? Et Emacs ?
Posté par Anonyme . Évalué à 1.
C'est l'exception qui rend tout ce concept caduque, y'a pas de raison que la façon dont on formate son code ne fasse pas en soit parti du code. Tout ce qui est raconté ici est possible parce que la majorité des langages n'interprètent pas les espaces, qu'ils ont pour leur majorité choisie des caractères spécifiques pour définir les limites de chaque instructions et ont décidé de laisser aux développeurs de formater leur code comme bon lui semble, mais c'est un choix qui n'est pas plus légitime que celui qu'à fait python d'utiliser l'indentation pour définir des blocs (et c'est particulièrement ce qui m'a séduit dans ce langage, mais je conçois tout à fait que cela ne soit pas partager).
De plus, dans ce concept de tabulation élastique, on doit inférer son usage comme étant celui d'aligner les éléments par rapport à la ligne suivante ou précédente, ce qui n'est encore une fois pas plus légitime que tout les autres usages qu'on pourrait faire de \t.
Je te réfère au journal, c'est exactement ce que les tabs élastiques veulent pouvoir corriger.
[^] # Re: Et Python ? Et Emacs ?
Posté par Dr BG . Évalué à 2.
Je ne vois pas pourquoi. C'est juste l'exception qui implique d'appliquer un cas exceptionnel adapté.
Je pense que si. Les concepteurs de Python ont décidé du contraire, mais je ne vois pas en quoi ça devrait se généraliser pour l'écrasante majorité des autres.
Tu considères que les fins tabs élastiques ne le corrigent donc pas ?
[^] # Re: Et Python ? Et Emacs ?
Posté par Psychofox (Mastodon) . Évalué à 5.
Vous vous prenez la tête sur un truc qui est à priori assez hors-sujet. De ce que j'en comprends les fins tabulations élastiques n'apportent une différence notable que dans l'alignement et pas dans l'indentation. Python s'en tape de l'alignement, tout ce qu'il veut c'est que tu indentes soit avec des espaces, soit avec des tabs mais pas un mélange des deux. Et je crois que tout le monde est d'accord pour dire que mélanger les deux dans l'indentation est stupide, quelque soit le langage utilisé.
[^] # Re: Et Python ? Et Emacs ?
Posté par barmic . Évalué à 1.
Le fait que make force des tabulations as t'il empêcher python de pousser les espaces ?
[^] # Re: Et Python ? Et Emacs ?
Posté par Thomas Douillard . Évalué à 3.
d’autant plus qu’on peut pousser des espaces avec des tabulations. Et ça personne n’en parle.
[^] # Re: Et Python ? Et Emacs ?
Posté par Astaoth . Évalué à 3.
Ravi de voir que mon troll sur Python a bien pris !
Personnellement, je n'aime pas python parce que sa grammaire se base justement sur les marques de formatage du code. J'ai pas besoin d'un langage de ce genre pour avoir du code bien indenté, et j'aime bien justement pouvoir choisir la façon dont j'indente mes blocs. Questions de goûts et de couleurs quoi.
Maintenant, je doute qu'il existe un IDE adapté pour coder avec tout les langages du monde. Au contraire, le choix de l'IDE et des éventuels plugins installés se font plutôt en fonction du langage et de ses préférences personnelles. Donc pour les pythonneurs, rien n'impose l'utilisation de ces tabulations elastiques si c'est inutilisable avec ce langage ou que ca ne convient pas aux développeurs. C'est donc très loin de rendre ce concept caduque.
Emacs le fait depuis 30 ans.
[^] # Re: Et Python ? Et Emacs ?
Posté par barmic . Évalué à 3.
On s'en fou de python ? Tu va nous expliquer qu'en whitespace ça ne fonctionne pas ? Avoir des règles différentes par type de fichier c'est monnaie courante et heureusement parce que ça permet d'utiliser la pep8 pour python et continuer d'utiliser make… Pratique, non ?
# LaTeX
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Cela me fait penser à l'environnement tabular de LaTeX.
# Kate
Posté par gipoisson . Évalué à 5. Dernière modification le 29 juillet 2018 à 23:14.
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
Katepour le développement, doncKatec'est cool pour les elastic tabstops mais ce n'est guère « industriel ».[^] # Re: Kate
Posté par gipoisson . Évalué à 1.
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
[^] # Re: Kate
Posté par Bruno Michel (site web personnel) . Évalué à 6.
J'ai corrigé le commentaire. La syntaxe était bonne, par contre, il faut donner l'URL d'une image, pas celle d'une page HTML qui contient l'image.
[^] # Re: Kate
Posté par gouttegd . Évalué à 4.
Euh, je ne suis pas sûr que ce soit bien la même fonctionnalité que celle décrite dans le journal.
Dans ton exemple, tu as besoin de quatre tabulations après le
X();pour que le commentaire à la fin de la ligne soit aligné avec les commentaires des lignes suivantes.Avec des « tabulations élastiques » telles que décrites dans le journal, si j’ai bien compris, tu n’insères qu’un seul caractère tabulation chaque fois que tu as besoin d’aligner, et c’est l’éditeur qui ajuste automatiquement la taille de la tabulation en fonction des lignes avoisinantes.
D’ailleurs, il me semble que ce tu montres dans Kate est en fait le comportement standard des tabulations dans la plupart des éditeurs (aussi décrit dans le journal)… la tabulation n’insère pas un systématiquement un blanc de 8 colonnes de large, elle insère un blanc de la largeur adéquate pour aller jusqu’au prochain tab stop.
Ou alors il y a quelque chose que j’ai raté sur cette image ?
[^] # Re: Kate
Posté par gipoisson . Évalué à 1.
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.
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 :
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
neovimpar 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. DansKate, 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 deKateont changé la « sémantique »1 de TAB selon la manière dont Nick le voudrait.Ailleurs, j'ai remarqué que tu t'insurges contre l'idée d'une sémantique quelconque de TAB, soit. Aussi, Haskell est un autre langage où l'indentation a (optionnellement) de la sémantique. ↩
[^] # Re: Kate
Posté par Thomas Douillard . Évalué à 2.
Je crois que justement le but c’est d’être indépendant de tout paramètre « indent-width ». Si les lignes se suivent, le caractère tab veut dire « nouvelle colonne ». Si tu as
l’objectif c’est que virtuellement tu aies l’équivalent de 3 colonnes dans un tableur, avec le commentaire ligne 1 aligné avec le commentaire ligne 2, et la colonne du milieu (celle qui contient les lignes de codes) soit suffisamment grande pour afficher le tout sur une ligne (quoi qu’on soit même pas obligé du coup).
Après ça nécessite de comprendre aussi que deux tabs consécutifs en début de lignes placés après les deux lignes
signifient bien une indentation et pas que « code » doive être mis dans la troisième colonne (celle des commentaires).
[^] # Re: Kate
Posté par gipoisson . Évalué à 1.
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”.
[^] # Re: Kate
Posté par gipoisson . Évalué à 3.
Une image animée pour compléter :
[^] # Re: Kate
Posté par YBoy360 (site web personnel) . Évalué à 5.
c'est beau!
ça donne presque envie de commenter son code.
[^] # Re: Kate
Posté par raphj . Évalué à 3.
Il me semblait que c'était plus ou moins le comportement attendu des tabulations dans les éditeurs de code.
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 (et tout reste aligné à l'indentation de la ligne, ce qui est bien pratique). J'aime bien cette option (retour à la ligne dynamique en français).
[^] # Re: Kate
Posté par gipoisson . Évalué à 1.
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”.
[^] # Re: Kate
Posté par raphj . Évalué à 3.
D'après ce que je vois, Static word wrap (retour à la ligne statique) est une option qui fait que Kate ajoute des retours à la lignes quand on dépasse les 80 caractères (ou la limite configurée).
Sauf erreur, dynamic word wrap est bien la fonctionnalité que j'ai décrite dans mon commentaire précédente.
Il n'y a pas du tout de fonctionnalité de tabulations élastiques dans Kate à ma connaissance, tes captures vidéos montrent le comportement classique de n'importe quel éditeur.
[^] # Re: Kate
Posté par benoar . Évalué à 6. Dernière modification le 30 juillet 2018 à 15:32.
Heu… c'est exactement le comportement d'une tabulation normale. Rien d'étonnant là-dedans.
[^] # Re: Kate
Posté par oinkoink_daotter . Évalué à 4.
Je m'était suis dit qu'en continuant un peu on atteindrait le niveau fonctionnel de la tabulation dans Wor^WLibreOffice, mais je ne l'avais pas écrit, par timidité :-D.
[^] # Re: Kate
Posté par gipoisson . Évalué à 1.
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
Katepouvait 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,
Katene fait pas de traitement de texte.[^] # Tabulations
Posté par Arthur Accroc . Évalué à 3.
Dans tous les éditeurs (pas que Kate), une tabulation n’est pas huit espaces (ou quatre, ou ce qu’on a choisi), mais un saut à la prochaine colonne multiple de huit (ou quatre, ou autre). C’est le principe.
Bon, tant qu’on ne fait qu’indenter avec, ça revient au même (et encore, pas si on met des lignes en commentaire), mais c’est quand on s’en sert pour aligner du code que c’est un peu plus fin (tant qu’on n’enlève ou n’ajoute pas un peu trop de caractères et que ça cause un saut de tabulation — faute des fameuses « fin de tabulations élastiques »).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Kate
Posté par benoar . Évalué à 3.
Ce qui est exactement le fonctionnement d'une tab normale tel qu'implémenté dans tous les éditeurs depuis 30 ans. Ceci n'a rien à voir avec les tabulations élastiques, tu te méprends.
N'importe quel éditeur de texte qu'il soit « traitement de texte » ou pas a ce comportement que tu présente. Va vérifier. Encore une fois, rien à voir avec les tabulations élastiques, qui concernent le fait de faire de l'alignement de lignes adjacentes avec uniquement une seule tab (ce qui n'est pas le cas de ton exemple).
[^] # Re: Kate
Posté par Chuck #1 . Évalué à 4. Dernière modification le 30 juillet 2018 à 19:50.
L'option
dynamic-word-wrapde Kate ne correspond absolument pas aux tabulations élastiques. Cette option insère automatiquement un caractère de passage à la ligne (\n) de sorte qu'aucune ligne ne dépassewrap-words-atcaractères (cf. le manuel de Kate).Sur ta capture d'écran, on peut voir qu'il faut plusieurs tabulations sur la ligne 10 pour arriver au niveau des lignes 11 et 12. Avec des tabulations élastiques, une seule suffirait. Ici, les tabulations sont justes alignées sur un multiple de 8.
Cette signature est publiée sous licence WTFPL
[^] # Re: Kate
Posté par gipoisson . Évalué à 1.
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.
Euh, je ne clame pas que
Katemet 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 queKaterentre dans cette catégorie d'implémentation édulcorée.# Convaincu
Posté par Elephant (site web personnel) . Évalué à 4.
Ah ben là patron vous m’avez convaincu, c’est une bonne raison. Je vais travailler avec les fins de tabulation élastiques
[^] # Re: Convaincu
Posté par Chuck #1 . Évalué à 5.
Tu oublies de préciser que ce qui t'as convaincu, c'est que tu es trop mauvais.
Cette signature est publiée sous licence WTFPL
# smarttabs++
Posté par kna . Évalué à 5. Dernière modification le 31 juillet 2018 à 12:08.
Personnellement, ma prédilection va aux tabulations pour l'indendation, espaces pour l'alignement
Si j'ai bien compris, avec cette extension, lorsqu'on utilise une tabulation ailleurs qu'en début de ligne, l'éditeur de texte aligne automatiquement. C'est un peu comme l'extension smart-tabs mais en plus intelligent (il fait l'alignement automatiquement), mais il conserve le caractère tabulation dans le fichier.
Ce qui me gène dans cette approche, c'est qu'un éditeur de texte qui n'aura pas l'extension perdra l'alignement. Mais ça sera aussi le cas de cat, head, tail, grep ou de l'affichage dans git(lab|hub).
[^] # Re: smarttabs++
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 31 juillet 2018 à 13:24.
Pour les outils historiques en ligne de commande il existe un utilitaire nommé etst sous licence MIT qui va faire la conversion et renvoyer vers la sortie standard.
Bon c'est pas hyper commode dans le sens où ça oblige à ajouter un pipe mais c'est faisable. Après c'est sûr que tant que les forges, les clients IM et autres outils ne le supporteront pas ce ne sera pas hyper convainquant.
[^] # Re: smarttabs++
Posté par Cᴬᴾᵀ Samavor . Évalué à 0.
+1 pour les tabulations pour l’indentation et les espaces pour l'alignement
Mais je voit un autre avantage à ces fins de tabulation élastiques, c'est de standardiser ce que relève actuellement de l'arbitraire. Si la plupart des développeurs alignent sur le début du mot suivant ou n'alignent pas, certains préfèrent aligner sur la fin du mot, et ce qui était un choix personnel du développeur devient avec ces fins de tabulation élastiques une option de configuration de l'éditeur, comme la taille de l’indentation.
# Oulala. Ca me rappelle qqchose...
Posté par cmic2 . Évalué à 4.
Et dans Emacs, il ya plein de choix possibles…
https://www.emacswiki.org/emacs/TabsSpacesBoth
--
cmic (sysadmin à la retraite..)
# mot manquant
Posté par theojouedubanjo . Évalué à 1.
"pour montrer visuellement les relations d'emboîtement logique des différentes de code" : un (ou plusieurs) mots manque(nt) entre "différentes" et "de code", potentiellement "lignes"
[^] # Re: mot manquant
Posté par Benoît Sibaud (site web personnel) . Évalué à 3. Dernière modification le 11 août 2018 à 20:45.
Corrigé, merci.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.