Peut-être que c'est moi qui ai raté un truc dans l'idée d'élasticité. Voici deux extraits de l'article de Nick Gavgaard.
For as long as we continue to define each tabstop as being a multiple of N characters we will never be able to solve this problem satisfactorily.
... Rather than saying that a tab character places the text that follows it at the next Nth column, we should say that a tab character is a delimiter between table cells in a manner more reminiscent of how they're used in tab separated value (TSV) files.
D'après ma comprenette, l'idée est que la touche TAB n'est plus équivalente à un multiple donné d'espaces à placer absolument dès qu'on l'invoque. Elle s'adapte suivant le contexte environnant. Sous cette lumière, revisitons la ligne 10 :
l'espace engendré par le premier TAB après « ; » est clairement plus petit que celui se trouvant avant « x(); », ce dernier respectant la spécification « indent-width=8 » dans l'en-tête du fichier ;
l'espace résultant des trois TAB suivant est conforme à la longueur fixe spécifiée ;
le dernier espace, juste avant « */ » est minuscule.
Tous ces ajustements étant faits pour s'adapter aux autres commentaires dans les lignes 11 et 12. D'après ma compréhension du concept donc, ceci est un parfait exemple d'un TAB qui se comporte comme si c'était « un marqueur de cellules à la manière d'un tableur », pour paraphraser Nick Gavgaard.
Maintenant, comme tu le fais fort bien remarquer, dans ma session neovim par exemple, j'aurai le même comportement, à une différence près : ce n'est pas le comportement par défaut et ça dépend de comment les TAB sont configurés. Dans Kate, le truc y est compilé par défaut mais reste configurable ; l'en-tête « dynamic-word-wrap » que j'ai placée dans l'exemple était redondante avec la valeur par défaut. De ce poit de vue, les développeurs de Kate ont changé la « sémantique »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 gipoisson . En réponse au journal Fins de tabulation élastiques: la bonne manière d'indenter et d'aligner le code. É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. ↩