Journal Participer à l'amélioration de l'expérience utilisateur d'Emacs (c'est facile)

Posté par  . Licence CC By‑SA.
Étiquettes :
24
22
août
2017

Salut la compagnie,

emacs-oob-reboot est un projet sur github dont le but est de redynamiser Emacs en améliorant l'expérience pour les nouveaux utilisateurs. La méthode est de rassembler de petits changements de configuration et de les proposer aux développeurs d'Emacs. Ce n'est pas un projet de kit de démarrage comme le sont Prelude ou Spacemacs.

Il y a eu quelques bonnes avancées, par exemple which-key a été intégré au dépôt officiel Elpa, ce qui le rend accessible à tout nouvel utilisateur sans configuration (sans devoir ajouter Melpa), et permettra de l'activer par défaut (which-key est génial, il permet de découvrir les raccourcis claviers du mode actuel, de découvrir quelles commandes sont disponibles à partir d'un raccourci incomplet).

Il y a de nombreuses discussions en cours. Dans plusieurs d'entre elles on relève le besoin d'avoir plus d'avis de débutants, plus de "user stories". Donc vous pourrez sans aucun doute aider aux décisions si vous avez par exemple l'expérience d'avoir introduit Emacs à des débutants (amis, collègues, élèves,…).

Ah, et la nouvelle config est facile à tester:

git clone https://github.com/josteink/emacs-oob-reboot
cd emacs-oob-reboot
emacs -Q -l ./init.el
Allons-y ! Emacs 26 sortira dans environ 6 mois après une période de feature-freeze, il est temps de proposer des changements ! (avec cette procédure)

  • # Raccourcis

    Posté par  . Évalué à 7.

    Déja, si tu essayes d’utiliser ctrl+C dans emacs, ça fait pas pareil que dans un autre éditeur. Tu diras, c’est pareil pour vim, mais n’empêche, ça a de quoi faire peur à un débutant (tu diras, c’est pareil pour vim).

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 3. Dernière modification le 22 août 2017 à 16:25.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Raccourcis

        Posté par  . Évalué à 3.

        Note que Ctrl+insert et Shift+insert marchent OOTB sous Emacs

        Bizarrement, pas chez moi. Ne serait-ce pas limité à la version graphique ?

    • [^] # Re: Raccourcis

      Posté par  . Évalué à 1.

      Mais sur Vim quand tu le fais, il te dit ce qu'il faut faire a la place :)

  • # les conventions sur les raccourcis!!!!

    Posté par  (site web personnel) . Évalué à 10.

    Ah, sympathique initiative, j'espère que ce sera un moyen de pousser des choses!

    bon pour être honnête, comme Xah, je trouve que Emacs devrait à tout prix admettre que ses raccourcis claviers n'ont , aujourd'hui, aucun sens.

    Il faudrait un Emacs qui suive les conventions actuelles. Nano a le même problème.
    Mais Emacs a un problème supplémentaire. Il y a des milliers de fonctions possibles. Des raccourcis (et un menu) ne suffisent pas.
    Il peut y avoir plein de solutions ; certains packages offrent d'ailleurs des idées.
    A mes yeux si Emacs veut être utilisatble "out of the box direct t'as vu"; il faut absolument montrer à l'utilisateur à quelles fonctions il a accès.

    En outre, le nommage des fonctions est souvent incompréhensible. L'exemple classique étant "frame" qui désigne une fenêtre et "window" qui désign une frame. Oui je sais ils n'y sont pour rien à l'époque mais y'a un moment il faut s'adapter!

    • [^] # Re: les conventions sur les raccourcis!!!!

      Posté par  . Évalué à 3.

      Il y a des milliers de fonctions possibles. Des raccourcis (et un menu) ne suffisent pas.
      Il peut y avoir plein de solutions ; certains packages offrent d'ailleurs des idées.
      A mes yeux si Emacs veut être utilisatble "out of the box direct t'as vu"; il faut absolument montrer à l'utilisateur à quelles fonctions il a accès.

      c'est sûr, mais on peut s'en sortir je pense: avec which-key, avec un dashboard de bienvenue (https://github.com/rakanalh/emacs-dashboard), avec un smex ou counsel-M-x (https://github.com/abo-abo/swiper) à la place de M-x pour avoir comme une palette sous d'autres éditeurs, et avec des hydras (https://github.com/abo-abo/hydra/) et l'interface à la magit: un "menu" interactif montre les sous-commandes accessibles en une touche. C'est super efficace !

    • [^] # Re: les conventions sur les raccourcis!!!!

      Posté par  (site web personnel) . Évalué à 5.

      bon pour être honnête, comme Xah, je trouve que Emacs devrait à tout prix admettre que ses raccourcis claviers n'ont , aujourd'hui, aucun sens.

      Il faudrait un Emacs qui suive les conventions actuelles. Nano a le même problème.

      Ce sera parfait pour perdre tous les utilisateurs actuels et n'en gagner aucuns (vu qu'il y aura toujours quelque chose qui n'ira pas).

      • [^] # Re: les conventions sur les raccourcis!!!!

        Posté par  . Évalué à 3.

        Les anciens auront tôt fait d’avoir un flag dans leur .emacs qui rétablit l’ancienne config. La force d’emacs est la configurabilité et l’extensibilité non ?

        vu qu'il y aura toujours quelque chose qui n'ira pas

        Mince, le corriger (ce qqch) empêcherait ptete de rendre le logiciel meilleur. Ce serait une conséquence dramatique.

        • [^] # Re: les conventions sur les raccourcis!!!!

          Posté par  . Évalué à 4.

          Les anciens auront tôt fait d’avoir un flag dans leur .emacs qui rétablit l’ancienne config. La force d’emacs est la configurabilité et l’extensibilité non ?

          Pour le coup je pense que fragmenter la communauté, c'est la dernière chose a faire. Les tutos risquent de ne plus être bons, les packages peuvent implémenter des raccourcis utilises par certaines et pas par d'autres.

          En tant qu'utilisateur Emacs, je trouve pas spécialement que les raccourcis clavier soient un tel probleme: une requete google suffit a savoir comment ca marche. Je trouve plutôt que le souci se trouve au niveau du choix des packages par defaut: quasiment aucune autocompletion, aucun syntax checker, meme la coloration syntaxique ou l'indentation pose probleme si on a pas installe les bons packages et si on a pas le bon .emacs.

          Je pense vraiment qu'avec de bons package et settings par défaut, il y a vraiment moyen de faire un truc qui roxxe.

          • [^] # Re: les conventions sur les raccourcis!!!!

            Posté par  . Évalué à 2.

            En tant qu'utilisateur Emacs, je trouve pas spécialement que les raccourcis clavier soient un tel probleme

            En même temps, il semble que les gens visés soient surtout les pas utilisateurs ;)

            • [^] # Re: les conventions sur les raccourcis!!!!

              Posté par  (site web personnel) . Évalué à 2.

              Je suis un peu du même avis que flavos.
              Limite en tant que nouvel utilisateur tu sais à quoi t'attendre en termes d'investissement dans l'apprentissage. Quand j'ai commencé il y a 5 ans, les raccourcis bizarres j'étais prévenu et c'est pas ça qui m'a fait peur.

              Ce qui fait peur dans Emacs c'est effectivement le support de certains langages de programmation (je faisais de l'HTML/CSS/PHP à l'époque c'était attroce), le besoin assez violent de rajouter une bonne quantité de packages pour avoir un éditeur correct, et les nombreux aspects un peu vieillots du soft.

  • # Commentaire supprimé

    Posté par  . Évalué à 5.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Vieux débat (nouvelles réponses?)

      Posté par  . Évalué à 7.

      Le truc le plus repoussant pour les gens, c'est probablement les raccourcis clavier, spécifiquement C-c pour copier (qui sous Emacs bloque tout car c'est le "préfixe" des raccourcis traditionnellement (oui, c'est juste une convention, garantie par rien ni personne)) C-v (qui "page down", big fun pour toute la famille) et C-z

      Je suis débutant sur emacs. Au début j'ai essayé vim, j'y suis resté très peu de temps, mais ça fait connaître les modes, et le langage que formes les raccourcis claviers pour éditer le texte. Ensuite j'ai vu cette video, et là j'ai voulu me mettre à emacs. Auparavant j'avais fait un tour d'horizon, en testant un moment kakoune, spacemacs, spacevim, neovim etc… Du coup je me suis mis à spacemacs.

      Honnêtement spacemacs (enfin emacs en plus out-of-the-box), je trouve ça génial et hyper puissant. J'ai découvert magit et ag par exemple (l'intégration avec helm est juste géniale je trouve). Globalement je trouve que les raccourcis sont très bien organisé, et que couplé à la description des commandes ça permet de se débrouiller à peu près sans la doc à côté.

      Par contre le truc horrible je trouve, c'est trouver des ressources, pour débutant, pour configurer des trucs comme l'auto-complétion, le checking du code etc… En gros ce qui permet de s'approcher d'un IDE. Je sais qu'il est possible d'avoir une configuration hyper puissante, mais pour un débutant (genre quelqu'un qui sait pas encore ce qu'est ctags par exemple) j'ai trouvé très peu de tuto. La doc est toujours là, mais on y passe des heures est ça marche jamais.
      J'en suis même arrivé à regarder des vidéo youtube pour me convaincre que l'auto-complétion pouvait marcher.

      Tout ça pour dire que les raccourcis claviers sont pas le plus gros frein (pour moi en tout cas), parce qu'on se rend vite compte que c'est très efficace. ctrl-z par exemple, il suffit de savoir (et ça on le trouve facilement) que c'est 'u' (dans evil mode) et on le retient facilement.
      Par contre pour avoir une configuration "IDE", c'est plus compliqué. Exemple, je veux configurer pour du python, je vais naturellement sur cette page, là j'apprends qu'il y a un mode python, et après c'est des trucs techniques.
      C'est sûr qu'en cherchant plus on trouve des trucs, mais justement ça montre (je pense) que le problème est la facilité et rapidité d'accès (de façon centralisée) à des tutos et docs pour débutant.

      Enfin bref, voilà mon point de vue de débutant :-).

      PS: quelqu'un sait si un mode 'kakoune' existe dans emacs, comme 'evil' pour vim?

      • [^] # Re: Vieux débat (nouvelles réponses?)

        Posté par  . Évalué à 3.

        salut, très intéressant retour d'expérience merci :)

        Par contre le truc horrible je trouve, c'est trouver des ressources, pour débutant, pour configurer des trucs comme l'auto-complétion, le checking du code etc… En gros ce qui permet de s'approcher d'un IDE

        Je vais naturellement sur cette page (https://www.emacswiki.org/emacs/PythonProgrammingInEmacs)

        comme je comprends. Partir de zéro demanderait de chercher beaucoup de paquets et de copier-coller pas mal l'elisp. Mais toi tu as commencé avec Spacemacs. Or donc tu n'as pas trouvé la config pour Python (python layer) satisfaisante ?

        De plus: je n'ai jamais aimé emacswiki. Je trouve que c'est un mauvais wiki qui ne retient pas les utilisateurs (s'il ne les fait pas fuir). Que penses-tu de cette page wikemacs sur Python ? http://wikemacs.org/wiki/Python Wikemacs est un "vrai" wiki (mediawiki). Il fut lancé par B. Batzov (Prelude, Projectile,…) mais devant le "refus" de la communauté il a laché l'affaire. Heureusement le wiki a été repris par d'autres et il vit toujours. Mais il n'est pas encore aussi bien référencé que emacswiki, encore que pour quelques bonnes pages ça passe.

        Je ne pense pas que parler des wikis rentre vraiment dans l'objectif de emacs-oob-reboot, mais avec l'appui de ton témoignage je tenterais bien le coup…

        et après c'est des trucs techniques.

        là ça m'intéresse de savoir ce que tu entends par là. Qu'est-ce qui est trop technique ? Trop détaillé ? Trop d'elisp ?

        ps: c'est ça kakoune ? http://kakoune.org/ Je comprends pas ce que tu cherches.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 3.

          Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Vieux débat (nouvelles réponses?)

          Posté par  . Évalué à 2.

          comme je comprends. Partir de zéro demanderait de chercher beaucoup de paquets et de copier-coller pas mal l'elisp. Mais toi tu as commencé avec Spacemacs. Or donc tu n'as pas trouvé la config pour Python (python layer) satisfaisante ?

          Si si bien sûr j'utilise le python-layer. De manière générale les layers avec spacemacs c'est purement génial. Par exemple j'ai eu l'occasion de faire un projet web avec d'autres étudiants, et je me suis forcé à utiliser spacemacs. Quand j'ai découvert le web-mode (je crois que ça s'appelle comme ça), c'est génial, j'avais directement la completion pour html/css/scss/js/react etc., avec une syntax-check et même le check des erreurs en js. Le recherche ag est ultra-rapide, et mes camarades me demandaient tout le temps où se trouvait telle fonction et variable dans les fichiers, je me sens roi à parcourir tout le code à coup de 'space-/'.

          Mais :D… Avoir de la complétion en python sur un module nouvellement installé? de la complétion en C++ avec des librairies et pleins de fichiers de code? j'ai cherché des semaines. Je lisais partout que helm pouvait faire de la fuzzy-completion pour le code, et bien j'ai vu des vidéos et gifs mais pas moyen d'avoir ça sur mon ordi… En fait avoir l'auto-completion avec spacemacs c'est pas trop dur, mais faire en sorte qu'elle comprenne le code, les types, explore les librairies etc., avoir les arguments des fonctions par exemple, là c'est plus dur je trouve. Maintenant je sais que ctags (ou ggtags, j'ai jamais compris la différence) sert précisement à ça, mais c'est pas évident pour un débutant qui vient d'un IDE ou tout marche par défaut.

          Que penses-tu de cette page wikemacs sur Python ? http://wikemacs.org/wiki/Python

          C'est 10x mieux. Merci, je vais visiter un peu ça a l'air très intéressant !
          Question: en utilisant spacemacs, j'observe que des fois dans les aides emacs ça diffère un peu. Est-ce que tu penses que ça reste superficiel, ou alors y a des domaines où c'est fondamentalement différent ? (si tu connais un peu spacemacs bien sûr).

          Petite remarque quant à spacemacs: je comprends pas pourquoi dans emacs il n'y a pas ce système de proposition de raccourci clavier. Je trouve ça tellement simple et puissant comme ergonomie. (quasiment) tout commence par 'space', et ensuite tu te laisses guider par l'arborescence des raccourci qui s'affiche. C'est tellement bien je trouve, que je pense à expérimenter un plugin Blender dans le même genre, ça permettrait de cases des dizaines de raccourcis de façon totalement rangée et rapide d'accès. Aussi en plus de cette 'arborescence' de touches à presser pour faire un raccourci, je trouve que le truc génial c'est de ne pas avoir à tenir enfoncée les touches, ça rend le truc hyper confortable.

          Illustration du 'space'+'suite du racourci…' pour ceux qui connaissent pas :
          spacemacs

          Qu'est-ce qui est trop technique ? Trop détaillé ? Trop d'elisp ?

          Peut-être technique est pas le bon terme.
          Il n'y a pas de valeur ajoutée à une simple liste de modules je trouve. C'est clairement pas pour les débutants, il n'y a quasiment aucune indication, à peine des phrases. Disons que ça n'aide en rien à par donner un tour d'horizon des modules pour python. Et je dirai qu'en étant débutant (pas juste dans une démarche de découverte, mais vraiment pour arriver à adopter emacs sérieusement), en attend plutôt une démarche guidée (avec un choix déjà fait de certains modules très utilisés), avec des explications, des commentaires etc… (en gros avoir la base pour pouvoir vraiment l'utiliser, puis après on pourra customiser comme on veut, "aux petits ognons" comme vous dites souvent :-))

          c'est ça kakoune ? http://kakoune.org/ Je comprends pas ce que tu cherches.

          Oui ! Je de plus en plus l'impression (en lisant des forums, articles etc…) que c'est vraiment un pas en avant par rapport à l'ergonomie de vim. Ce que j'aime beaucoup c'est que tout soit visuel, et qu'il y ainaturellement des multi-selections.
          evil-mode sert à ramener l'ergonomie de vim (à l'origine, mais j'ai l'impression que ça devient limite un standard d'ergonomie maintenant dans pleins de logiciels et même sites web) dans emacs. Je me demandais si il existait la même chose mais avec l'ergonomie de kakoune. Mais je pense pas, vu la jeunesse de celui-ci.

          En tout cas merci encore pour wikemacs, ça va peut-être me garder définitivement dans emacs (ou plutôt spacemacs) ! (j'ai essayé peut-être 4-5 fois de revenir sur emacs pendant plusieurs semaines, avant de retomber sur un IDE genre kdevelop pour le C++, par que j'arriverai pas à avoir les features que je voulais)

          • [^] # Re: Vieux débat (nouvelles réponses?)

            Posté par  . Évalué à 2.

            Question: en utilisant spacemacs, j'observe que des fois dans les aides emacs ça diffère un peu. Est-ce que tu penses que ça reste superficiel, ou alors y a des domaines où c'est fondamentalement différent ? (si tu connais un peu spacemacs bien sûr).

            euh alors ce devrait être des différences superficielles, du genre raccourcis claviers (évidemment) ou moyens de configurer les différents modules en elisp, auquel cas si ça diffère de la doc officielle c'est pas grave (j'ai pas utilisé spacemacs (evil-mode bien sûr !) (mais j'ai un peu regardé sa config) donc des exemples seraient bienvenus).

            En tout cas merci encore pour wikemacs, ça va peut-être me garder définitivement dans emacs (ou plutôt spacemacs) !

            ça c'est cool ça :) Je rappelle qu'un wiki est ouvert aux contributions et que petit à petit le "noob" construit des pages utiles ;) (la preuve)

          • [^] # Re: Vieux débat (nouvelles réponses?)

            Posté par  (site web personnel) . Évalué à 2.

            ah ouais la liste des raccourcis claviers spacemacs est pas mal.
            je pomperai bien leur truc pour rendre mes prompts plus jolis (dans emacs nu)

          • [^] # Re: Vieux débat (nouvelles réponses?)

            Posté par  (site web personnel) . Évalué à 3.

            au fait, si on veut installer spacemacs, le site dit

            git clone https://github.com/syl20bnr/spacemacs ~/.emacs.d

            hmm. y'aurait pas mieux ? bon je veux bien faire un backup de mon emacs.d, tester, remettre, m'enfin pour se donner le temps de tester plus longtemps ça devient embêtant!

            • [^] # Re: Vieux débat (nouvelles réponses?)

              Posté par  (Mastodon) . Évalué à 3. Dernière modification le 24 août 2017 à 10:32.

              $ mkdir ~/spacemacs/
              $ git clone https://github.com/syl20bnr/spacemacs ~/spacemacs/.emacs.d
              $ HOME=~/spacemacs emacs

              sinon tu peux utiliser GNU stow ou d'autres alternatives pour gérer tes dotfiles.

            • [^] # Re: Vieux débat (nouvelles réponses?)

              Posté par  . Évalué à 3.

              t'as des solutions ici: https://www.reddit.com/r/emacs/comments/3ucnnx/trying_out_spacemacs_without_messing_with_my/ et ceci marche pour moi:

              $ cd
$ mkdir fakehome    
$ git clone --recursive https://github.com/syl20bnr/spacemacs ~/fakehome/.emacs.d
$ env HOME=/home/andreas/fakehome/ emacs

            • [^] # Re: Vieux débat (nouvelles réponses?)

              Posté par  . Évalué à 2.

              Allons… un peu d'effort que diantre:

              cd ~/.emacs.d
git init
git commit -Am "initial commit"
git remote add whatever
git branch whatever_test
git checkout whatever_test
git pull whatever
git commit -Am "testing whatever"
git checkout master

              Bon, ok, c'est pas court, et ça marche pas en l'état, mais une adaptation devrait pas être trop longue. En tout cas ça rend le switch de config relativement aisé, voir même un merge partiel ;)

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 4.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Vieux débat (nouvelles réponses?)

          Posté par  . Évalué à 1.

          Elle a l'air très utile cette infographie, je vais retourner à la case "learn how to learn" je crois :D…

          Par rapport à la vidéo sur evil-mode, je suis d'accord ça explique pas énormément de choses. Mais quand même, le gars parle bien, il est dynamique, il fait beaucoup de démo assez impressionnantes (pour un non emacien). Je sais tout ça c'est futile, c'est pour le "hype", mais n'empêche pour quelqu'un (un jeune qui fait du web par exemple :D) qui est sur sublime ou atom, ça donne très envie (j'ai réussi à convaincre une personne dans le genre cette année, avec cette vidéo :-)).
          En tout cas sans evil-mode, je serai pas sur emacs c'est sûr. Et d'ailleurs je suis pas sur emacs, mais spacemacs. Question bête : vous trouvez pas que avoir à presser seulement 'space', c'est pas plus confortable que 'C-c' ?

          Merci pour tous les liens, ça me fait pas mal de tuto maintenant !

          Par rapport à toutes ces vidéos d'ailleurs, un truc génial serait d'avoir des vidéo très condensées, avec beaucoup d'infos, et ne pas "subir" (j'avoue que des fois, les "euh" ou dans le genre, de la personne qui parle, ça m'éééénerve :D) un déroulement plutôt lent.
          Évidemment, si machin, si truc, … ça demande beaucoup de travail et de temps tout ça. (tu dois bien le savoir avec les vidéos de MAO, que je trouve très bien d'ailleurs, elle me donne un point de vue motivant sur qtractor).

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 9.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Vieux débat (nouvelles réponses?)

              Posté par  . Évalué à 1.

              Haha mince, j'oubliais que tout le monde n'est pas sur evil-mode. Parce qu'en 'normal mode' dans evil-mode, presser 'space' c'est hyper naturel (une touche comme ça on peut pas le louper), et rapide.
              Et du coup spacemacs entier est basé la dessus.

    • [^] # Re: Vieux débat (nouvelles réponses?)

      Posté par  . Évalué à 3.

      Oh à propos de journal, j'avais raté ton précédent sur Common Lisp, il est excellent, j'y ai appris plein de choses, merci. Je suppose que tu connais Parens of the Dead mais je pose ça ici quand même.

      yes merci, suis ravi. Avec encore un peu d'abnégation il y aura une suite plus complète :) En tout cas récemment c'est le lisp cookbook qui a pris un coup de jeune (et il en avait bien besoin).

      Nan je connaissais pas Parens of the Dead car je suis pas trop dans Clojure, même si pour le web couplé à Clojurescript ça a l'air bien efficace.

      ce truc devrait être installé et activé par défaut

      aujourd'hui je me dis ça pour les Hydras ! (et blog)

    • [^] # Re: Vieux débat (nouvelles réponses?)

      Posté par  . Évalué à 3.

      une fenêtre est contenue dans un cadre et pas le contraire

      Je n’utilise pas emacs (ni vim d’ailleurs) et n’est pas la moindre foutue idée de ce que l’on entend par « cadre » (frame), ou fenêtre… dans ce logiciel (une zone de sélection « en colonne » peut-être ?), toujours est-il que si on s’en tient à l’analogie avec la fenêtre dans le bâtiment, le cadre est une partie de la fenêtre, donc si, c’est bien le contraire ! :)

      https://fenetre.ooreka.fr/comprendre/fenetre_definition

  • # en fait Emacs est très facile. Enfin le lisp.

    Posté par  (site web personnel) . Évalué à 4.

    je pense que tous les commentaires, vont un peu dans ce sens.

    La puissance de Emacs ce n'est pas que cet outil offre tout, c'est pourquoi cet outil offre tout.
    Pourquoi? eh bien parce passé quelques douleurs au début, lisp est plutôt facile.
    on peut apprendre en customisant un peu des trucs faciles.
    puis, des minis trucs perso.
    on va vite fait de coder un minor-mode, un major-mode, ef paf! on tombe dans la marmite elpa.

    ou du moins, avec lisp on arrivera à peu de frais à faire ce qu'on veut.
    peut être que ce n'est pas le plus performant ou sécure. Par contre ça marche diablement bien.
    c'est pour cela que ces projets d'améliorer la première expérience sont intéressants.

    si je prends par exemple Atom. c'est vraiment juste un exemple. au début on trouve beaucoup plus de choses
    tout de suite. Et puis rapidement ça s'essoufle. Alors on veut lire la doc pour faire ses trucs.
    Et là c'est le drame.

    ou encore Evil. Emacs est maintenant la meilleure implémentation de vim
    (performance à part. Attention aux très gros buffers si vous êtes un robot.)

    il faudrait presque partir d'un emacs vide que l'on se bâtirait brique à brique
    Arch Emacs!

    • [^] # Re: en fait Emacs est très facile. Enfin le lisp.

      Posté par  . Évalué à 2.

      Par rapport à Lisp justement. A quelqu'un qui n'y a jamais touché, comme expliques-tu que ce soit un langage particulièrement adapté à un logiciel comme emacs ?

      Je me pose la question par exemple par rapport à Python. Je pense que Python est beaucoup plus familier pour plus de gens, et il y beaucoup de modules (après Lisp doit en avoir beaucoup aussi).
      J'imagine par exemple qu'avec un "emacs en Python", on pourrait avoir à portée de main des modules comme Numpy, matplotlib (pour citer des scientifiques), pour dessiner un graphe à la volée avec les donnée dans le buffer, ou sûrement pleins d'autres choses plus utiles et puissantes.

      Ou même rust par exemple, penses-tu qu'un "emacs en rust" (avec le même niveau de modularité) serait possible ?

      • [^] # Re: en fait Emacs est très facile. Enfin le lisp.

        Posté par  (site web personnel) . Évalué à 2.

        Déjà il faut noter que le coeur de Emacs c'est du C.
        Le Lisp ce n'est guère que quelques millions de lignes par dessus ouch.

        un éditeur de texte en rust y'en a forcément, si je pioche au hasard :

        http://libs.rs/text-editors/

        en python ça existe aussi forcément.
        pourquoi lisp resterait intéressant? je dirai que dès le début RMS a choisi le language le plus approprié pour un cas bien précis.
        Dès le début il s'agissait d'éditer du texte, et dès le début il s'agissait de pouvoir customiser à gogo.

        mais sous la plume de RMS c'est différent :
        "The most powerful programming language is Lisp"
        (fouiller dans : https://stallman.org/stallman-computing.html)

        après désolé ça sort de mon domaine de compétence.
        il manque des commentaires sur, pourquoi lisp est adapté au texte.
        ce qui est certain est, que lisp s'apprend très facilement.

        voici hello world en lisp

        (insert "Hello!")

        c'est un peu triché, mais voilà l'idée.

        • [^] # Re: en fait Emacs est très facile. Enfin le lisp.

          Posté par  (site web personnel) . Évalué à 2.

          Oui enfin, Lisp était probablement le meilleur choix dans les années 80, quand le logiciel a été conçu. De nombreux langages et concepts modernes n'existaient pas à l'époque ce qui restreignait les choix possibles. Puis dans les années 80 je pense que beaucoup de programmeurs connaissaient le Lisp, aujourd'hui ce n'est plus vraiment le cas.

          Aujourd'hui, je doute que si Emacs devait être écrit de 0 le Lisp serait choisi.

          Et l'avis de RMS est biaisé, il a quand même une culture informatique assez ancienne (cela fait 10-20 ans qu'il ne programme plus vraiment), c'est lui qui a pondu ce gros bébé avec les contraintes et le savoir de son époque. Bref, forcément pour lui, changer autant en profondeur son bébé serait vu comme un crime. ;-)

          Après est-ce que cela vaudrait le coup de tout réécrire maintenant ? Je n'en suis pas sûr. L'écosystème d'Emacs reste important, c'est un gros logiciel complexe et puissant et le gain d'une réécriture serait je pense assez faible par rapport à l'effort que cela demanderait.

          • [^] # Re: en fait Emacs est très facile. Enfin le lisp.

            Posté par  (site web personnel) . Évalué à 2.

            évidemment c'était à l'époque, ça date quand même de 40 piges. En informatique 40 ans çe ne change pas grand chose.
            je pense que réécrire ce serait juste pas possible. d'après ce site merveilleux, https://www.openhub.net/p/emacs/analyses/latest/languages_summary

            nous avons
            - en C : trois cent quarante deux mille lignes
            - en Lips : un million cent quatre vingt neuf mille lignes
            - et si, si , y'a du python ! trois cent lignes.

            déjà Emacs à la fameuse question de passer à un Lisp un peu mieux, et rien que là ça bloque depuis des années,
            et peut être ad vitam

            • [^] # Re: en fait Emacs est très facile. Enfin le lisp.

              Posté par  . Évalué à 1.

              En informatique 40 ans çe ne change pas grand chose.

              Je peux la ressortir quand j'ai envie de dire une connerie à l'avenir?

              nous avons
              - en C : trois cent quarante deux mille lignes
              - en Lips : un million cent quatre vingt neuf mille lignes

              Tout ça pour un éditeur de texte? Sérieux? Je serait fort étonné que le plus gros du code ne soit pas la pour des raisons purement historique, du code quasi-zombie quoi…
              Bon, il doit aussi y avoir l'interpréteur lisp et son API qui pompent, mais même…

              je pense que réécrire ce serait juste pas possible

              Un projet avec autant d'inertie, on ne le réécrit pas, du moins pas sans le forker ou partir sur l'idée de faire un clone. Déjà sur des projets plus petits c'est horrible, mais la, on parle d'un des éditeurs les plus populaires parmi les barbus, et le remplacer mènerait sûrement à des guerres bien plus sanglantes que sysVinit vs systemd.

          • [^] # Re: en fait Emacs est très facile. Enfin le lisp.

            Posté par  . Évalué à 2.

            De nombreux langages et concepts modernes n'existaient pas à l'époque

            de nombreux concepts de lisp ne sont pas présents dans les languages aujourd'hui, tels que Python: le modèle objet (méthodes génériques,…), les hooks ("advice"), la méta-programmation riche (les fameuses macros) (Python avec ses décorateurs et "with statements" fait pâle figure), le fait d'avoir une "lisp machine" est énorme, les reader macros (modification du reader, qui lit le code source, pour créer une nouvelle syntaxe), l'inférence de types, créer une image exécutable standalone, désassembler une fonction, plus d'orientation objet, les closures,… (Cf mon commentaire https://linuxfr.org/nodes/112513/comments/1711088)

            mais pas sûr que elisp serait choisi sur un autre lisp, oui.

          • [^] # Re: en fait Emacs est très facile. Enfin le lisp.

            Posté par  (site web personnel) . Évalué à 2.

            Aujourd'hui, je doute que si Emacs devait être écrit de 0 le Lisp serait choisi.

            Je pense que ce genre de choix dépend beaucoup de la personne ou de l'équipe qui code la première version du logiciel. Ceci dit je pense que le Lisp d'Emacs est objectivement beaucoup plus facile que des langages très populaires aujourd'hui comme le Python ou le JavaScript.

            JavaScript est bourré ~d'idioties~ d'idiosyncrasies, comme la sémantique farfelue des opérateurs de comparaison ou des opérations + et -, c'est aussi un langage à objets – ce qui ajoute de la complexité conceptuelle par rapport à Lisp – et il y a ce fichu mot-clef this qui est mal fagoté.

            Python a aussi des objets, il introduit une syntaxe spéciale pour les listes paresseuses (yield) et a des décorateurs, qui en gros sont aussi puissants que les macros Lisp mais leur syntaxe bizarre les fait passer pour des constructions beaucoup plus élaborées qu'elles ne le sont réellement.

            Après est-ce que cela vaudrait le coup de tout réécrire maintenant ? Je n'en suis pas sûr. L'écosystème d'Emacs reste important, c'est un gros logiciel complexe et puissant et le gain d'une réécriture serait je pense assez faible par rapport à l'effort que cela demanderait.

            Entre passer 1 mois à bien documenter tout ce qu'il faut savoir pour bien utiliser Emacs dans son cas d'utilisation (par exemple pour faire due développement web) et passer 6 ans à tout réécrire, le choix devrait être vite fait. ;)

            • [^] # Re: en fait Emacs est très facile. Enfin le lisp.

              Posté par  . Évalué à 2.

              des décorateurs, qui en gros sont aussi puissants que les macros Lisp

              ah là non, je ne suis pas du tout d'accord !

              • [^] # Re: en fait Emacs est très facile. Enfin le lisp.

                Posté par  (site web personnel) . Évalué à 2.

                Et bien éclaire-moi, cela fait depuis au moins 5 ans que je ne fais plus de Python, mais dans mon souvenir les décorateurs (ou bien cette notation @@ ou semblable) permet de faire beaucoup de choses en meta-programmation. Est-ce que par exemple tu pourrais citer 2-3 choses qui sont relativement faciles à faire avec des macro Elisp et totalement impensables avec la meta-programmation de Python? Merci! :)

        • [^] # Re: en fait Emacs est très facile. Enfin le lisp.

          Posté par  . Évalué à 5.

          Emacs en Rust ? Remacs ! https://github.com/Wilfred/remacs où Rust remplace le C, lisp inchangé. (cf mon commentaire plus bas sur lisp VS python)

          • [^] # Re: en fait Emacs est très facile. Enfin le lisp.

            Posté par  . Évalué à 3.

            Impressionnant !
            En espérant qu'il s'intéresse aussi à l'un des problèmes d'Emacs, faire en sorte qu'il devienne multi-thread. Mais bon, cela ne touche pas que le cœur en C d'Emacs.

      • [^] # Re: en fait Emacs est très facile. Enfin le lisp.

        Posté par  . Évalué à 4.

        Emacs en Rust, mais oui mon ami ! https://github.com/Wilfred/remacs Où Rust remplace le C, mais où le elisp est inchangé. Ce n'est pas un fork, bonne chose à noter.

        J'ai écrit quelques paquets elisp, j'ai mon avis sur elisp VS python. Clairement Python est plus populaire, mais il me paraît totalement inadapté au rôle que remplie le lisp. Lisp permet d'avoir une "lisp machine", où on peut évaluer du code dans le process en cours qui devient disponible de suite. En Python, on écrit et on relance l'appli. Elisp et d'autres lisps permettent de définir une fonction qui soit exécutée juste avant, juste après ou à la place d'une autre (les "advice"). C'est ce qui permet d'implémenter les hooks par exemple, et c'est beaucoup utilisé en général. Ça permet d'écrire facilement des extensions à un paquet, sans avoir à le modifier. En Python (ou autres), il n'y a pas ça par défaut. De manière similaire certains frameworks proposent des signaux (pre-save, post-save,…). De manière générale la méta-programmation en lisp est plus riche et complète, de par le module objet, ces hooks, et grâce aux parenthèses (le code est une liste, facile à manipuler), alors que vas-y pour manipuler l'ast de python. Des trucs comme ça.

        Plus concrètement, je me demande comment on ferait pour taper du python, sensible à l'indentation, dans le mini-buffer ! Alors qu'en lisp tu regardes le matching des parenthèses.

        Enfin notons qu'on peut écrire des extensions qui utilisent en sous-main des paquets python, en l'installation elles-mêmes à l'endroit qui va bien, etc (emacs-traad,…).

        Et que Emacs25 supporte les Xwidgets, donc on peut imaginer voir ces trucs plus puissants (encore que, moi je préfère manipuler du texte qu'un widget graphique à la souris).

        • [^] # Re: en fait Emacs est très facile. Enfin le lisp.

          Posté par  . Évalué à 0.

          Effectivement ma question ne portait pas sur le langage dans lequel est écrit l'interpréteur, mais bien le langage qu'interprète l'interpréteur.

          Je pense par exemple à Blender. Il me semble (presque sûr quand même) que l'interface est en python, et ça appelle la partie en C++ au travers de l'API du logiciel. On peut customiser à la volée une partie de l'interface en faisant "clic droit" + "edit source", et là on arrive direct sur le code python. Pareil pour toutes les actions, ce sont des fonctions python qui utilisent l'API derrière.

          Atom ça doit être un peu pareil d'ailleurs mais avec du JS.

          Après comme tu me le dis, Python n'a apparemment pas toute la puissance d'expression du Lisp, et une syntaxe avec indentation uniquement.

          Pour le rust, je pensais bel et bien au langage d'extension :D. C'est pas possible de compiler du rust à la volée, le charger dynamiquement et l'executer ? Et puis c'est un langage plutôt très expressif. Après c'est peut-être totalement overkill et pas facile facile à apprendre.

          Enfin bref, qu'importe le langage, ça serait un gigantesque travail de tout porter, et peut-être pas très utile.

          • [^] # Re: en fait Emacs est très facile. Enfin le lisp.

            Posté par  . Évalué à 2.

            Enfin bref, qu'importe le langage, ça serait un gigantesque travail de tout porter, et peut-être pas très utile.

            Je ne commenterai pas sur le les avantages de lisp vs. python, il y aurait sûrement des tonnes de trucs à faire partir en cacahuète, par contre j’imagine qu’emacs se traîne des pelletées de code historique et que ça doit pas être méga simple de faire du nettoyage. Dans ces conditions se reposer des questions de design pourrait peut être bénbfique pour coder enfin emacsOS. Mais ptete que jme goure et que c’est proprifié de génération en génération de dinosaure.

    • [^] # Re: en fait Emacs est très facile. Enfin le lisp.

      Posté par  . Évalué à 2.

      ou du moins, avec lisp on arrivera à peu de frais à faire ce qu'on veut.

      Je viens de tilter… Lisp… le nom, ce serait pas parce qu'on a l'impression qu'il y a des lips un peu partout quand on l'utilise?

      Oui, je m'ennuie, je suis au bureau, il pleut, et on est trolldi :)

Suivre le flux des commentaires

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