Kakoune, un éditeur de texte qui a du caractère

Posté par Benoît Laurent (site web personnel) le 11 novembre 2015 à 20:44. Édité par Lucas, mawww, Anonyme, Benoît Sibaud, patrick_g et Thomas Debesse. Modéré par Benoît Sibaud. Licence CC By‑SA.

Étiquettes :

nov.

2015

Kakoune est un éditeur de texte en console qui gagne a être connu. Cette dépêche a pour but de le faire découvrir à plus de monde.

NdM : Le logiciel est placé par ses auteurs dans le domaine public.

Présentation

Logo de Kakoune Kakoune avait été évoqué dans le journal Tour d'horizon des éditeurs de texte pour le terminal il y a bientôt 1 an.

Il a depuis continué d'évoluer assez rapidement et s'est doté récemment d'un site web Kakoune.org.

Kakoune, c'est plus de 3 ans de développement et plus de 14000 lignes de code c++11 ; il cumule aujourd'hui plus de 30 contributeurs.
De toute la famille des éditeurs inspiré de vi/vim, c'est le seul qui va au delà du clone et repense l'interaction avec le texte.

Kakoune reprend les grand concepts de la famille vi, à savoir :

un éditeur avec plusieurs modes (édition, sélection, commande, …) ;
les séquences de touches forment un langage d'édition de texte.

Fonctionnalités — Spécificités

Kakoune se définit lui-même comme :

inspiré par Vim (c’est un éditeur modal) ;
plus rapide (dans le sens "moins de touches à presser") ;
permettant la sélection multiple ;
ayant un design orthogonal.

Fonctionnalités

sélection multiple comme principale façon d'interagir ;
puissantes fonctions de manipulation des sélections :
- sélection de toutes les correspondances d'une expression rationnelle dans les sélections en cours,
- conservation de toutes les sélections contenant ou ne contenant pas de correspondances à une expression rationnelle,
- divisions des sélections en cours avec une expression rationnelle,
- objets texte (paragraphe, phrase, blocs imbricables) ;
puissantes primitives de manipulation du texte :
- alignement des sélections,
- rotation du contenu des sélections,
- manipulation de la casse,
- indentation,
- envoi de chaque sélection à un filtre extérieur ;
architecture client-serveur :
- clients multiples sur la même session d'édition,
- utilise tmux ou votre window manager pour gérer les fenêtres ;
interaction facile avec les programmes externes ;
aide contextuelle automatique ;
complétion automatique lors de la frappe ;
macros ;
crochets ;
coloration syntaxique :
- prise en charge de plusieurs langages dans le même tampon,
- coloration différente d'un même tampon dans des fenêtres différentes.

Quelques exemples

Afin d'illustrer la manière de travailler avec Kakoune, voici quelques exemples expliqués.

Le premier exemple permet d'aligner les signes = apparaissant sur trois lignes consécutives.

3Xs=<RET>&

3X sélectionner 3 lignes à partir de la ligne courante
s entrée en mode sélection
=<RET> on sélectionne le = dans chaque ligne
& aligner les sélections

Le second exemple montre comment remplacer un motif par un autre dans le tampon courant (communément appelé "remplacement global").

%sfoo<RET>cbar<ESC>

% sélectionner l'intégralité du tampon
sfoo<RET> sélectionner les instances de l'expression régulière "foo" dans la sélection courante
c entrer en mode d'insertion pour remplacer le contenu des sélections
bar<ESC> insérer "bar" puis quitter le mode d'insertion

Pour les vimistes, un document, Migrating from VIm, explique les différences de concepts.

La principale différence étant que dans Kakoune, on sélectionne d'abord le texte à manipuler, puis on lance des actions sur la ou les sélections. Comme tout tourne autour des sélections, le choix a été fait que les commandes avec Shift étendent celles-ci. Par exemple : w sélectionne un mot et Shift-w ajoute le mot suivant à la sélection.

Ce choix a nécessité dans certain cas de rompre la compatibilité avec vim, par exemple J sélectionne vers le bas et c'est Alt-J pour joindre deux lignes.

Compilation — Installation

Kakoune fonctionne sous les Unix, ses dépendances sont :

libboost-all-dev
libncursesw5-dev

Développé en C++11, il nécessite un compilateur compatible, soit GCC >= 4.8 ou clang = 3.4

Pour les personnes intéressées qui voudraient tester Kakoune, les instructions de compilation sont simples et tiennent en quelques lignes :

git clone https://github.com/mawww/kakoune.git
cd kakoune/src
make
./kak

Il existe aussi beaucoup de recettes (OSX, Arch, Fedora, etc.) dans la documentation principale, section installation

Avenir

Bien que Kakoune continue d'évoluer, il est tout à fait utilisable en tant qu'éditeur principal. Des modifications incompatibles avec l'existant peuvent encore arriver de temps à autres mais se font de plus en plus rares. La prise en charge de l'édition de code C ou C++ est bien en place, et le modèle d’extensibilité semble fonctionnel.

Les prochains points clé pour Kakoune sont désormais :

davantage d'utilisateurs afin de développer la prise en charge de plus de langages ;
de cas d'utilisations (voir Advertise Kakoune).

Pas de version 1.0 à l'horizon, pas du tout de numéro de version en fait. L'auteur préfère avoir une branche master stable grâce à de nombreux tests (171 à ce jour) et une intégration continue (voir Begin versioning/releasing kakoune?).

Aller plus loin

# Plus rapide ?

Posté par antoyo le 11 novembre 2015 à 21:05. Évalué à 10.
Bonjour.

Je n’ai pas essayé cet éditeur de texte, mais je me demande si c’est vraiment plus rapide d’utiliser les sélections.

Par exemple, l’exemple donné plus haut :
```
%sfoo<RET>cbar<ESC>
```
n’est pas vraiment plus rapide que :
```
%s/foo/bar
```
Y a-t-il quelque chose que je n’ai pas compris ?

De plus, je me suis mis de moins en moins à utiliser les sélections dans neovim (avec relativenumber, c’est plus simple).

Merci.
- [^] # Re: Plus rapide ?
  
  Posté par mawww le 11 novembre 2015 à 23:42. Évalué à 9.
  
  Bonjour,
  
  c'est une touche de moins (le : requis dans vim avant le %), mais le gros avantage reste que c'est incrémental, on voit la sélection et on utilise le mode d'insertion normal. L'autre aspect, c'est que c'est composable, tu peu par exemple faire %sfoo(msbard qui va selectionner les matches de foo(, puis selectionner le contenu des parenthese apres le foo (le 'm' fait ce que la touche '%' fait dans vim), puis selectionner bar dans ces selections et le supprimer (avec 'd'), ce qui permet d'exprimer la suppression de tout les 'bar' dans les parametres de 'foo' (comme exemple).
  - [^] # Re: Plus rapide ?
    
    Posté par rogo le 12 novembre 2015 à 17:16. Évalué à 3.
    
    Je suis loin d'être convaincu.
    
    D'abord s/foo/bar/g, ça parle à plein de gens, alors que la syntaxe alternative est trop exotique à mon goût. J'aurais compris qu'on abandonne le format vi pour le PCRE (c'est-à-dire "à la Perl"), mais j'ai plus de mal avec encore un nouveau format.
    
    Ensuite, il m'arrive souvent de revenir modifier le pattern au fur et à mesure que j'écris le remplacement, surtout pour les regexs complexes. Sauf erreur, cela ne semble pas prévu avec Kakoune.
    Idem pour rappeler un ancien substitute et le relancer, éventuellement après une retouche.
    - [^] # Re: Plus rapide ?
      
      Posté par mawww le 12 novembre 2015 à 17:54. Évalué à 5.
      Il faut comprendre que ça n'est pas une nouvelle syntaxe, Il n'y a pas de concept de remplacement de regex du tout dans Kakoune, uniquement celui de sélection de regex. La substitution viens de la combinaison de plusieurs fonctionnalités:
      
      La sélection de regex avec s, qui ouvre un prompt, dans lequel on tape une regex (ou l'on peut aussi rappeler une regex précédente via l'historique). Avec la recherche incrémentale, les matches sont visible au fur et a mesure que l'on tape l'expression.
      
      Le mode d'insertion, qui permet de remplacer ces selections, avec access au groupes de captures via les registres 0..9. Ici on y rentre avec c pour supprimer le contenu des sélections avant (exactement comme vim ferait avec cw)
      
      Les regex, au passage, utilise la syntaxe perl (boost::regex en pratique, mais très proche de pcre).
      - [^] # Re: Plus rapide ?
        
        Posté par Jiehong (site web personnel) le 13 novembre 2015 à 13:25. Évalué à 3.
        
        Les regex, au passage, utilise la syntaxe perl (boost::regex en pratique, mais très proche de pcre).
        
        Emacs est à la ramasse là-dessus, ce qui fait que je n'utilise presque jamais les expression régulières dans cet éditeur…
        
        [^] # Re: Plus rapide ?
        
        Posté par Pierre Téchoueyres le 13 novembre 2015 à 20:34. Évalué à 2.
        
        Pourquoi à la ramasse ?
        Il y a bien quelques différences de syntaxe mais j'ai pas l'impression qu'il y ait de gros manques côté Emacs.
        Quelques exemples seraient les bienvenus.
        
        [^] # Re: Plus rapide ?
        
        Posté par barmic le 14 novembre 2015 à 10:35. Évalué à 4.
        
        Si tu veux voir des usages avancés d'expression régulière :
        http://articles.mongueurs.net/magazines/linuxmag106.html
        
        Des gens qui utilisent ça, il n'y en a pas beaucoup (et pas dans leur éditeur de texte).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Plus rapide ?
        
        Posté par Jiehong (site web personnel) le 14 novembre 2015 à 18:09. Évalué à 3.
        
        Pourquoi à la ramasse ?
        Il y a bien quelques différences de syntaxe mais j'ai pas l'impression qu'il y ait de gros manques côté Emacs.
        Quelques exemples seraient les bienvenus.
        
        Emacs ne supporte pas la syntaxe Perl, c'est ça le manque. Après, il a bien sa propre syntaxe, mais c'est moins pratique.
        
        Il n'y a pas de trucs pratiques comme \d, alors que c'est assez utilisé, et il faut échapper des trucs qu'il ne faut pas échapper dans Perl tels que \(\) pour la capture de groupe, ou encore \{\} pour les répétitions, et bien entendu il faut échapper les \ si on veut les matcher.
        
        Voici quelques différences :
        
        | | perl | emacs | |---------------------------+------------+--------------| | Capture | (…) | \(…\) | | Chiffre | \d | [[:digit:]] | | Mot | \w | [[:word:]] | | Espace | \s | [[:space:]] | | Ex. (mot de taille >=20) | \w{20,} | \w\{20,\} | | Ex. (mot finissant par s) | \w+s | \w+s\> | | Ex. (2 mot identiques) | ( \w+)\1 | \( \w+\)\1\> | | Ex. (alternatives) | chat|chien | chat\|chien |
        
        Vu que c'est propre à Emacs, t'as pas facilement envie de l'apprendre, et il y a bien trop de \ à mon goût ;)
        
        [^] # Re: Plus rapide ?
        
        Posté par barmic le 14 novembre 2015 à 18:33. Évalué à 4.
        
        Vu que c'est propre à Emacs
        
        Pas du tout c'est les expressions étendues POSIX, tu peux les utiliser par exemple avec grep -E (ou egrep).
        
        Emacs n'a rien inventé à ce sujet là.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Plus rapide ?
        
        Posté par Jiehong (site web personnel) le 14 novembre 2015 à 19:30. Évalué à 3.
        
        Sauf les échappements partout…
        
        [^] # Re: Plus rapide ?
        
        Posté par barmic le 14 novembre 2015 à 22:14. Évalué à 4.
        
        En effet ce sont des expressions régulières basiques (c'est aussi du POSIX).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Plus rapide ?
    
    Posté par eingousef le 12 novembre 2015 à 21:38. Évalué à 10.
    
    qui va selectionner les matches de foo(
    
    Alors je sais pas qui est le nouveau sélectionneur pour les matches de foo par contre en regardant dans le code de linuxfr j'ai pu voir des matches de ruby :o
    
    *splash!*
# Au secours

Posté par chimrod (site web personnel) le 12 novembre 2015 à 10:05. Évalué à 10.

Ils ont introduit le trombone dans la console !!
- [^] # Re: Au secours
  
  Posté par Benoît Laurent (site web personnel) le 12 novembre 2015 à 11:38. Évalué à 1.
  Je ne sais pas si c'est un clin d'œil au clippy de word !
  
  Mais ça peut se configurer dans le kakrc:
  - soit déactiver complètement set global autoinfo false
  - soit changer le style, sont disponibles 'clippy', 'cat' et 'none' set global ui_options ncurses_assistant=none
  P.S: Je ne peux pas tester tout de suite la syntaxe, mais ça doit être ça
  - [^] # Re: Au secours
    
    Posté par robin le 15 novembre 2015 à 00:50. Évalué à 2.
    
    L'ascii art du chat, c'était mon tout premier pull request ! Un grand moment :)
    
    bépo powered
# Difficulté d'apprentissage

Posté par Pierre Jarillon (site web personnel) le 12 novembre 2015 à 10:13. Évalué à 8.

Que ce soit Vim ou Emacs ou un de leurs dérivés (gvim / xemacs), la pente d'apprentissage est raide et c'est normal.
Un éditeur de texte plus simple comme kwrite ou nedit est certes plus facile à apprendre mais ses performances resteront limitées. Kakoune ne cherche pas à jouer dans ce registre mais bien dans celui des grands, des éditeurs réservés aux professionnels pour qui l'investissement dans l'apprentissage sera rentable.

On ne change d'habitudes que dans deux cas. Le premier, c'est qu'on y est obligé, le deuxième, c'est qu'on y trouve un intérêt. Si l'intérêt n'est pas franchement plus important que l'effort, il y aura une résistance au changement. Est-ce que kakoune est meilleur que vi ou emacs ? Peut-être, mais pour s'imposer, il faudra qu'il soit franchement meilleur, ce qui ne sera pas facile.

J'ai 25 ans de pratique de VI, je n'ai pas changé pour emacs malgré l'insistance de quelques amis ainsi que celle de RMS car je n'aurais jamais rentabilisé l'investissement.

Pour terminer, il a un éditeur de texte que je ne regrette absolument pas, c'est EDLIN !
- [^] # Re: Difficulté d'apprentissage
  
  Posté par Benoît Laurent (site web personnel) le 12 novembre 2015 à 10:37. Évalué à 3.
  
  Comme le décrit mawww dans sont commentaire au dessus, Re: Plus rapide ?, le mode sélection est mis en avant et celui-ci est incrémental et très visuel. Donc si l'apprentissage d'un jeux de commandes reste nécessaire, il est plus facile de composer ses commandes au fur et à mesure, alors que dans vi/vim elles doivent être faite en une fois.
  
  Après je suis d'accord, changer d'éditeur est quelque chose de difficile.
- [^] # Re: Difficulté d'apprentissage
  
  Posté par mawww le 12 novembre 2015 à 11:39. Évalué à 10.
  Clairement, Kakoune requière un apprentissage pour devenir efficace.
  
  Du point de vue d'un Emacsien, il n'est pas un meilleur Emacs, loins de la, car il se concentre plus sur l'interaction avec l’environnement extérieur que la programmabilité de ses comportements internes.
  
  Pour un Vimiste, il dépends bien entendu de son point de vue. A mon sens Kakoune est un meilleur vim pour différentes raisons:
  - Plus rapide que vim: dans le sens moins de touches à taper pour le même résultat (voir mes exemples vimgolf)
  - Plus simple que vim: les responsabilités des différents modes sont mieux respectés, les commandes interagissent beaucoup plus facilement les unes avec les autres.
  - Plus interactif que vim: l'inversion de la sélection et de la commande, outre permettre la composition des sélections, permet d'afficher incrémentalement ceux sur quoi l'on va agir. Le modèle d'extension rends l’a-synchronicité facile, les commandes grep et make par exemple tournent en tache de fond, avec leur sortie remplissant progressivement un tampon.
  - Plus facile à apprendre: Kakoune essaie un maximum de fournir de l'aide en direct. Par defaut chaque commande dans le prompt affichera sa documentation, les commandes comme g qui attendent une seconde touche affichent aussi les possiblités. On peut même, en mettant l'option autoinfo à 2, obtenir une aide qui explique apres chaque touche en mode normale ce qu'il viens de se produire.
  Enfin, en respectant la vision "les touches appuyés forment un language d'edition de texte", Kakoune est en passe de remplacer sed (pour moi) pour les editions rapides, car il me permet d'exprimer plus concisement des changement plus complexe. (Kakoune peut etre utilisé comme un filtre avec 'kak -f', par exemple echo tchou | kak -f 'sou<ret>caa' est equivalent à echo tchou | sed -e 's/ou/aa/g'
  - [^] # Re: Difficulté d'apprentissage
    
    Posté par tcws le 12 novembre 2015 à 20:17. Évalué à 7. Dernière modification le 12 novembre 2015 à 20:19.
    
    c'est intéressant comme point de vue, mais devant l'exemple je reprendrais la réflexion faite plus haut de la "lisibilité"
    s/foo/bar est directement lisible par plus de gens, même si ils ne connaissent ni sed ni vi (les pauvres)
    d'un autre côté si à l'usage c'est plus efficace ça peut convenir à la jeune génération - je n'en suis plus depuis un bail, comme Pierre Jarillon je suis resté coincé à vim (que j'utilise à 12% de ses capacités comme 87.23% de ses utilisateurs - à la louche). o tempora…
    - [^] # Re: Difficulté d'apprentissage
      
      Posté par barmic le 13 novembre 2015 à 08:52. Évalué à 4.
      
      c'est intéressant comme point de vue, mais devant l'exemple je reprendrais la réflexion faite plus haut de la "lisibilité"
      s/foo/bar est directement lisible par plus de gens, même si ils ne connaissent ni sed ni vi (les pauvres)
      
      Je ne comprends pas cet argument. Quand tu utilise ton éditeur de texte ce n'est pas systématiquement pour faire des démonstrations, si ?
      Tu as le même genre d'interface dans emacs.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Plug-ins

Posté par JoeltheLion (site web personnel) le 12 novembre 2015 à 21:45. Évalué à 5.

Est-ce qu'il y a un équivalent de YouCompleMe et Syntactic pour Kakoune ? C'est des Plug-ins vim très utiles pour le développement, j'aurais beaucoup de mal à y renoncer et je pense que ce serait la même chose pour pas mal d'autres gens.
- [^] # Re: Plug-ins
  
  Posté par mawww le 13 novembre 2015 à 10:37. Évalué à 5.
  Kakoune dispose d'un système de complétion intégré similaire à YouCompleteMe, l'heuristique de classement des mots demande encore un peu de peaufinage, mais la fonctionnalité est la. Lorsque on est en mode d'insertion, les mots disponible dans les tampons ouverts sont proposé comme complétion. Le script clang.kak rajoute quand a lui la completion intelligente pour C/C++/Objective-C, et aussi les diagnostiques automatiques à la Syntastic.
  
  Pour activer la complétion pour les fichier C, ainsi que les diagnostiques, on peut mettre le code suivant dans son kakrc:
```
hook global WinSetOption filetype=cpp %{
    clang-enable-autocomplete
    clang-enable-diagnostics
}
```
  - [^] # Re: Plug-ins
    
    Posté par antoyo le 13 novembre 2015 à 20:05. Évalué à 2.
    
    Est-ce que tout cela est asynchrone ?
    Y a-t-il aussi des scripts pour indexer les tags des fichiers d’un projet (par exemple avec ctags) pour permettre la navigation vers la définition d’une fonction ?
    - [^] # Re: Plug-ins
      
      Posté par mawww le 14 novembre 2015 à 04:52. Évalué à 3.
      
      Bonsoir,
      
      Oui, la completion clang est asynchrone, ctags aussi est supporté et peut generer les tags de façon asynchrone avec la commande gentags, et l'on peut sauter a la definition d'une fonction avec la commande tag.
      - [^] # Re: Plug-ins
        
        Posté par antoyo le 14 novembre 2015 à 05:53. Évalué à 2.
        
        Cool !
        J’essaie cet éditeur tout de suite.
        Il va me rester à faire des scripts pour avoir la complétion intelligente en Rust et un fuzzy finder.
        À moins qu’il n’y ait déjà des scripts pour faire ça ?
        Merci.
# Design orthogonal

Posté par Guillaume Maillard (site web personnel) le 12 novembre 2015 à 23:45. Évalué à 9.

L'orthogonalité se définit dès quand il existe une forme bilinéaire entre deux espaces vectoriels sur un même corps.

Je ne sais pas vous, mais moi que je lis du "design orthogonal", je me pose des questions sur le taux de pipoware associé.
- [^] # Re: Design orthogonal
  
  Posté par BAud (site web personnel) le 13 novembre 2015 à 00:10. Évalué à 6.
  
  Tu confonds sans doute Principle_of_orthogonal_design et Orthogonalité, voire en prend la définition de produit scalaire nul.
- [^] # Re: Design orthogonal
  
  Posté par Alex G. le 13 novembre 2015 à 12:10. Évalué à 5.
  
  Ce n'est pas pipo et tout à fait utile.
  
  C'est avoir un code où différent modules se concentre sur une tâche spécifique qu'il font bien, les tâches se composent ensuite naturellement en des choses plus complexes.
  
  Comme je l'entends, le terme orthogonalité vient effectivement de l'espace de vecteurs. Quand tu décris la position d'un point dans l'espace, tu utilises un système de coordonnées composé de vecteurs. Tu peux très bien le faire avec des vecteurs non orthogonaux (mais qui génèrent bien tout l'espace), mais chaque point a alors plusieurs coordonnées possibles. Si tu choisis des vecteurs orthogonaux, tu as un et un seul vecteur coordonnées pour chaque point. De manière intuitive, les vecteurs de ton repère ne répètent pas une information présent dans un autre (la projection d'un des vecteurs sur les autres est nulle).
  
  Dans le logiciel, tu essaye d'avoir des fonctionnalités simples et complètes mais qui ne répètent pas ce que font les autres (ici : sélection, édition etc…, mais pas remplacement car c'est une sélection / édition) mais se composent ensemble pour permettre un vaste ensemble d'interaction (ton espace).
  
  L'avantage c’est que tu génère moins d'incohérence et facilite la maintenabilité (une évolution n'est pas à reporter à plusieurs endroit à la fois, tu peux éventuellement faire évoluer chaque fonctionnalité indépendamment, mais en augmentant toujours les interactions possibles, chaque fonctionnalité a une cohérence interne bien focalisée qui permet de plus facilement dérouler la logique). Le désavantage c'est que n'ayant pas de définition formelle de l'orthogonalité, c'est un peu au nez que tu le définis (où plutôt à l'expérience). C'est également un type de design qui demande plus une vision d'ensemble pour résoudre les cas d'usages concrets.
  
  Bien sur ce n'est pas une définition de logique formelle mais uniquement analogique (mais ça a de la valeur en sois, et tu peux le mesurer en pratique).
  - [^] # Re: Design orthogonal
    
    Posté par Dring le 13 novembre 2015 à 13:02. Évalué à 3.
    
    Foutaises !
  - [^] # Re: Design orthogonal
    
    Posté par Cédric Chevalier (site web personnel) le 13 novembre 2015 à 13:21. Évalué à 9.
    
    Comme je l'entends, le terme orthogonalité vient effectivement de l'espace de vecteurs. Quand tu décris la position d'un point dans l'espace, tu utilises un système de coordonnées composé de vecteurs. Tu peux très bien le faire avec des vecteurs non orthogonaux (mais qui génèrent bien tout l'espace), mais chaque point a alors plusieurs coordonnées possibles. Si tu choisis des vecteurs orthogonaux, tu as un et un seul vecteur coordonnées pour chaque point. De manière intuitive, les vecteurs de ton repère ne répètent pas une information présent dans un autre (la projection d'un des vecteurs sur les autres est nulle).
    
    Non, une base non orthogonale reste une base, l'unicité de la décomposition d'un vecteur dans une base ne nécessite pas l'orthogonalité (Base).
    - [^] # Re: Design orthogonal
      
      Posté par j_m le 13 novembre 2015 à 23:18. Évalué à 1.
      
      Je pense que l'on se rapproche dangereusement d'une herméneutique transformative de la gravitation quantique: Affaire Sokal
      - [^] # Re: Design orthogonal
        
        Posté par Alex G. le 14 novembre 2015 à 11:31. Évalué à 2.
        
        J'ai bien dit qu'il s'agissait d'une analogie, je n'ai aucunement voulu le présenter comme scientifique. Mais bonne référence, en tout cas, il faut éviter de glisser.
    - [^] # Re: Design orthogonal
      
      Posté par Alex G. le 14 novembre 2015 à 11:28. Évalué à 1.
      
      Ok autant pour moi, il faut des vecteurs "libre".
      
      Effectivement, je voulais prendre l'exemple d'une base génératrice mais non libre, mais en pratique pour qu'elle soit libre on la prend souvent orthogonale.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.