Quels sont les inconvénients des taquets élastiques? [fermé]


83

Regardez ici: une guerre sainte typique entre onglets et espaces .

Maintenant, regardez ici: tabstops élastiques . Tous les problèmes ont été résolus et de nombreux nouveaux comportements très utiles ont été ajoutés.

taquets élastiques

Des tabstops élastiques sont-ils même mentionnés dans cette discussion tabs vs espaces? Pourquoi pas? Y at-il des inconvénients à l’idée d’éléments de tabulation élastiques si sérieux que personne ne les a jamais mis en œuvre dans un éditeur populaire?

EDIT : Je m'excuse d'avoir mis trop d'emphase sur "pourquoi ne sont-ils pas mentionnés". Ce n'était pas vraiment ce que je voulais. cette question est peut-être même hors sujet. Ce que je veux vraiment dire, c’est quels sont les plus gros inconvénients qui empêchent l’adoption plus large d’une idée évidemment bénéfique? (dans un monde idéal où tout le supporte déjà)

(Il s'avère qu'il existe déjà une demande sur Microsoft Connect pour une implémentation Visual Studio de tabstops élastiques , ainsi qu'une demande dans Eclipse . De plus, une question concerne les autres éditeurs qui implémentent des tabstops élastiques. )


4
Ce serait une excellente question pour ux.stackexchange.com
JonnyBoats

11
Ils ne sont jamais mentionnés dans la discussion "onglets versus espaces" car il n'y a pratiquement aucun moyen pour un programmeur actif d'utiliser ces éléments. Peut-être que si vous aviez une implémentation Eclipse, VS, gvim et emacs, cela pourrait changer.
Paul Tomblin

2
J'aime vraiment l'idée, mais c'est seulement quand vous vivez avec elle pendant environ un mois que vous savez vraiment quels sont les pièges. Comme tout, il y a des cas garantis où il fait des choses inattendues ...
Chris Burt-Brown Le

3
@ ChrisBurt-Brown C'est toujours un risque, oui. IntelliSense comporte également des pièges, tels que la substitution de texte lorsque vous ne le souhaitez pas. Dans l’ensemble, cependant, IntelliSense en C # a été une grosse victoire.
Roman Starkov

4
Je veux ça dans le bloc-notes ++ ... je le veux maintenant
Ben Brocka

Réponses:


32

Les guerres saintes sont subjectives

Les taquets élastiques de Nick sont un concept étonnant qui pourrait aider beaucoup de gens à s’entendre sur une solution viable, même si je doute fort que cette guerre sainte s’achèverait complètement: c’est aussi une question de goût et beaucoup de programmeurs ne voudront pas bouger. pouce de leur position sur cette question, même au prix d'un compromis. Ce serait donc une première raison.

Par exemple, de nombreuses personnes du côté des "espaces" ne l'aimeront toujours pas, car cela nécessite une logique supplémentaire dans votre logiciel pour un rendu correct (par exemple, la simple visualisation d'un jeu de modifications dans la vue Web de votre GDS).

Problèmes d'implémentation

Mais la raison la plus évidente est simplement son obstacle technique à l'entrée : il s'agit d'un concept fondamentalement différent de celui mis en œuvre depuis plusieurs années (voire des décennies) dans les IDE et les éditeurs de texte. Il faudrait en réécrire certaines pour traiter les lignes de manière assez différente, ce qui complique la tâche des systèmes plus anciens et plus grands, qui risquent davantage de subir un couplage étroit et profond dans leur code de traitement de ligne. Il est, cependant, beaucoup plus facile à faire lorsque vous commencez à partir de zéro (pensez à la démo de Nick ou de Go de tabwriter package).

Pour une anecdote personnelle, je me souviens d’avoir approché l’auteur il y a quelque temps pour lui demander s’il y avait un quelconque soutien à emacs, et dans ce cas particulier, il a mentionné cela comme la raison pour laquelle ce n’était pas anodin. Il a également demandé l'aide de la communauté pour aider à mettre en œuvre cette fonctionnalité et l'amener aux masses.

Est-ce que nous nous en soucions assez?

Une troisième raison est que certains développeurs ne sont pas si pressés par la question et ne se soucient pas vraiment de faire un effort supplémentaire pour soutenir leurs efforts. Dans la plupart des cas, le conflit espaces-vs-tabs n’est pas un bloqueur d’affaires. Il n’ya donc pas beaucoup de motivation derrière le problème.

Si vous le voulez, vous devrez vous battre pour cela. Ce qui est faisable dans un logiciel open-source. Et si vous en modifiez suffisamment, les sources fermées devront suivre au risque de perdre une partie de leur base d'utilisateurs, si infime soit-elle.

Alors, si tu le veux, donne un coup de main à Nick.


(hors sujet) Je me demande souvent comment d'autres types de fonctionnalités "c'est sympa mais très mineur" en font des produits comme Visual Studio. Il semble que quelqu'un de l'équipe ait simplement trouvé le temps de le mettre en œuvre pour des raisons personnelles. Pensez à saisir plusieurs lignes à la fois dans Visual Studio, par exemple; ce n'est pas comme si des dizaines de milliers de personnes l'avaient demandé, mais je l'aime plutôt.
Roman Starkov

3
@romkyns: Comme pour beaucoup de choses, il faut soit un initié discret, soit mille voix qui crient aux portes.
Hayem

35

Plusieurs fois, j'ai dû me battre avec un traitement de texte pour que le document ait l'apparence que je veux sans règle automatique cachée contrôlant le placement de mes mots. Je ne veux pas passer une seconde à essayer de comprendre pourquoi l'éditeur insiste pour y placer ces mots.


11
Je ne comprends pas non plus pleinement ce sentiment, car de telles règles me frustrent également beaucoup. Mais c'est différent de deux manières. Un: Tout comme les tablettes maintenant, vous n’avez pas à les utiliser si vous ne le souhaitez pas. Vous pouvez laisser le texte de vos collègues seul s'il les utilise. Deux: les taquets élastiques n’ont pas de règles cachées, mais clairement évidentes. Le comportement est tout à fait naturel - peut-être même plus naturel que les tabstops traditionnels, qui se produisent à une position arbitraire, généralement non pertinente, dans le texte. C’est la raison pour laquelle personne n’utilise plus les tabulations pour autre chose que l’indentation.
Timwi

10
@ Timwi: La question était de lister les inconvénients. J'ai fait.
mhoran_psprep

14
Cela ne semble pas évident dans le GIF, mais le seul moyen de le comprendre est que lorsque vous appuyez sur "TAB", tout ce qui suit apparaîtra correctement aligné verticalement. Ce n'est rien comme un traitement de texte. Essayez juste la démo interactive sur le lien que j'ai posté, et vous verrez à quel point c'est naturel.
Roman Starkov

3
@ mhoran_psprep: Très bien, j'apprécie votre contribution. Je suppose que nous examinions différentes interprétations de la question. Vous énumérez les inconvénients de votre utilisation de la fonctionnalité, alors que je pensais qu'il s'agissait d'inconvénients à l'introduction de la fonctionnalité (c'est-à-dire la rendre disponible et non obligatoire ).
Timwi

27

C'est la première fois que j'en entends parler. Je ne sais pas si c'est une bonne idée, mais cela semble peu utile, car nous avons des outils (tels que l'indentation) qui déjà formatent automatiquement le code.

Que se passe-t-il lorsque j'ouvre vos vilaines tabulations élastiques dans vim et les modifie? Est-ce que l'onglet se nettoie automatiquement ou vous laisse-t-il un gâchis?

Les principaux inconvénients, tels que je les vois, sont peut-être les différences, le contrôle de version et la compatibilité avec les éditeurs qui ne les prennent pas en charge. Cela prend peut-être beaucoup de modifications de code pour les prendre en charge et il y a des choses plus importantes que la fonctionnalité "encore un onglet pour formater le code". Après tout, nous pouvons tous utiliser indentce qui fait tout ce qui précède si la mémoire est bonne.


9
Quelle attitude rétrograde. Ne progressons pas, car les anciens outils obsolètes préférés des utilisateurs ne peuvent pas encore s'en sortir ! (L'ironie, bien sûr, étant que ces outils (tels que vim) sont open-source, donc si cela vous importait vraiment, vous pourriez (et devriez probablement ) y ajouter un support de
tabulation

14
@ Timwi: Vous manquez tout à fait ce que je voulais dire. Que se passe-t-il lorsque votre fichier de code est analysé par quelque chose qui ne connaît pas les tabstops élastiques? Vous vous retrouvez avec un désordre ou peuvent-ils faire face? Qu'en est-il du contrôle de version et des diffs? Vouloir que tous les outils prennent en charge la fonctionnalité $ est irréaliste, même si ces outils sont open source.
Sardathrion

14
@ Timwi: Vous supposez que tout le monde trouve les tabstops élastiques aussi géniaux que vous le pensez. Cela peut ne pas être vrai.
Sardathrion

7
@Sardathrion a raison. Que se passe-t-il lorsque je dois télécommander mon serveur * nix sans système de fenêtrage et que je dois examiner du code avec Vim / Emacs / Pico / Quoi? S'il existait un mécanisme lisible, tout irait bien ... sinon ce serait un cauchemar. Je ne vois pas l'avantage des languettes élastiques qui soient aussi bénéfiques. Je peux déjà formater automatiquement mon code pour voir comment il devrait être dans les IDE que j'utilise.
Rig

7
Le point de contrôle de version est un bon point. Je ne pense pas que les gens apprécieront un éditeur qui commence à modifier en silence l’emplacement / le format des commentaires dans le code de manière arbitraire, loin du code qu’ils modifient (voir la section magenta dans la section animée de OP). gif). Il serait utile d’avoir une implémentation de référence avec laquelle jouer, mais ce que je vois jusqu’à présent n’est pas remarquable: emacs fait déjà beaucoup de cela, juste avec quelques touches supplémentaires (ce qui est sans doute une bonne chose).
mcmcc

13

Pour être honnête, je ne les trouve pas très utiles une fois que vous avez surmonté l'excitation initiale. Par exemple, je n'aime pas les commentaires à la fin d'une ligne de toute façon - je place toujours mes commentaires sur une ligne séparée. Avec cela, les onglets élastiques perdent leur utilisation principale.

Après cela, vous pouvez bien sûr toujours les utiliser pour aligner les arguments de la fonction (et les paramètres) et les longues listes d’assignations.

Mais pour les premiers, j'ai tendance à simplement indenter tous les arguments d'un niveau supplémentaire, ce qui me convient parfaitement:

void foo(
    int x,
    int y,
    string z
)

Et je ne vois pas la nécessité de changer cela.

Et en ce qui concerne l’alignement des tâches, je ne le fais pas. Je mets des espaces simples autour des affectations, c'est tout. J'ai aussi tendance à ne pas regrouper beaucoup d'assignations, de sorte qu'il y a rarement un problème de lisibilité.

En résumé, les onglets élastiques n'ont absolument aucune utilité pour moi. C’est bien sûr une préférence très personnelle qui peut varier, mais j’estime que cela fonctionne bien et que l’absence de prise en charge des onglets élastiques tient au fait que d’autres pensent de la même façon.

Si un éditeur les implémentait, je ne les utiliserais toujours pas.


Apprécié. Il semble que vous puissiez également utiliser une police à largeur variable si vous le souhaitez, car vous n'alignez de toute façon rien d'autre que le début de la ligne. En fait, Visual Studio offre un très bon support pour cela, et l’amélioration de la lisibilité est appréciable.
Roman Starkov

1
@romkyns Nous avons eu des discussions à ce sujet et au cours de l' une d' elles, j'ai essayé d'utiliser une police de caractères proportionnelle pour la programmation pendant un certain temps. Le résultat est que les polices mono-espacées fonctionnent mieux, même en ignorant l'indentation. En dehors de cela, je travaille actuellement exclusivement avec Vim et la console, qui ne supporteront probablement jamais les polices proportionnelles.
Konrad Rudolph

1
@romkyns Cela dit, ces problèmes peuvent être résolus (ou peut-être même résolus avec une police proportionnelle conçue pour la programmation). Mais je ne vois toujours pas vraiment la nécessité.
Konrad Rudolph

13

Un inconvénient est que cela ne fonctionne pas si vous souhaitez aligner sur un groupe de lignes puis indenter sur le suivant, car il regroupe les taquets de tabulation des lignes adjacentes.

def foo( bar,
         xyzzy ):
         wibble() # Too much indentation

Ce que je voulais:

def foo( bar,
         xyzzy ):
    wibble()

Pour les langages à accolades, cela pourrait être moins un problème, car vous pouvez généralement le résoudre en plaçant l'accolade d'ouverture sur une ligne distincte (comme dans l'animation), mais pour les langages sensibles aux espaces, cela devient rapidement pénible, et vous finissez par devoir utiliser des espaces.


D'accord. L'implémentation de Nick ne fonctionne pas très bien pour des langages comme Python.
Roman Starkov

3
Pourquoi ça ne marcherait pas? Ce n'est pas une limitation fondamentale, l'algorithme doit simplement être sensible à la langue. Mais dans une certaine mesure, cela est vrai même aujourd'hui, Vim, par exemple, définit différentes règles d'indentation en fonction de la langue. Cela pourrait facilement prendre en compte l'indentation Python.
Konrad Rudolph

1
@ KonradRudolph Non, ils ne pouvaient pas. Le tirant d’éléments de tabulation élastiques correspond à la possibilité d’indenter / désindenter automatiquement des groupes de texte. Un exemple simple est la fin d'une instruction "if": vous essayez et non-indenter parce que vous quittez l'instruction, mais les tabstops élastiques "intelligents" décident que vous souhaitez également indenter la ou les lignes ci-dessus, etc. et ainsi de suite ... Et si vous devez explicitement regrouper le texte, alors à quoi sert-il? C'est plus de travail que de réparer les empreintes vous-même ...
Izkata

1
@Izkata Unindenting manuellement devrait (devrait) simplement mettre fin au groupe actuel. Pourquoi voudriez-vous jamais contrôler l'indentation avec la languette élastique qui s'arrête manuellement? Vous ne voudriez pas, donc l'algorithme sait que lorsque vous le faites, c'est pour mettre fin à un bloc, pas pour annuler le retrait du bloc ci-dessus.
Konrad Rudolph

1
Oh, bon point. Hmm ... peut-être pourriez-vous double-indenter les arguments? Ainsi, il wibble()n'y aurait qu'une seule indentation et, par conséquent, ne serait pas aligné avec les arguments de la fonction?
Ajedi32

12

Pourquoi ne faisons-nous pas simplement que le caractère de tabulation verticale (VT, ASCII 11) serve à indiquer l'utilisation de tabstops élastiques? Cela ne sert à rien dans aucun langage de programmation traditionnel, et pourtant, il est analysé comme un espace valide dans chacun d'entre eux, autant que je sache.

Cela signifierait que l'utilisation de tabulations élastiques n'est plus une convention externalisée (par exemple, "ce fichier a été formaté avec des tabulations élastiques, veuillez les activer"), mais une option pour laquelle vous optez au cas par cas.

Les éditeurs de texte existants affichent généralement un glyphe ou un espace unique à la place d'un onglet vertical. Ce n’est pas idéal, mais un petit prix à payer, IMO.


10

Ils ne sont pas mentionnés car ils ne sont pas implémentés dans la plupart des IDE d'éditeurs de texte; ils sont une nouveauté peu utile dans un projet.

Les espaces sont utilisés pour la programmation depuis l’époque des cartes perforées. Les onglets sont arrivés et quelqu'un a évidemment pensé que c'était une bonne idée (ils se sont trompés: p).

À l'époque où la plupart des éditeurs modernes peuvent convertir automatiquement les onglets en espaces ... ils sont plutôt inutiles.

Devoir installer un autre outil pour traiter quelque chose d'aussi trivial que tabulations / espaces ne m'intéresse certainement pas, et je ne pense pas que cela plairait à la plupart de mes collègues.


J'ai effacé les commentaires alors qu'ils tombaient dans une insulte.
ChrisF

1
Je pensais juste que la raison principale pour laquelle j'aime bien l'idée de tabstops élastiques ne réside pas dans le fait qu'elle résout le problème des tabulations par rapport aux espaces, mais à cause du comportement indiqué dans le GIF dans la question d'origine; alignement automatique et sans douleur. De plus, pour VCS diffs, cet exemple présente l'avantage supplémentaire de ne pas nécessiter de changement d'espace.
Ajedi32

"Avoir à installer un autre outil ..." n'est pas un argument assez valable ... Comme s'il n'y avait pas assez d'outils déjà utilisés.
Milind R

@MilindR Que vous considériez l'argument suffisant ou non, c'est la raison pour laquelle (à l'époque, il y a trois ans) je ne m'intéresserais pas à cela. L'utilisation de nombreux outils permettant de faire quelque chose d'utile n'est pas une raison pour en ajouter un autre qui n'ajoute rien à votre environnement.
TZHX

Des attitudes comme celle-ci sont la raison pour laquelle des entreprises telles que MS décident de forcer les utilisateurs à utiliser de nouvelles UX ... Je frémis de penser à ce qui se passerait si la même attitude était appliquée aux disquettes -> Transition de CD.
Milind R

4

Je pense qu'ils trouveraient une grande utilité si les IDE les prenaient en charge (Microsoft!). Une fois que les gens ont découvert qu'ils pouvaient frapper leurs bacs de fleurs sur le côté et les rendre bien lisibles, ils le feront. Vous pourriez peut-être ajouter soudainement plus de commentaires au code source (ce qui ne peut être que positif).

Je suppose que nous pourrions également ajouter des "info-bulles" à la liste "serait-il bien si ...", afin que vos blocs de commentaires volumineux puissent être masqués et visualisés facilement en cas de besoin? Nous pourrions peut-être aussi avoir des blocs de commentaires qui font partie de la documentation (pas des trucs de type sandcastle, des extraits de documentation lisibles par l'utilisateur qui ont été incorporés dans le code, pas seulement les en-têtes de méthode).

Inconvénients: les différences entre vos sources peuvent sembler mauvaises si plusieurs lignes semblent avoir été modifiées alors que seul 1 (vraiment) a été modifié (si l’éditeur a sauvegardé le fichier avec les tabulations converties en espaces). Ou bien, si l'onglet élastique était implémenté avec un seul caractère (ou plus vraisemblablement, 2 tabulations), alors l'affichage de votre source en dehors de l'éditeur pourrait être gênant.

Cependant, je pense que j'aime bien l'idée, "onglet" à la fin d'une ligne élastifie le bloc de commentaires et aligne tous les commentaires sur les lignes suivantes (qui ont un espacement de double tabulation) en conséquence.


3

Voici comment je vois les choses: si la plupart des outils populaires prenaient déjà en charge les arrêts de tabulation élastiques, beaucoup de gens les utiliseraient. La même chose s'est produite avec le mode navigation / édition de vi, avec la coloration syntaxique, et plus tard avec Intellisense. Dans chaque cas, la sagesse établie était que cela n’était ni utile ni utile, mais il a été mis en œuvre et a démarré.

Les taquets élastiques ont bien sûr un impact relativement faible. La plupart des gens sont suffisamment satisfaits du statu quo et s'en moquent. Un raisonnement similaire est appliqué à de nombreuses situations dans lesquelles certaines personnes sont simplement heureuses de ce qu'elles ont et ne voient aucune raison de passer à quelque chose de plus avancé. En d’autres termes, le plus gros problème avec les taquets élastiques est le même que pour presque toutes les autres bonnes idées: il faut qu’il gagne en traction.

Mais cela ne signifie pas que la fonctionnalité ne peut pas être adoptée progressivement. Chaque langage de programmation a été adopté progressivement, même si toute une équipe a besoin d’un nouveau compilateur et d’un nouvel IDE pour commencer à l’utiliser. Il en va de même pour chaque architecture matérielle et de nombreux autres exemples. En outre, le manque d'intégration avec les outils existants ne constitue pas un obstacle: il en va de même, par exemple, du "format unifié-diff", qui remplace progressivement un format antérieur moins lisible, mais néanmoins compris par des outils automatisés. (comme patch). Ces outils ont été améliorés au fil du temps.

J'apprécie les problèmes d'interopérabilité évoqués par d'autres, mais malgré eux, il y aura certainement des équipes (comme la mienne) qui l'adopteront sans hésitation, dans notre intégralité. Les outils externes tels que la différenciation, la fusion, etc. ne le prendront pas en charge au départ, mais nous ferions notre part pour encourager les fournisseurs à inclure cette fonctionnalité. C'est ainsi que des progrès ont toujours été accomplis. Cela nécessite quelques peines pendant une période transitoire temporaire, mais finalement, cela en vaut la peine.


L'argument C vs C ++ semble un peu erroné. Bien que cela puisse être vrai pour "certaines personnes" (comme vous l'avez dit à juste titre), il existe des raisons évidentes de rester en C ou de favoriser C ++ en fonction de la situation. La taille de l'exécution C ++ étant l'une d'entre elles, dans un paramètre par défaut.
haylem

Je suis avec haylem. Votre remarque serait plus solide sans la comparaison C-contre-C ++. Ce sont des langues assez différentes. À mon sens, C s’applique à la programmation système et à d’autres tâches élémentaires nécessitant un contrôle important (une machine virtuelle, par exemple). C ++ est davantage destiné aux applications de niveau moyen où l'abstraction est utile pour gérer la complexité (espaces de noms, conteneurs et algorithmes STL, modèles), mais les performances restent un sujet de préoccupation (les jeux étant l'exemple le plus visible).
Jon Purdy

@haylem: Merci pour les commentaires. J'ai supprimé la référence à C / C ++.
Timwi

@JonPurdy: Merci pour les commentaires. J'ai supprimé la référence à C / C ++.
Timwi

2

Le plus gros problème que j'aurais avec cela est l'espacement incohérent dans toute la documentation. Je sais qu'en tant que programmeur, je serais ennuyé de voir une boucle ou une instruction if à l'indentation «standard», puis de remarquer des indentations différentes. Je sais personnellement que j'aime voir toutes mes accolades alignées dans la documentation, pas seulement dans le bloc de code que je regarde.

Globalement, je pense que c'est une bonne idée cependant, mais personnellement, je ne l'aimerais pas.


1

Je viens de tester l'implémentation par des tablettes élastiques de jEdit, qui fonctionne étonnamment bien avec les langages de programmation avec lesquels je suis familier (principalement les langages HTML / XML et les langages de type C). Avec le code Python, voici comment il a été rendu (des espaces utilisés à la place des tabulations pour illustrer l’alignement des choses):

def foo(x):
             '''<1 tab before the docstring.
No tab       <tab
No tab       <tab
             <tab  <another tab
             <tab  <another tab
             <tab'''
             if 1 or 2:    #<Tab before this comment
                           yield True

Pour un langage tel que Python reposant sur l'espacement, il s'agit d'un facteur décisif, à moins que vous ne désactiviez la fonctionnalité fournie par les tabstops élastiques. Des éditeurs tels que Vim et Emacs simplifient la désactivation de la plupart des fonctionnalités si vous connaissez le nom de l'option et son désactivation, mais cette fonctionnalité doit être désactivée pour le code comme ci-dessus.

Cela dit, c’est génial pour les systèmes ASM x86, C, C ++, Go, XML, HTML et autres qui ne dépendent pas tellement des espaces:

import (
    "fmt"    // We love formatting functions.
    "io"     // Because I/O is useful.
    "os"     // Can't open a file without os.Open!
)

type Foo struct {
    Field1              int          // This is properly aligned
    ReallyLongField2    string       // with this.
    privateField        io.Reader    // Elastic tabstops are great for Go.
}

Je dirai que les dialectes Lisp tels que Scheme ont leurs propres conventions qui feraient aussi en sorte que les tabstops élastiques rendent le code "moche". Si je modifie mes paramètres de tabulation pour qu'ils correspondent à la convention de 2 colonnes et que j'insère des tabulations à des emplacements inhabituels (entre une fonction et ses arguments):

(let loop ((n 1))
  (if  (> n 10)
        '()
        (cons  n
               (loop (+ n 1)))))

vs le plus lisible:

(let loop ((n 1))
  (if (> n 10)
      '()
      (cons n
            (loop (+ n 1)))))

Certes, celui-ci n'est pas aussi grave que l'exemple Python, mais il réduit nettement la lisibilité du code. Bien que j'apprécie beaucoup la fonctionnalité lors du codage en C # ou C ++, je déteste cette fonctionnalité dans un langage comme Python ou Scheme où les espaces sont fonctionnels et / ou visuellement utiles. Les tabstops élastiques ont été créés spécifiquement pour être utiles sans nécessiter un utilitaire d'indentation séparé, mais ils ne sont évidemment pas destinés à tous les langages de programmation.


0

Emacs gère déjà l'indentation en présence de parenthèses non fermées et alignera automatiquement wilma avec fred . Je ne sais pas pourquoi Eclipse ne fait pas la même chose. Ok, j'ai une idée, mais c'est peu compliqué.

Vous pouvez aussi amener Emacs à aligner le commentaire sans trop de difficulté, mais autant que je sache, personne d'autre que vous ne l'a jamais voulu.


2
Je ne peux interpréter votre dernière phrase que comme une traîne, puisqu’au moins un autre type l’a voulue assez mal pour créer une page bien argumentée, une implémentation Java et un GIF pour montrer pourquoi elle est bonne. Si vous lisez les réponses, vous constaterez que Nick n'est pas seul non plus. Oh, attends, regarde ici aussi.
Roman Starkov

À propos, Emacs se réindente-t-il wilmalors de vos modifications, par exemple en modifiant la longueur du nom de la fonction? Si c'est le cas, c'est assez proche de ce que font les taquets élastiques.
Roman Starkov

@romkyns: Je ne voulais pas traîner, je voulais simplement dire que je n'avais jamais vu ce style de commentaire indenté dans EMACS. En général, EMACS ne réindente pas plusieurs lignes au fur et à mesure de la frappe, mais cela peut également être modifié.
Kevin Cline
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.