Journal Les doutes d'un gars qui écrit: sérieusement se mettre à Emacs, ou pas ?

Posté par  (Mastodon) . Licence CC By‑SA.
Étiquettes :
17
10
mai
2021

Cher Journal

Nous ne nous connaissons pas encore très bien, toi et moi. J'espère pourtant que tu pourras néanmoins me faire profiter de tes lumières sur un sujet ô combien trollesque qui ne l'est pourtant pas pour moi.

Depuis toujours, pour écrire j'utilise Microsoft Word (j'ai aussi utilisé Scrivener) et, depuis mon passage à Linux, LibreOffice Writer. À côtw de ça, j'utilise aussi un éditeur de texte + Markdown, pour blogger ou pour écrire des trucs en ligne.

En switchant sur Linux, je me suis fait la promesse de tenter de tout écrire dans un éditeur de texte, y compris la fiction. Par curiosité, par goût de tenter de nouvelles choses, mais aussi motivé à l'idée de pouvoir tout gérer dans des fichiers TXT, et d'apprendre à utiliser Git (pour le contrôle de versions des manuscrits).

Mon éditeur de texte par défaut, c'est VisualStudio Code (en réalité, j'utilise son fork VSCodium, mais c'est la même chose sauf quelques réglages par défaut qui sont plus respectueux de la vie privée). VSCode est simple d'emploi, on trouve à peu près un gazillion et demi d'extensions simples à installer et a configurer, dont certaines vachement sympa pour écrire, et on n'a pas besoin de tout réapprendre à zéro juste pour commencer a l'utiliser… Un outil de plus, dans la boite à outils, quoi.

Évidemment, en faisant quelques recherches, je suis tombé sur des auteurs qui travaillent aussi avec des fichiers texte. Plusieurs d'entre eux recommandant d'utiliser Vim ou Emacs. Je connaissais de nom ces deux légendes mais ne les avais jamais utilisés jusqu'ici. J'ai donc décidé de m'y mettre, en commençant avec Emacs. Yolo, comme disent les plus jeunes.

Cela fait un peu plus de quinze jours de ça.

Si je suis bluffé par les possibilités d'Emacs, je suis au moins autant effrayé par sa complexité. La complexité de sa configuration et la quantité de docs et de tutos (qui ne disent pas tous la même chose). Par la simple difficulté qu'il y a à commencer à l'utiliser : Emacs ne fait absolument rien comme les autres. Oui, j'ai pigé : c'est normal, Emacs est le plus ancien de tous, mais ça change pas la violence du choc, ni que tout ou presque (même des choses simples) doive être configuré manuellement, via un langage de programmation qui — là encore, j'ai pigé l'idée — fait sa force proprement stupéfiante.

Mais c'est cette puissance, inutile au débutant que je suis, qui rend tellement difficile de d'apprendre et de progresser. Du moins, pour moi tout semble si complexe…

C'est vrai, il suffit de lire la doc et de faire qqes recherches pour souvent trouver une solution qui, a défaut d'être optimale, marche. Mais toutes ces heures passées en recherche et en bidouilles… Le but de petit journal d'humeur n'est pas de taper sur Emacs : il est incroyable. Le but, c'est de dire mon incertitude sur ce que je dois faire : est-ce que apprendre Emacs en vaut la peine quand on n'est pas un développeur ?

Lorsque je vois ce que certain(e)s auteur(e)s arrivent à faire avec Emacs, j'ai envie de dire oui ! Il est carrément génial, c'est l'outil parfait ! Mais quand je vois le temps déjà passé (et les efforts faits) pour n'arriver que là où j'en suis (càd, pas très loin). Et quand j'essaye d'estimer le temps que je vais encore devoir passer avant d'arriver là où j'en suis avec mes outils habituels, mon 'oui' enthousiaste d'il y a un instant se transforme en un Euh… j'sais pas. J'sais plus.

Depuis quinze jours et qqes que j'ai commencé, j'ai le sentiment d'avoir énormément progressé et en même temps d'avoir si peu avancé que je me demande si je ne recule pas. "La route est longue", nous rappelle Framasoft… Je ne l'ai jamais aussi bien ressenti que depuis que j'ai pris le chemin Emacs ;)

  • # Remarques

    Posté par  . Évalué à 9.

    VisualStudio Code (en réalité, j'utilise son fork VSCodium, mais c'est la même chose sauf quelques réglages par défaut qui sont plus respectueux de la vie privée)

    Ce n'est pas que de la configuration, il y a des choses en moins pour ne pas pister les utilisateurs.

    Oui, j'ai pigé : c'est normal, Emacs est le plus ancien de tous,[…]

    vim (ou plus précisément précurseur vi) est bien plus ancien :p

    Lorsque je vois ce que certain(e)s auteur(e)s arrivent à faire avec Emacs, j'ai envie de dire oui !

    Tu pense à quoi ?

    Personnellement il ne me semble pas que ce soit d'une grande utilité pour du travail rédactionnel « pure ». On travail bout par bout et on a pas le coté accès aléatoire aux fichiers qui demandent à faire des sauts réguliers. Il me semble que le gros du besoin c'est de travailler les paragraphes, les phrases et les mots. Probablement de mettre en évidence de la recherche pour notamment regarder les répétitions.

    Mais quand je vois le temps déjà passé (et les efforts faits) pour n'arriver que là où j'en suis (càd, pas très loin). Et quand j'essaye d'estimer le temps que je vais encore devoir passer avant d'arriver là où j'en suis avec mes outils habituels, mon 'oui' enthousiaste d'il y a un instant se transforme en un Euh… j'sais pas. J'sais plus.

    Il ne faut pas partir de l'idée que l'on va maitriser des outils comme emacs ou vi pour s'en servir. Il faut commencer à s'en servir et petit à petit apprendre à utiliser leurs raffinements. C'est pour ça que ce sont des choix qui se font en années. De temps en temps ou par exemple pour un nouvel usage, tu ajoute une nouvelle arme à ton attirail.

    C'est aussi pour ça que les utilisateurs de ses outils veulent capitaliser au maximum sur leurs outils non seulement c'est dommage de ne pas réutiliser autant d'effort mais en plus s'ils ont mis autant de personnalisation c'est que c'est devenu la manière la plus efficace de manipuler du texte pour eux.

    Chercher à se comparer a des gros utilisateurs ce serait comme dire « j'aimerais bien me mettre au vélo mais quand je vois la différence entre moi et Lance Armstrong, je me dis qu'il me reste beaucoup d'entrainement ».

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Remarques

      Posté par  (Mastodon) . Évalué à 1.

      vim (ou plus précisément précurseur vi) est bien plus ancien :p
      Je ne savais pas, j’avais cru comprendre le contraire. Merci pour la précision;)

      Tu pense à quoi ?

      Là à rien ni personne de précis, mais je peux faire un petit tour des trucs que j'ai trouvés intéressants. Faut juste reprendre mes notes.

      Chercher à se comparer a des gros utilisateurs ce serait comme dire « j'aimerais bien me mettre au vélo mais quand je vois la différence entre moi et Lance Armstrong, je me dis qu'il me reste beaucoup d'entrainement ».

      Je comprends ça. Ce n'était pas mon objectif , désolé pour la confusion ;)

      Disons que je compare plutôt l'usage (basique) que j'ai d'un VSCode, avec ce que je réussi à faire dans Emacs (et tout ce que je n'arrive pas à faire, ou moins bien). Je compare aussi le temps de formation que leur utilisation exige (à défaut d'un terme plus adéquat).

      Sans doute, c'est le point de départ de mes hésitations: si je suis toujours heureux d'essayer de nouveaux trucs, je n'avais pas du tout prévu d'investir des années dans l’apprentissage d’Emacs en tant qu'outil — je suis plus que ok pour imaginer y passer ces années pour y écrire, par contre  (y a pas mal de choses que je trouve géniales) mais, vraiment : pour y écrire, pas pour apprendre à l’utiliser.

      Il ne faut pas partir de l'idée que l'on va maitriser des outils comme emacs ou vi pour s'en servir. Il faut commencer à s'en servir et petit à petit apprendre à utiliser leurs raffinements.

      C'est ce que j'ai commencé a piger, en réalisant que la façon dont je m´étais lancé était foireuse : je ne pouvais pas juste apprendre a utiliser Emacs pour écrire, ni certaines de ses fonctionnalités plus avancées, fallait d’abord apprendre à utiliser Emacs tout court. Pas le même objectif, pas le même investissement non plus.

      je vais continuer à apprendre Emacs encore un peu (y a vraiment trop de trucs qui me bottent), et on verra.

      Merci encore ;)

      • [^] # Re: Remarques

        Posté par  . Évalué à 3.

        fallait d’abord apprendre à utiliser Emacs tout court

        Un des "trucs" que j'ai fait pour faciliter l'apprentissage, c'est de l'utiliser pour une tâche simple récurrente : la rédaction de mail (ça marche aussi pour vim, évidemment).

        Il n'y a pas besoin de connaître grand chose (sauf si on veut mettre des images, du rouge italique gras surligné en fluo clignotant), et ça force un peu à utiliser la netiquette au passage.

        Matricule 23415

        • [^] # Re: Remarques

          Posté par  (Mastodon) . Évalué à 4.

          Un des "trucs" que j'ai fait pour faciliter l'apprentissage, c'est de l'utiliser pour une tâche simple récurrente : la rédaction de mail (ça marche aussi pour vim, évidemment).

          Pareil, ou presque : le premier truc que j'ai fait c'est de me 'forcer' a utiliser Emacs pour tenir mon journal quotidien> C'est court, simple mais ça permet de faire rentrer les raccourcis de base dans les doigts.

          Là, j'en suis à utiliser Org pour rédiger le brouillon d'une petite histoire, en quinze chapitres dans un seul fichier .org. Je suis sur le cul devant le confort qu'offre Org pour de l'écriture non-linéaire (navigation dans le texte, le simple fait de pouvoir insérer des commentaires à soi-même dans le texte, en sachant qu'ils ne seront pas exportés par défaut,…), et aussi par son efficacité (le contrôle sur l'exportation, les raccourcis claviers,…). Faut juste d'abord réussir à faire marcher Emacs comme on le souhaite ;)

    • [^] # Re: Remarques

      Posté par  . Évalué à 5. Dernière modification le 10 mai 2021 à 12:58.

      mais quand je vois la différence entre moi et Lance Armstrong, je me dis qu'il me reste beaucoup d'entrainement qu'il me reste beaucoup de piqures à faire

      • [^] # Re: Remarques

        Posté par  (Mastodon) . Évalué à 6.

        Si tu ne t'entraines pas les piqûres ne servent pas à grand chose cela-dit.

      • [^] # Re: Remarques

        Posté par  . Évalué à 5.

        Tu veux te faire pousser des doigts ?

      • [^] # Re: Remarques

        Posté par  . Évalué à 3.

        Et t'acheter un vélo à 8~16k€.

        Mais il n'a besoin de rien pour mettre une race au commun des mortels.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # historiques

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

      Oui, j'ai pigé : c'est normal, Emacs est le plus ancien de tous,[…]

      vim (ou plus précisément précurseur vi) est bien plus ancien :p

      J'aurais juré que les deux sont de la même génération… Alors, je suis allé vérifier ce qu'en dit la fiche Wikipedia

      Richard Stallman began work on GNU Emacs in 1984 to produce a free software alternative to the proprietary Gosling Emacs. GNU Emacs was initially based on Gosling Emacs, but Stallman's replacement of its Mocklisp interpreter with a true Lisp interpreter required that nearly all of its code be rewritten. This became the first program released by the nascent GNU Project. GNU Emacs is written in C and provides Emacs Lisp, also implemented in C, as an extension language. Version 13, the first public release, was made on March 20, 1985. The first widely distributed version of GNU Emacs was version 15.34, released later in 1985. Early versions of GNU Emacs were numbered as 1.x.x, with the initial digit denoting the version of the C core. The 1 was dropped after version 1.12, as it was thought that the major number would never change, and thus the numbering skipped from 1 to 13.

      La première publication (pas le début d'écriture) de GNU Emacs est de 1985 ; et je pense que c'est à cette date qu'il est fait allusion ici. Car il ne faut pas oublier les « early implementations »

      In the following years, programmers wrote a variety of Emacs-like editors for other computer systems. These included EINE (EINE Is Not EMACS) and ZWEI (ZWEI Was EINE Initially), which were written for the Lisp machine by Mike McMahon and Daniel Weinreb, and Sine (Sine Is Not Eine), which was written by Owen Theodore Anderson. Weinreb's EINE was the first Emacs written in Lisp. In 1978, Bernard Greenberg wrote Multics Emacs almost entirely in Multics Lisp at Honeywell's Cambridge Information Systems Lab. Multics Emacs was later maintained by Richard Soley, who went on to develop the NILE Emacs-like editor for the NIL Project, and by Barry Margolin. Many versions of Emacs, including GNU Emacs, would later adopt Lisp as an extension language.

      James Gosling, who would later invent NeWS and the Java programming language, wrote Gosling Emacs in 1981. The first Emacs-like editor to run on Unix, Gosling Emacs was written in C and used Mocklisp, a language with Lisp-like syntax, as an extension language.

      La première version Unix, qu'on doit à l'un des pères de Java, date lui de 1981.
      Et il existait déjà une implémentation même pour Multics alors que Vi est apparu avec un BSD…
      Outre Multics, les Emacs-like ont été présents dans de nombreux vieux systèmes temps partagés historiques.

      The original Emacs, like TECO, ran only on the PDP-10 running ITS. Its behavior was sufficiently different from that of TECO that it could be considered a text editor in its own right, and it quickly became the standard editing program on ITS. Mike McMahon ported Emacs from ITS to the TENEX and TOPS-20 operating systems. Other contributors to early versions of Emacs include Kent Pitman, Earl Killian, and Eugene Ciccarelli. By 1979, Emacs was the main editor used in MIT's AI lab and its Laboratory for Computer Science.

      Oui, Emacs remonte au PDP-10 avec ITS en 1976, comme il est dit en introduction.

      The original EMACS was written in 1976 by David A. Moon and Guy L. Steele Jr. as a set of Editor MACroS for the TECO editor. It was inspired by the ideas of the TECO-macro editors TECMAC and TMACS.

      Là, on pourrait penser que Emacs est l'aîné de Vi… bien que n'ayant mis les pieds dans Unix que plus tard (en 1981.) Mais l'autre fiche Wikipedia m'indique la même année de naissance sous son autre nom :

      The original code for vi was written by Bill Joy in 1976, as the visual mode for a line editor called ex that Joy had written with Chuck Haley. Bill Joy's ex 1.1 was released as part of the first Berkeley Software Distribution (BSD) Unix release in March 1978. It was not until version 2.0 of ex, released as part of Second BSD in May 1979 that the editor was installed under the name "vi" (which took users straight into ex's visual mode), and the name by which it is known today. Some current implementations of vi can trace their source code ancestry to Bill Joy; others are completely new, largely compatible reimplementations.

      Là où t'as raison, c'est si on se limite strictement au système Unix-like en résumant que la commande vi date de 1979 et la commande emacs de 1981.
      Désolé pour le pavé, je suis un peu fan d'histoire d'informatique.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: historiques

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

        J'imagine que c'est l'antériorité qui fait que vim est disponible de base à peu près partout par défaut, là où il faut souvent installer emacs.

        • [^] # Re: historiques

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

          C'est à la fois simple et poil plus compliqué.

          Simple : comme j'essaye de le montrer, les deux sont nés à la même année… Mais Vi est né directement sous Unix et a en prime été directement popularisé par BSD (après tout c'est créé sur le campus de Berkeley) tandis que Emacs a surtout fait sa vie sur les LispMachine et n'est apparu sous Unix qu'avec le portage de Goslin. De là ma conclusion :

          […] si on se limite strictement au système Unix-like en résumant que la commande vi date de 1979 et la commande emacs de 1981.

          Complexe : il y a aussi un certain nombre de facteurs qui ne jouent pas en faveur de Emacs par défaut

          • Un système compatible Unix au sens POSIX doit fournir un certain nombre de commandes au nombre desquels vi. En fait Vi c'est Ex (en mode visuel/plein-écran) et ex étend Ed, l'éditeur original du système auquel il reste donc compatible de façon ascendante.
          • En plus des programmes par défaut (pour les administrateurs systèmes et les développeurs), pendant longtemps (en fait tant qu'on n'était pas dans l'optique « Linux sur le poste de travail ») on essayait d'avoir un système qui prend très peu de place sur disque (histoire que le support, cher, puisse servir à plus de données usagers) et des programmes qui prennent peu de place en mémoire (celle-ci étant une denrée peu courante aussi) Du coup, Emacs est plutôt un luxe… Plus tard, quand on a pu se permettre d'avoir des trucs lourds installés de base, par rapport à la cible (bureautique et loisir), d'autres ont eu la priorité (fureteur web, suite bureautique, lecteurs médias, etc.)
          • Le public qui aurait pu être intéressé a souvent suivi d'autres modes (Eclipse, Atom, VSCodium, etc.) qui font que dans les distributions qui tiennent des statistiques pour savoir ce qu'il faut installer de base ne voient pas ces outils (LaTeX par exemple a le même souci de taille que ce cher Emacs) comme des besoins de base. De plus, le public qui les utilise sait souvent comme les mettre en place (et on se mord la queue)
          • Etc.

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: historiques

          Posté par  . Évalué à 4.

          Le 'poids' aussi, c'est difficile a croire aujourd'hui mais à une époque Emacs était considéré comme un éditeureur 'lourd' (eight megabytes and constantly swapping) et ce n'est pas un mythe ou une méchanceté 'gratuite': quand j'étais en thèse une bonne façon de décoller quelqu'un de sa machine était de se connecter sur sa machine et de lancer emacs: le gars ne pouvait plus rien faire pendant un petit moment donc il venait manger..
          Donc a cette époque là forcément vi était partout mais pas emacs et c'est resté..

      • [^] # Re: historiques

        Posté par  . Évalué à 4. Dernière modification le 14 mai 2021 à 00:17.

        Pour l'anecdote, Gosling raconte que Stallman lui a "piqué" tout "son" Emacs.

        Stallman a une version différente, le LL était moins théorisé/formalisé et la position de Gosling sur Emacs a été semble-t-il changeante et peut-être même tentant de revendiquer rétroactivement le copyright alors qu'il y avait déjà d'autres contributeurs (et peut-être pas de CLA), la quantité de code provenant de Gosling pourrait avoir été bien moindre que ce que prétend ce dernier - et surtout il a été remplacé dès qu'il y a eu un doute, enfin les seules éléments de preuves avancés par Gosling sont très indirects (du style "d'autres ont été condamnés, mais Stallman il a pas de tunes et il se lave pas, on l'a pas attaqué").

        Enfin bon l'anecdote a un intérêt historique, y compris dans la création de la GPL.

        • [^] # Re: historiques

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

          Ce qui est marrant, c'est que c'est RMS qui a écrit nombre des macros qui ont été repris dans les Emacs de l'époque que Gosling a copié. C'est aussi Stallman qui a formalisé la majorité des raccourcis pour E (c'était le nom de la commande que son labo utilisait) et qui ont été repris par tout le monde. La seule vraie idée qu'il a piqué est celle de l'interpréteur Lisp (et l'écriture du cœur en C ?), et même là c'est juste l'idée puisqu'ils sont parti sur l'idée de créer ELisp et non d'utiliser MLisp qui était limité par rapport à un vrai MacLisp.

          Gosling ayant retourné sa veste pour le pognon n'est pas très crédible pour moi. C'est d'ailleurs la libre diffusion avant la vente-et-fermeture qui a donnée quelques alternatives intéressantes et cette privateurisation est effectivement « un évènement majeur dans l'histoire du mouvement du logiciel libre »
          Avec ce genre d'attaques et de réécriture de l'histoire il baisse dans l'estime général. Par ailleurs, l'histoire de RMS est corroborée par plusieurs témoignages de l'époque.

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: historiques

        Posté par  (Mastodon) . Évalué à 6.

        Désolé pour le pavé, je suis un peu fan d'histoire d'informatique.

        Tu en veux du pavé ? Alors voilà : https://www.jwz.org/doc/lemacs.html

      • [^] # Re: historiques

        Posté par  . Évalué à 2.

        J'oublie toujours qu'emacs n'est pas n'ait avec gnu emacs. Ce qui est frappant c'est qu'aujourd'hui, il n'existe quasiment plus que l'implémentation gnu, non ? Tous les trucs comme xemacs sont basés sur la version gnu.

        Alors qu'il existe plusieurs implémentations de vi (ne serais-ce titre vim et neovim).

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: historiques

          Posté par  (site web personnel, Mastodon) . Évalué à 1.

          Tout dépend de l'environnement dans lequel on travaille… Il va de soi que sous GNU/Linux on ne trouve de base que GNU Emacs (c'est pour ça que c'est un système GNU…) Sur de plus anciens Unix-like où ce ne sont pas les outils GNU qui sont installés par défaut, on pourrait trouver d'autres variantes, mais il est claire que Gosling Emacs a quasiment disparu.
          Ainsi, les gens qui travaillent sous Minix connaissent mieux Elle (récursivement Elle Looks Like Emacs) ; tandis que les utilisateurs des DOS utilisaient Freemacs
          Ceci dit, sous Linux, on a bien d'autres implémentations qui visent souvent un objectif de régime (donc un Emacs brut mais pas extensible) : mg (µGNU Emacs …alternative libre à microEmacs dont c'est une fourche et qui n'est GNU mais veut s'en rapprocher fonctionnellement), JOE (récursivement Joe's Own Editor), JOVE (récursivement Jonathan's Own Version of Emacs), ZILE (récursivement Zile Is Lossy Emacs), et certainement d'autres que je ne connais pas.
          Pour XEmacs c'est un peu normal que ce soit basé sur GNU Emacs car c'en est une fourche qui par la suite s'est réconciliée pour en devenir la version X Windows… Dans le même esprit, il y a Aquamacs pour Cocoa (Mac OS X).

          Pour Vi il existe certes plusieurs implémentations, mais sous GNU/Linux on ne trouve plus beaucoup de choix non plus : NVi (présent par défaut dans les BSD et le plus proche du logiciel initial, les distros du manchot lui préfèrent Tiny-ViM/ViM-Tiny qu'importe comment chacun le nomme), ViM (décliné en version minimale évoqué précédemment, complète normale en console, complète et étendue parfois, complète normale pour X sous le nom de gViM), Elvis (présent par défaut dans Minix et autrefois précurseur avant de se laisser distancer par ViM), NeoViM n'est qu'une fourche de ViM, JOE…

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # RMS innocent

        Posté par  . Évalué à 2.

        Emacs remonte au PDP-10 avec ITS en 1976

        Ce n’est pas lui qui a commis l’« ergonomie » d’emacs !

        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

        • [^] # Re: RMS innocent

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

          Ce que je veux dire, c'est que Emacs en tant que logiciel distinct (en fait, comme une suite bureautique ou une distribution système, c'est une suite cohérente et ergonomique de Macros et de configurations autour de TECO) est bien présent dès 1976 dans ITS. Les fondements n'ont quasiment pas changé depuis.

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # Gaffe aux TMS

    Posté par  . Évalué à 7. Dernière modification le 10 mai 2021 à 13:04.

    Attention, la conf par défaut d'Emacs n'est pas top pour l'ergonomie. Ça oblige à utiliser trop fréquemment le petit doigt gauche. C'est préférable de la changer. Il existe même une entrée dans le wiki à ce sujet.
    À titre d'anecdote, c'est à cause d'une tendinite à l'auriculaire gauche que j'étais passé à Vi pendant mes études. Donc faites attention si vous avez les tendons fragiles.

    • [^] # Re: Gaffe aux TMS

      Posté par  (Mastodon) . Évalué à 2.

      Je lis ça avec la main gauche dans une attelle… Bon, je vais allez voir comment changer ça ;)

  • # L’autonomie a un coût

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

    (Je n’utilise Emacs que pour coder, prendre des notes, et gérer mes listes de tâches)

    Comme le dit Prot dans son long article de blog sur sa découverte d’Emacs (https://protesilaos.com/codelog/2021-04-16-emacs-moral-lessons/), l’autonomie et la prise de contrôle sur ses outils a un coût en temps qui est incompressible. Mais je suis de l’avis que c’est un chemin qui vaut le coup, en tout cas pour ce que j’en fais aujourd’hui.

    Le principal conseil que je peux donner, c’est de ne pas essayer de vouloir "tout faire" d’un coup (le champ des possibles est justement infini ici, et on se perd très vite), mais plutôt repartir de ses besoins à chaque fois pour orienter ses recherches et apprendre/trouver l’astuce qui te rendra service.

    Il y a une liste de diffusion/discussion francophone sur Emacs, avec une rencontre (en ligne par les virus qui courent) mensuelle où toutes les questions peuvent être posées en tout cas : https://www.emacs-doctor.com/

    Sinon lire le manuel d’Org-mode ou voir la documentation en ligne (et divers tutoriels qui peuvent t’intéresser https://orgmode.org/worg/org-tutorials/index.html ) peut être une bonne idée pour trouver des petites fonctions à picorer ; j’ai l’impression que toutes les personnes que je vois passer qui veulent faire de la prose avec Emacs utilisent Org au final. Je ne l’utilise que pour mes notes et mes tâches, mais l’organisation hiérarchique et ses extensions sans fin ont l’air de bien correspondre aux besoins d’écriture

    • [^] # Re: L’autonomie a un coût

      Posté par  . Évalué à 4.

      Concernant Org-mode, linuxfr a publié des traductions des tutoriels :
      https://linuxfr.org/tags/org_mode/public

    • [^] # Re: L’autonomie a un coût

      Posté par  (Mastodon) . Évalué à 2. Dernière modification le 10 mai 2021 à 13:38.

      J'ai commencé à utiliser Org pour gérer mes notes et pour écrire (si, si, j'ai lu et relis la doc ;)). Pour un utilisateur de longue du Markdown tel que moi c'est inpresionnant ce qu'il offre et son intégration dans Emacs le rend particulièrement plaisant à utiliser. Org-mode est une des choses qui me séduit le plus dans Emacs, à vrai dire.

      Merci pour les liens, je vais m'abonner à la liste Emacs (je connais déjà un peu le travail de Prot, ainsi que ses tutos vidéo, mais j'ai pas encore eut le temps d'y plonger à fond) :)

  • # J'ai déjà ressenti ça ....

    Posté par  . Évalué à 4.

    J'ai ressenti ça lorsque j'ai vu ce qu'était Ruby on Rails. J'ai rapidement compris l'intérêt de l'outil et j'ai essayé de m'y mettre. Cependant j'ai pris le problème dans le mauvais sens. J'ai essayé de faire des trucs en Rails sans connaitre suffisamment Ruby (ce serait comme faire du SpringBoot sans connaître Java, ou du React ou NodeJS sans connaitre JAvaScript ). Certains côté "magiques" de Rails m'ont échappé, et j'étais assez frustré de ne pas réussir à faire ce que je voulais de manière simple.

    Ce qu'il faut savoir, c'est qu'Emacs c'est bien plus qu'un éditeur de texte. C'est un environnement à part entière. Je ne dis pas "environnement de programmation" mais "environnement" : c'est un environnement à tout faire. Il a ses propres règles et codes qui n'ont rien à voir avec les autres types d'éditeurs (vim c'est un peu la même chose - mais en moins complexe que emacs - de mon point de vue).

    Du coup comme dit par ailleurs, il faudrait que tu commeces par éditer des trucs simples pour comprendre les bases, pour ensuite pouvoir apprécier la puissance d'"Emacs. Et surtout te dire qu'un Emacs avec le nécessaire pour éditer deu code sera probablement bien différent qu'un Emacs configuré pour éditer du texte (LaTeX ou Md par exemple) - et que l'Emacs que toi tu utiliseras sera probablement différent de l'Emacs qu'une autre personne avec des besoins similaires utilisera ( parce que vous l'aurez personnalisé différemment).

  • # Spacemacs

    Posté par  . Évalué à 3.

    Personnellement, depuis que je suis passé à Spacemacs, je passe beaucoup moins de temps à configurer Emacs.

    Et je fais de plus en plus de choses avec Org Mode.

    Et pandoc.

    Le principal est de se faire plaisir.

    • [^] # Re: Spacemacs

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

      J'ajouterais la mention de Doom Emacs, qu'à titre personnel, je préfère.

      Chacun a l'approche qui lui plaît, mais je ferais, si j'étais débutant, attention à ne pas trop passer de temps à configurer Emacs. Aussi plaisant celui peut-il être, cela peut être extrêmement chronophage. J'ai, au début de mon utilisation, passé énormément de temps à le configurer pour ensuite me rendre compte que :
      - en utilisation réelle, quotidienne, certaines choses basiques ne fonctionnaient pas ou m'étaient inconnues : je ne m'étais pas concentré sur l'essentiel
      - d'autres avaient déjà fait ce que je voulais faire, beaucoup mieux et avec beaucoup plus de talent

      (et je dis ça en étant un grand fan de Prot :)

      • [^] # Re: Spacemacs

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

        Pareil, je suis passé à doom et depuis je ne configure presque plus rien, j'ai pas mal gagné de temps et j'ai un emacs bien configuré globalement avec plein de fonctionnalités.

        Le principal problème d'emacs ou vim je trouve c'est qu'une fois que l'on est habitué, c'est insupportable d'utiliser autre chose pour écrire du texte. Tout devient lent et laborieux.

        • [^] # Re: Spacemacs

          Posté par  . Évalué à 4.

          Emacs a un avantage ici, car pour sauver, <Ctrl>+X <Ctrl>+S ce qui sous un éditeur de texte officiel dans de nombreuses entreprise sauve le document.
          Moi qui utilisait principalement vim à l’époque, j’ai eu comme remarque lors de relecture de document : « Enlever les :w »…

      • [^] # Re: Spacemacs

        Posté par  . Évalué à 4. Dernière modification le 11 mai 2021 à 05:56.

        Ces distribs sont sans doute bien mais quand tu débutes emacs je pense que c'est pas mal de commencer par écrire sa propre configuration pour comprendre un petit peu le fonctionnement de la chose.Quand tu as une distrib qui arrive avec plus de 100 paquets c'est vite chaud de comprendre lequel sert à quoi. Personnellement j'ai suivi les tutos de cet américain : https://www.youtube.com/watch?v=74zOY-vgkyw et j'ai trouvé ça vraiment cool. (Je débute depuis seulement 1 mois.)

        • [^] # Re: Spacemacs

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

          Pour les anglophones (et amateurs de vidéo, ce que je ne suis pas), je recommande fortement la chaîne System Crafters, dont tu as mentionné une vidéo. Son auteur propose notamment une introduction à l'Emacs Lisp assez bien faite - j'espère qu'il aura le temps d'en faire une retranscription.

  • # Oui

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

    Oui, je t'encourage à passer à Emacs ou Vim (peut-être même que je mets Emacs juste parce que je n'ai jamais eu le courage de passer à Vim…)

    Je l'utilise pour tout ce qui ressemble à du texte. Que ce soit du code, un livre, des fichiers de config, quelques notes prises à la volée.

    J'ai utilisé des IDE (notamment Eclipse, des trucs de JetBrains, VS Code), j'ai utilisé d'autres éditeurs (notamment Gedit, nano, Notepad++), et j'ai utilisé du wisiwyg (notamment Word, LibreOffice). J'en reviens toujours à Emacs. J'apprécie en particulier d'avoir tout sous les doigts, dès lors que j'ai trouvé le raccourci ou la commande. Les fonctions de recherche et de remplacement sont géniales, la complétion dans n'importe quel document est bien confortable.

    Le top du top pour moi est sûrement le côté épuré. Pas de barre d'outil encombrée, pas d'arborescence de fichiers, pas de barre d'onglets qui déborde, pas de minimap, pas de notif, pas de « attends je build des trucs en arrière-plan, reviens dans dix minutes », pas de barre de progression, pas de popup recouvertes de cases à cocher. Pas de caractères '}' ou '"' qui poppent sans que je les demande. Tous ces trucs pour Augmenter La Productivité™, très peu pour moi, merci. Quand j'ouvre Emacs je commence à faire ce que je suis venu faire dès la première seconde, et je ne touche plus à la souris jusqu'à en sortir. C'est parfaitement efficace. Et ça marche sur mon ordi, en graphique, dans un terminal, ou même à distance via ssh.

    Côté inconvénients, le plus pénible est sûrement que les raccourcis ne correspondent à rien d'autre. Tu coupes du texte dans Emacs avec Ctrl+W, si tu fais la même chose dans Firefox ça ferme l'onglet. Au revoir le long message que tu rédigeais. Je remarque aussi que l'édition à distance est parfois délicate parce que les combinaisons de touches sont récupérées par le terminal au lieu d'être envoyées. Et il y a aussi les perfs qui sont parfois décevantes. L'ouverture est un poil longue, et certains fichier font bien ramer l'éditeur.

    • [^] # Re: Oui

      Posté par  (Mastodon) . Évalué à 3.

      L'ouverture est un poil longue, et certains fichier font bien ramer l'éditeur.

      J'ai remarqué qu'il n'est pas le plus rapide à démarrer, ni à ouvrir les fichiers mais c'est pas trop un souci : je le démarre une fois par jour maximum, et une fois ouverts ça va (scroller un doc un peu long reste saccadé, cela dit malgré une machine correcte).

      Tous ces trucs pour Augmenter La Productivité™, très peu pour moi, merci.

      J'avais plussé ta réponse, j'aurais aimé pouvoir plusser aussi ce passage en particulier ;)

      C'est à la fois ce qui me fait vouloir persister dans Emacs (là où j'en suis, c'est déja pas mal, même si je suis encore nulle part) et ce qui me fait hésiter : au moindre souci, ce minimalisme efficace que j'apprécie est renvoyé au néant par le temps que je dois passer à chercher ce aui pose problème et comment le corriger. À ce stade, j'en suis vraiment à me demander si c'est un risque raisonnable de consacrer encore (bcp) plus de temps à un outil. Mais une part de moi y est déjà très attachée, je dois dire…

      • [^] # Re: Oui

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

        J'ai remarqué qu'il n'est pas le plus rapide à démarrer, ni à ouvrir les fichiers mais c'est pas trop un souci : je le démarre une fois par jour maximum, et une fois ouverts ça va (scroller un doc un peu long reste saccadé, cela dit malgré une machine correcte).

        Emacs peut être utilisé en mode client/serveur. Il suffit ensuite d'utiliser emacsclient pour ouvrir un nouveau fichier. L'ouverture est plus rapide, emacs étant déjà chargé. On peut aller même plus loin en démarrant emacs en mode server sans gui à 'louverture de la session utilisateur (via un service systemd par ex)

        • [^] # Re: Oui

          Posté par  . Évalué à 2.

          Et tu peux compiler ta configuration pour qu'elle soit exécutée plus vite aussi.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Oui

            Posté par  . Évalué à 2.

            Je suppose que tu parles de la pré-compilation du lisp en bytecode. Si c'est le cas, cela accélère le chargement des fichiers lisp mais pas leur utilisation proprement dite.

            Toutefois, la (future?) version 28.1 permet la compilation du lisp en code natif. https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS

                * Installation Changes in Emacs 28.1

    ** Emacs now optionally supports native compilation of Lisp files.
    To enable this, configure Emacs with the '--with-native-compilation' option.
    This requires the libgccjit library to be installed and functional,
    and also requires GCC and Binutils to be available when Lisp code 
    is natively compiled.  See the Info node "(elisp) Native Compilation"
    for more details.

            En théorie cela devrait permettre d'accélérer certaines opérations coûteuses. Je ne sais pas si cela aura un effet notable sur la colorisation syntaxique des gros fichiers (c'est pénible à utiliser sur un Raspberry Pi 4) car le problème vient en fait du «garbage collector» qui interrompt l'exécution. Emacs n'est malheureusement pas multi-threads.

            • [^] # Re: Oui

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

              je ne sais plus si certains désactivent gc durant l'ouverture de gros fichiers, au démarrage (début init.el), ou les deux. En tout cas pour accélérer

    • [^] # Re: Oui

      Posté par  . Évalué à 4.

      Tous ces trucs pour Augmenter La Productivité™

      Si tu as passé du temps dans emacs tu dois savoir que tout outil sophistiqué vient avec une certaine philosophie, les IDE qui font de l'introspection de code n'ont pas pour objectifs d'augmenter ton nombre de frappe par minute, mais de te fournir toute l'information dont tu peux avoir besoin pour réaliser chaque frappe (le typage entre autre). Et ils ont généralement un grand niveau de configuration tout ce que tu as décrit.

      Tu es content avec emacs et c'est cool, ne change pas, mais je trouvais ta description fortement biaisée. On peut très bien trouver vim excellent (ce qui est mon cas) sans mauvaise fois au près d'emacs.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Oui

      Posté par  . Évalué à 5.

      L'ouverture est un poil longue, et certains fichier font bien ramer l'éditeur.

      T'as déjà utilisé Eclipse ? Essaie, et tu verras qu'à côté, Emacs est rapide :)

    • [^] # Re: Oui

      Posté par  . Évalué à 2.

      salut, si, les raccourcis correspondent à ceux de bash par exemple :) (C-a, C-e, C-k, M-p, M-n, M-b, M-f…)

      • [^] # Re: Oui

        Posté par  . Évalué à 2.

        Bah … il suffit d'avoir ton bash configuré avec l'option d'édition vi et ça marche plus … (set -o vi).

    • [^] # Re: Oui

      Posté par  . Évalué à 1.

      Tu coupes du texte dans Emacs avec Ctrl+W, si tu fais la même chose dans Firefox ça ferme l'onglet.

      Ho pinaise, je ne compte plus le nombre de fois où j'ai perdu du texte dans Firefox à cause de ça. Encore une machination diabolique des vimeux.

      • [^] # Re: Oui

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

        Les vimeux n'y sont pour rien si les logiciels que les gens trouvent simples ont des raccourcis qui n'ont aucun sens (contrôle avec : Z, X, W, V, S, Q, P, O, N, G, F, C, A) et qui ont été popularisé par Fenêtre et Pomme.
        D'ailleurs ces machinationistes diaboliques se font avoir aussi en voulant redimensionner la fenêtre du panda roux mais n'accusent pas les emacsiens.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: Oui

          Posté par  . Évalué à 3.

          Ou en tentant de sauvegarder avec C-s.

          (Si tu te retrouve à lire ça parce que tu es bloqué dans ce cas: C-q pour en sortir).

        • [^] # Re: Oui

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

          Pour le coup Ctrl+W c'est associé au caractère ASCII End of Transmission Block: https://en.wikipedia.org/wiki/End-of-Transmission-Block_character , donc d'un point de vue historique et compatibilité ascendante avec les téléscripteurs, ça me parait pertinent de l'associer à la fermeture. C'est plutôt emacs qui se fourvoie à ce niveau là.

          Pour ceux que l'histoire de ces codes de contrôle intéresse: https://bestasciitable.com/

    • [^] # Emacs distant par ssh, il y a mieux

      Posté par  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 12 mai 2021 à 21:26.

      [Emacs] est parfaitement efficace. Et ça marche sur mon ordi, en graphique, dans un terminal, ou même à distance via ssh.

      Si tu as un accès ssh à un système distant, le plus simple est d’ouvrir les fichiers distants dans ton Emacs local à l’aide de TRAMP (inclus dans Emacs depuis la version 22.1). Pour l’avoir utilisé un peu, c’est vraiment excellent : rien à configurer, il faut simplement préciser que le fichier est distant lorsque tu fais un find-file (il y a une syntaxe pour ça qui ressemble un peu à la spécification d’un chemin distant avec rsync), et après ça marche de façon complètement transparente en se faisant oublier (mais bien sûr tu peux tout configurer si tu veux, ça reste Emacs après tout). Et surtout c’est beaucoup plus fiable que d’espérer que le système distant ait un Emacs relativement à jour installé, de devoir installer ta configuration sur le système distant, espérer qu’elle va marcher sans problème avec une version différente d’Emacs, et autres complications potentielles.

      Une solution similaire mais qui donne aussi automatiquement accès aux fichiers distants à tous tes programmes locaux, c’est de monter sur ton système de fichier local le répertoire qui t’intéresse sur le système distant, en utilisant sshfs. Ça marche aussi super bien, rien à configurer non plus, et ça n’est pas limité à Emacs.

  • # Est-ce que ça vaut le coup

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

    Courbe d'apprentissage Emacs

    Cela vaut le coup si tu t'apprête à passer longtemps à écrire. Si tu passe ta vie à écrire alors oui cela vaut le coup.

    Ensuite je ne peux qu'abonder avec les autres commentaires, s'il faut d'abord tester Emacs "natif", il peut être intéressant de voir du côté des distributions - pour tester. Tu découvriras des "modes" qui te plairont, ou pas. Tu sauras alors si tu reviens à un Emacs standard pour partir de là, ou si l'une des distrib correspond mieux à ton usage.

    Tu as sans doute une idée de quelques fonctionnalités utiles pour écrire autre chose que du code
    - plusieurs vues sur un même texte, éventuellement des "ancres" pour revenir à tel ou tel point
    - profiter des modes org ou markdown pour "replier" des parties du texte
    - fonctionnalités d'undo avancées
    - git pour versionner ce que tu écris (et le contrôler depuis Emacs, avec magit)
    - evil pour reposer ses petits doigts.
    - création d'abbrev qui sont automatiquement étendues pour taper très vite

    • [^] # Re: Est-ce que ça vaut le coup

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

      J'ai l'impression que les légendes sont interverties…

      ton image mon ressenti
      pico vi
      vi notepad
      notepad pico

      J'ai encore jamais testé Visual Studio, le peu que j'en ai vu m'a paru fort complexe.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # paradigmes/univers ≠

    Posté par  (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 11 mai 2021 à 03:26.

    Il y a certains trucs qui m'interpellent… Prenons point par point :

    Depuis toujours, pour écrire j'utilise Microsoft Word (j'ai aussi utilisé Scrivener) et, depuis mon passage à Linux, LibreOffice Writer. À côté de ça, j'utilise aussi un éditeur de texte + Markdown, pour blogger ou pour écrire des trucs en ligne.

    Pourquoi un éditeur de texte, sachant que tu peux aussi utiliser ton traitement de texte pour écrire du Markdown …avec les avantages qui vont avec : tu connais l'outil (donc pas de prise de tête pour un certain nombre d'opérations et pour les nouvelles tu sais comment configurer etc.), tu as tes petits à portée de main (par exemple pour la correction orthographique)

    Ma question a l'air trollesque mais j'ai cependant constaté qu'avec des outils qu'on maîtrise on fait bien mieux qu'avec de nouveaux trucs qui ne correspondent pas du tout à votre mode de fonctionnement (j'insiste sur ce point car la découverte de nouveaux outils est aussi un bonheur quand ça permet de retrouver des façons de faire avec lesquelles on est plus en phase que les habitudes qu'on se coltine.)

    En switchant sur Linux, je me suis fait la promesse de tenter de tout écrire dans un éditeur de texte, y compris la fiction. Par curiosité, par goût de tenter de nouvelles choses, mais aussi motivé à l'idée de pouvoir tout gérer dans des fichiers TXT, et d'apprendre à utiliser Git (pour le contrôle de versions des manuscrits).

    Justement, qu'entends-tu par « tout » ? Tu voudras faire ton courrier et tes cartes de vœux dans un éditeur de texte ? (ce n'est pas pour dénigrer ou décourager hein, même mes schémas se font avec un éditeur de texte, mais pour autant je n'en fais pas de prosélytisme car j'ai conscience que ça ne convient pas à tout le monde ainsi que des complications que cela peut engendrer pour échanger avec les gens.) Quand tu écris « y compris la fiction » qu'apporterait ce changement brusque par rapport à avant ?

    Sinon, le « goût de tenter de nouvelles choses » est bien pour découvrir mais n'implique pas la radicalité de vouloir « tout écrire dans un éditeur de texte » du jour au lendemain. J'ai un peu peur de ce genre d'enthousiasme qui balai tout sans se poser la question des vraies attentes inconscientes et des difficultés que l'on rencontrera ; parce-que ça peut mener à des déceptions grave. (désolé de faire mon rabat-joie bien que ravi que tu veuilles découvrir ce merveilleux côté du miroir.)

    Mon éditeur de texte par défaut, c'est VisualStudio Code (en réalité, j'utilise son fork VSCodium, mais c'est la même chose sauf quelques réglages par défaut qui sont plus respectueux de la vie privée). VSCode est simple d'emploi, on trouve à peu près un gazillion et demi d'extensions simples à installer et a configurer, dont certaines vachement sympa pour écrire, et on n'a pas besoin de tout réapprendre à zéro juste pour commencer a l'utiliser… Un outil de plus, dans la boite à outils, quoi.

    Du coup, que t'apporte VSCodium par rapport à LibreOffice Writer ? :-)

    Et si VSCodium est « vachement sympa pour écrire, et on n'a pas besoin de tout réapprendre à zéro juste pour commencer à l'utiliser » ; qu'est-ce qui motive vraiment la recherche d'un autre éditeur d'une part, et qu'apporterait Emacs de plus d'autre part ?

    Désolé pour la séance de psychanalyse mais je crois qu'il faut toujours bien préparer les longs voyages et que si certaines choses sont bien claires on sait mieux doser l'effort qu'on va mettre pour que ça en vaille le coup et que la traversée soit plaisante malgré les turbulences qui pourraient survenir.

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: paradigmes/univers ≠

      Posté par  (Mastodon) . Évalué à 2. Dernière modification le 11 mai 2021 à 09:46.

      Pourquoi un éditeur de texte, sachant que tu peux aussi utiliser ton traitement de texte pour écrire du Markdown

      • le format TXT, pour la possibilité de travailler sur mon téléphone (ODT sur iOS… mais même docx, c'est tout sauf le pied), comme sur n'importe quelle machine, et sur n’importe quell app, sans rien avoir à installer (ou à quoi devoir m’abonner — Office 365 est nécessaire sur iOS pour accéder à toutes les fonctions de Word Mobile (qui sont déjà limitées p/r au desktop). Le tout sans souci de compatibilité et de formatage des docs qui risquent changer d’un écran à l’autre selon les polices installées et la version de Word ou de Writer.
      • Réelle compatibilité avec Markdown (live preview, par ex).
      • Compatibilité avec Git. Celui-là, en ce qui me concerne, c'est juste un projet mais je veux l’expérimenter.

      Justement, qu'entends-tu par « tout » ?

      C'est une façon de parler — mais oui, je fais à peu près tout dans un éditeur (ou dans LO) dès que c’est plus qu’une poignée de lignes, pour le coller là où j'en ai besoin, le cas échéant (même ici ;)). Pourquoi ?

      • J'ai trop souvent perdu un texte, dans un formulaire web qui plante ou que je ferme par erreur.
      • J'ai appris à rédiger mes emails (surtout les plus… énervés) loin du client mail, pour me laisser une chance de ne pas pouvoir les envoyer, de pouvoir les relire tranquillement et réaliser que, bon, vaut mieux ne pas envoyer ça ;)
      • J’ai toujours un Emacs/LO ouvert, prêt à l’emploi et qui ne me sert qu’à ça.
      • Facilité — un comble ;) — de Emacs + Org pour rapidement prendre des notes via un raccourci clavier et les envoyer dans tel ou tel fichier de ton choix. Ça je ne peux déjà plus m’en passer : je tiens des carnets de notes/journaux pour chaque projet actif et pouvoir passer aussi facilement de l’un à l’autre est une bénédiction.

      Sinon, le « goût de tenter de nouvelles choses » est bien pour découvrir mais n'implique pas la radicalité de vouloir « tout écrire dans un éditeur de texte »

      Perso, ce n’est pas une question de radicalité, juste le désir de m’immerger autant que possible pour comprendre ce aue je peux espérer trouver et en tirer. Mon seul objectif n’est pas d’adhérer à telle ou telle foi, ni à tel ou tel outil, c’est de garder ma boite à outils… aussi portative que possible. Et pour ça, je suis OK de tenter de la simplifier au max en faisant le max de choses avec un seul outil là où j’en utilisais deux ou plus, ou d’en utiliser deux ou plus là où je faisais tout avec un seul… Tant que j'arrive au même résultat, si pas mieux, et tant que c’est pas plus pénible. Mais pour ça je dois tester, donc m’immerger ;)

      Et si VSCodium est « vachement sympa pour écrire, et on n'a pas besoin de tout réapprendre à zéro juste pour commencer à l'utiliser » ; qu'est-ce qui motive vraiment la recherche d'un autre éditeur d'une part, et qu'apporterait Emacs de plus d'autre part ?

      • La curiosité, toujours. Bidouiller, c’est ce que j’aime faire pour me changer les idées. Je pense que je n'aurais jamais envisagé Emacs sans ça.
      • La lourdeur de VScode sur mon vieux laptop. Je cherche moins gourmand mais pas moins bien doté en features, si possible.
      • Même forké et respectueux de la vie privée, VSCodium reste basé sur le code de Microsoft, et j’ai envie de voir si je peux bosser loin de Microsoft — sans haine, ni rien a leur encontre : j’utilise MS depuis toujours, je veux juste voir comment je me débrouille avec des outils faits par d’autres, que ce soit pour Word, Edge, VSCode, etc. (Si tu te poses la question : j’ai écarté Apple parce que je vois pas trop de sens à sortir du jardin clos MS pour entrer dans celui de Apple… sauf que leurs apps sont vraiment bien foutues, d’après des potes auteur(e)s qui ne jurent que par Mac et iOS, et puis le pognon… ;))

      Désolé pour la séance de psychanalyse mais je crois qu'il faut toujours bien préparer les longs voyages et que si certaines choses sont bien claires on sait mieux doser l'effort qu'on va mettre pour que ça en vaille le coup et que la traversée soit plaisante malgré les turbulences qui pourraient survenir.

      Pas de souci. Et tu as raison.

      • [^] # Re: paradigmes/univers ≠

        Posté par  . Évalué à 2.

        • J'ai trop souvent perdu un texte, dans un formulaire web qui plante ou que je ferme par erreur.
        • J'ai appris à rédiger mes emails (surtout les plus… énervés) loin du client mail, pour me laisser une chance de ne pas pouvoir les envoyer, de pouvoir les relire tranquillement et réaliser que, bon, vaut mieux ne pas envoyer ça ;)

        Vscode est particulièrement lourd pour ça car il t'oblige à créer manuellement un fichier pour ça, là où emacs te permet de juste ouvrir un nouveau buffer (ou réutiliser) et taper directement ton texte.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: paradigmes/univers ≠

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

      Apprendre un éditeur puissant peut s'avérer joyeux plutôt que turbulent. Bien sûr du temps, du temps, mais ce temps sera éventuellement regagné. Si le temps investi ne représente pas immédiatement moins de temps à écrire il représentera plus de connaissances.

      La configuration dans Emacs se fait en lisp, qui n'est autre que le langage dans lequel est codé Emacs. Configurer Emacs est égal à recoder Emacs. Il n'y a pas de limite.

      Je ne code pratiquement plus (et je ne teste plus trop les trucs comme lire les flux rss, faire du réseau social, etc.., dans Emacs) mais j'écris toujours dans Emacs pour cette raison - je me suis fait mon Emacs qui est devenu meilleur pour mon usage que tout autre éditeur de texte ; et si j'essaie parfois un truc comme un énième éditeur markdown, c'est pour bien vite rire grassement de ses limites.

      • [^] # Re: paradigmes/univers ≠

        Posté par  (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 12 mai 2021 à 09:11.

        La configuration dans Emacs se fait en lisp, qui n'est autre que le langage dans lequel est codé Emacs. Configurer Emacs est égal à recoder Emacs. Il n'y a pas de limite.

        Attention que ce n'est pas tout à fait vrai…

        Aussi bien le Emacs originel (sur PDP-10) que ceux actuels sous les systèmes de type Unix ne sont en Lisp… Pour les Unix-like, y compris GNU/Linux, le cœur de l'éditeur est écrit en C ; j'y reviens plus tard.

        Il a fallu attendre le portage sur une machine Lisp (SINE, EINE, ZWEI) pour avoir un éditeur écrit en Lisp, qui était l'équivalent à la fois du C ou du FORTRAN (compilation haut niveau) et du BASIC (interprétation interactive) sur ces machines là. Quelques autres suivront : le portage sous Multics utilisera MacLisp (dialecte écrit en assembleur PDP pour ITS, et en PL/I pour Multics) et Zmacs (la suite propriétaire de ZWEI) utilisera ZetaLisp.

        Pour en revenir aux implémentations unixiennes, il a actuellement un certain nombre d'éditeurs de textes qui ont le fonctionnement du Emacs de base sans la personnalisation (plus précisément le système d'extension par MACroS) ; et aucun d'entre eux n'est en Lisp, mais plutôt en C pour les plus anciens (de nouveaux ou futur programmes du genre sont ou seront probablement en C++ ou Rust ou Java ou Go ou que sais-je)

        Les implémentation complétes/extensibles de référence sont écrit en C, avec un langage d'extension dérivé de Lisp : ce sera Mocklisp pour Gosling Emacs ; Emacs Lisp pour GNU Emacs et XEmacs !

        Il n'y a pas, à ma connaissance, d'utilisation de CL (Emacs Lisp s'en rapproche mais il y a quelques différences qui parfois cassent les pieds) mais de plus en plus d'application sont extensibles en Scheme via Guile et script-fu

        À noter aussi que d'autres éditeurs ont fait le choix d'être extensibles via un certain langage de programmation, comme Lua ou JS, au lieu d'inventer leur DSL. C'est un peu la même idée…

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: paradigmes/univers ≠

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

          Il n'y a pas, à ma connaissance, d'utilisation de CL (Emacs Lisp s'en rapproche mais il y a quelques différences qui parfois cassent les pieds) mais de plus en plus d'application sont extensibles en Scheme via Guile et script-fu

          Bon, complément et début de petit mémo pour retrouver l'information en repassant par ici.

          Bien que Emacs Lisp à la fois proche du vieux MacLisp et du standard Common Lisp, j'aurais souhaité que soit exploré la piste de la stricte adhérence à cette dernière. Quelque chose de plus que le mode SLIME qu'on salut cependant.
          Eh bien, il y a une application McCLIM (l'implémentation libre de CLIM dont la spécification provient des API des machines Lisp de Symbolics.) : Climacs

          De même, je pense qu'il faut lorgner du côté de l'excellent Scheme …pour lequel il y a malheureusement trois implémentations GNU (le "MIT Scheme" du professeur Hal Abelson, qui en devenant membre du CA de la FSF, décida de l'intégrer au projet GNU et est aujourd'hui maintenu par Chris Hanson de chez Google ; SCM et GNU Guile dont le mainteneur actuel est Andy Wingo, et qui déplore cet état de fait…) Et je découvre que "GNU/MIT Scheme" l'a fait : Edwin
          D'un autre côté, un certain nombre de hackers font une réécriture en Guile, qui sait être compatible avec divers dialectes. Zile y est déjà passé, et Emacs pourrait à terme aussi.

          nom d'implémentation langage d'extension
          Gosling Emacs / Unipress Emacs Mocklisp / MLisp
          GNU Emacs Elisp
          Zile lithp
          Zile-on-Guile (experimental) GNU Guile
          Freemacs MINT (une implémentation de TRAC)
          Climacs CL
          Edwin (intégré) MIT/GNU Scheme
          Hemlock (intégré) Spice Lisp → CMUCL
          Barry's Emacs Mocklisp → Python (experimental)

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: paradigmes/univers ≠

        Posté par  (Mastodon) . Évalué à 3. Dernière modification le 12 mai 2021 à 09:17.

        je me suis fait mon Emacs qui est devenu meilleur pour mon usage que tout autre éditeur de texte

        C'est vraiment la sensation que me donnent la majorité des articles et des vidéos des utilisateurs qui en parlent, et c'est ce qui me séduit le plus: Emacs est leur outil. Ils ne parlent pas d'Emacs, ils parlent de leur Emacs. Mais ce côté toujours unique, c'est aussi ce qui rend difficile d'apprendre à l'utiliser en se basant sur la config d'un autre, car cette config est toujours très personnelle et, bâtie dans/pour la durée, repose sur pas mal d'acquis et de personnalisations antérieures. Je ne compte pas le nombre de fois où j’ai en vain tenté d'appliquer sans succès une astuce/config pêchée ici ou là pour chaque fois échouer. Parce que ceci ou cela manquait dans mon install, ou avait changé depuis le moment ou le tuto avait été rédigé, ou etc.

        Mais malgré ça, même à mon tout tout petit niveau, c'est déjà ce que je ressens en utilisant Emacs (comme dans Linux en général, d‘ailleurs) : j’y suis chez moi. Et ça fait une énorme différence dans la façon dont je considère les efforts nécessaires à son apprentissage.

        Oui, Emacs est grognon comme un vieil ours. Il n'a pas non plus le sourire irrésistible de la jolie crémière/du joli crémier. En plus, il pas mal de, hum, aspérités et rugosités, et il grogne souvent. Mais c'est dingue à quel point Emacs s'adapte à tes besoins et y met toute sa force. C'est juste qu'il faut prendre le temps de l'apprivoiser, et c'est un temps qui semble devoir se mesurer à l'échelle géologique, ou peu s'en faut ;)

  • # Vraie question

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

    Et sinon, comment tu as fait pour choisir entre emacs et vim ?

Suivre le flux des commentaires

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