Journal un éditeur de code portable par Microsoft?

Posté par . Licence CC by-sa.
46
9
fév.
2018

Ce matin, pas trop décidé à faire une tâche pénible, j'ai été jeter un oeil sur développez.com, et suis tombé sur un article qui indique «Visual Studio Code 1.20 est disponible […] l’éditeur de code open source et multiplateforme de Microsoft».

Entre méfiance et envie de défouler ma mauvaise foi, je vais donc voir pour télécharger le-dit éditeur sur le site officiel.

Et la, j'enchaîne les déceptions:

  • ils remarquent que je ne suis pas sous windows, et fournissent à la fois un .deb et un .rpm… obligation donc de télécharger pour tester.
  • je télécharge le .deb, le dpkg de manière habituelle, et comme d'hab je lance aptitude pour aller réparer les dépendances manquantes… et bah non! Rien. Les seules dépendances: apt, gnupg, libgconf, libnotify, libnss, libsecret et libxkbfile! Du coup, obligé de tester…
  • je lance, espérant que ça merde, histoire de pouvoir troller sur un soft trop lourd voire qui ne se lance pas (tant de softs galèrent quand on n'a pas un bureau classique…): encore raté, il se lance instantanément, sans le moindre problème…
  • en «bon» utilisateur (initié, mais loin de maîtriser) de vim, je me dis que je vais p'tet pouvoir me rabattre sur des raccourcis clavier mal branlés… faux: je trouve en quelques clics (moins de 5!) comment lui faire utiliser les raccourcis clavier classiques de vim!
  • ok, allons donc regarder un peu ce qui tourne, en quelques secondes… vim $(which code) => un script bash. Bon, ils auraient pu utiliser sh, pour ce que j'en lit, en tout cas, à première vue, c'est propre, un script de lancement classique, qui lance '/usr/share/code/code' (ah, enfin des trucs étranges, mais pas de quoi fouetter un chat).
  • listons les dépendances de ce fameux binaire, on va bien trouver un truc à redire, j'ai quelques saletés installées à cause de softs utilisés par la boîte, dont je me débarrasserais bien, y'a bien une lib dedans que je vais pouvoir troller:
~% ldd /usr/share/code/code 
    linux-vdso.so.1 (0x00007ffdf9774000)
    libnode.so => /usr/share/code/libnode.so (0x00007fab9beb8000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fab9bc9b000)
    libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007fab9b652000)
    libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 (0x00007fab9b39d000)
    libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007fab9b190000)
    libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007fab9af6a000)
    libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007fab9ac56000)
    libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007fab9aa32000)
    libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007fab9a69c000)
    libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007fab9a450000)
    libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007fab9a1fd000)
    libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007fab99f4e000)
    libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007fab99d10000)
    libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007fab99ac0000)
    libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007fab998be000)
    libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fab99696000)
    libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007fab99486000)
    libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007fab9927b000)
    libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007fab99078000)
    libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007fab98e6d000)
    libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007fab98c6a000)
    libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fab98a58000)
    libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007fab98852000)
    libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007fab98648000)
    libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fab98308000)
    libXtst.so.6 => /usr/lib/x86_64-linux-gnu/libXtst.so.6 (0x00007fab98102000)
    libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1 (0x00007fab97eff000)
    libgconf-2.so.4 => /usr/lib/x86_64-linux-gnu/libgconf-2.so.4 (0x00007fab97cce000)
    libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007fab97aca000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fab978c2000)
    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fab975ae000)
    libnss3.so => /usr/lib/x86_64-linux-gnu/libnss3.so (0x00007fab97264000)
    libnssutil3.so => /usr/lib/x86_64-linux-gnu/libnssutil3.so (0x00007fab97036000)
    libsmime3.so => /usr/lib/x86_64-linux-gnu/libsmime3.so (0x00007fab96e09000)
    libnspr4.so => /usr/lib/x86_64-linux-gnu/libnspr4.so (0x00007fab96bc9000)
    libffmpeg.so => /usr/share/code/libffmpeg.so (0x00007fab9671e000)
    libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007fab96411000)
    libcups.so.2 => /usr/lib/x86_64-linux-gnu/libcups.so.2 (0x00007fab96188000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fab95f84000)
    libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fab95d5a000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fab959d8000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fab956d4000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fab954bd000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fab9511e000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fab9d50a000)
    libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007fab94f08000)
    libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007fab94d05000)
    libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007fab94b03000)
    libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007fab9485c000)
    libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007fab94629000)
    libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007fab94425000)
    libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007fab94217000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fab93ffd000)
    libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fab93dd5000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fab93bbe000)
    libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007fab93970000)
    libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0 (0x00007fab93766000)
    libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fab9355d000)
    libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007fab9d679000)
    libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fab93359000)
    libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fab93153000)
    libdbus-glib-1.so.2 => /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x00007fab92f2c000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fab92cb9000)
    libplc4.so => /usr/lib/x86_64-linux-gnu/libplc4.so (0x00007fab92ab4000)
    libplds4.so => /usr/lib/x86_64-linux-gnu/libplds4.so (0x00007fab928b0000)
    libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007fab92665000)
    libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007fab922cc000)
    libavahi-common.so.3 => /usr/lib/x86_64-linux-gnu/libavahi-common.so.3 (0x00007fab920bf000)
    libavahi-client.so.3 => /usr/lib/x86_64-linux-gnu/libavahi-client.so.3 (0x00007fab91eae000)
    libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007fab91c19000)
    libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007fab919d3000)
    libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007fab917cb000)
    liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fab915a5000)
    liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fab91393000)
    libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007fab91083000)
    libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007fab90e6d000)
    libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007fab90b93000)
    libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007fab90960000)
    libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007fab9075c000)
    libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007fab90550000)
    libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007fab9034c000)
    libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fab900e7000)
    libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x00007fab8feb3000)
    libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007fab8fca0000)
    libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007fab8fa69000)
    libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007fab8f834000)
    libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fab8f5b1000)
    libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007fab8f384000)
    libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fab8f17f000)
    libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fab8ef6b000)

Ah, il y a bien des choses qui sont un peu étranges, ou alors pas listées dans les dépendances: avahhi-client, gtk (2, à priori), uuid, X.*… mais rien de lié à du javascript ou un quelconque langage de script, qui m'eusse permis de râler! D'un autre côté, ça explique la réactivité du truc.

Bref, du coup, je suis bien déçu pour mon défouloir, pire, j'ai même envie de tester plus avant ce logiciel…
Du coup, je partage ça ici, en ce jour dédié, dans l'espoir que l'on m'aide à troller ce soft qui à l'air propre malgré qu'il soit édité par Microsoft… Ou va le monde, si un honnête troll ne peux plus attaquer Microsoft, je vous le demande ma p'tite dame!

Note pour moi-même, vérifier que les dépendances listées par le .deb sont bien les seules réellement nécessaires, c'est une piste de râlage potentiel… ou un moyen d'apprendre une technique pour faire du code plus indépendant du système: d'un côté ou de l'autre, je gagnerai à étudier ça.

  • # Éditeur préféré

    Posté par . Évalué à 10.

    C’est devenu mon éditeur préféré, non pas pour sa légèreté, mais parce qu’il fonctionne :

    • La complétion est top et pour avoir utilisé Visual Studio Express pour faire du cécharpe avec, on a la même chose.
    • Les plugins sont de très bonne qualité, merci la communauté !
    • L’éditeur est fluide, et pour être tatillon sur les moindres petites latences à la saisie, je ne ressens rien ici. On est presque au niveau de réactivité de SublimeText.

    Ça fait un baille que j’ai abandonné Vim au profit d’éditeurs plus lourdingues, et VSCode est un bon outil qui a largement progressé depuis sa sortie initiale… où on avait une fenêtre et un curseur, en gros :D

    • [^] # Re: Éditeur préféré

      Posté par (page perso) . Évalué à 4.

      Pareil, c'est aussi mon éditeur préféré ;-)
      J'avais tenté ATOM, mais j'ai fini sur VSCODE, plus fluide, et des plugins qui fonctionnent. (on ne se retrouve pas en carafe suite à une upgrade)
      Il tourne sur win ou nux, ce qui permet de garder ses configs aux petits oignons.
      Bref, idéal si on veut un peu plus lourd qu'un SciTE ;-)

  • # Rapport de bug

    Posté par (page perso) . Évalué à 10.

    Note pour moi-même, vérifier que les dépendances listées par le .deb sont bien les seules réellement nécessaires, c'est une piste de râlage potentiel… ou un moyen d'apprendre une technique pour faire du code plus indépendant du système: d'un côté ou de l'autre, je gagnerai à étudier ça.

    Fais attention, bientôt tu vas te retrouver à envoyer des rapports de bugs à Microsoft, voire même à contribuer à régler le problème (gasp!).

  • # Déception

    Posté par . Évalué à 2. Dernière modification le 09/02/18 à 11:26.

    $ ./code
    ./../code: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by ./../code)
    ./../code: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./../code)
    ./../code: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.5' not found (required by ./../code)
    ./../code: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by /home/killou/tmp/VSCode-linux-x64/libnode.so)
    ./../code: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /home/killou/tmp/VSCode-linux-x64/libnode.so)
    

    Je vais rester sous SublimeText. Même si il n'est pas OpenSource/Libre, il a le mérite de se lancer sur ma Centos 6*, contrairement à VSCode et Atom.

    *Machine pro, je n'ai pas le choix du système que j'utilise.

    • [^] # Re: Déception

      Posté par . Évalué à 2. Dernière modification le 09/02/18 à 11:33.

      Tu peux essayer de le compiler :)

      https://github.com/Microsoft/vscode/wiki/How-to-Contribute#build-and-run-from-source

      Ou alors de le lancer dans un chroot CentOS 7

      • [^] # Re: Déception

        Posté par . Évalué à 1.

        Je ne suis pas root sur ma machine, ça complique un peu l'utilisation de chroot ou de l'installation des dépendances pour le compiler :)

        • [^] # Re: Déception

          Posté par . Évalué à 3.

          Tant que ton homedir reste monté en exec, t'as toujours moyen de compiler depuis une machine à la maison.

          Reste après la volonté ou non de le faire.

        • [^] # Re: Déception

          Posté par . Évalué à 2.

          Hummmmm bon alors tu peux te bricoler une image flatpack à ta meuson, puis l’installer à l’arrache sur ta bécane en compilant flatpak pour centos 6 dans un tgz que tu ramènes en clef usb :D

          On se lance dans des joyeusetés… c’est fantastique :D

    • [^] # Re: Déception

      Posté par . Évalué à 3.

      Un petit chroot/schroot et on n'en parle plus. C'est pas comme si t'avais une dépendance sur le kernel non plus.

    • [^] # Re: Déception

      Posté par (page perso) . Évalué à 4.

      Emacs tourne sans problème sur Centos 6*. ;)

  • # retour d'utilisation

    Posté par . Évalué à 3.

    J'utilise vscode en parallèle avec vim depuis un peu plus d'un an. Je ne dirais pas qu'il est léger non plus, pas plus pas moins qu'atom.

    Le seul gros défaut que je vois c'est qu'il n'a pas de version console et que les plugins pour avoir les mêmes raccourcis que vim ont tous certaines petites limitations qui font que tout ne sera pas tout à fait identique.

    Sinon il est très bien. C'est un des très bon produits de Microsoft et je n'ai pas honte de le dire.

  • # C'est libre ?

    Posté par (page perso) . Évalué à 3.

    Ah mince, oui. Mais pas les binaires distribués (?!)

    Tu peux toujours râler sur la licence choisie. Quelle qu'elle soit, il y a matière.

    • [^] # Re: C'est libre ?

      Posté par . Évalué à 2.

      Cette remarque n'est valable que si tu utilises leur dépôts.

    • [^] # Re: C'est libre ?

      Posté par . Évalué à 10.

      C'est presque libre (du coup ça ne l'est pas en fait)

      L'éditeur l'est en tout cas, par contre le store de plugin ne l'est pas. Du coup pour avoir essayer le vscode fournit par MS et vscode compilé à partir de github, ben clairement le 2° n'est pas vraiment utilisable sans la richesse qu'apporte les différents plugins

  • # Rien de lié à un langage de script ?

    Posté par (page perso) . Évalué à 10.

    mais rien de lié à du javascript ou un quelconque langage de script, qui m'eusse permis de râler! D'un autre côté, ça explique la réactivité du truc.

    Si je ne me trompe pas, VSCode est codé en Javascript (plus précisemment en Typescript) et tourne en gros dans un browser, c'est une application Electron… Donc les dépendances natives que tu listes, c'est en gros celles de nodejs + Chrome.

    Sources: https://github.com/Microsoft/vscode , https://en.wikipedia.org/wiki/Visual_Studio_Code

  • # Electron

    Posté par (page perso) . Évalué à 8.

    Note pour moi-même, vérifier que les dépendances listées par le .deb sont bien les seules réellement nécessaires, c'est une piste de râlage potentiel… ou un moyen d'apprendre une technique pour faire du code plus indépendant du système

    Pas besoin d’aller vérifier les dépendances, tu peux consulter le code source directement. En l’occurrence, la « technique pour faire du code indépendant du système » s’appelle Electron, en gros c’est du Javascript/HTML/CSS…

  • # dépendances

    Posté par . Évalué à 8.

    Pour installer un paquet .deb local et ses dépendances sans avoir à "apt-get -f install" (ou aptitude), on peut utiliser gdebi.

    • [^] # Re: dépendances

      Posté par (page perso) . Évalué à 4.

      Depuis un bon moment on peut simplement utiliser apt install ./paquet.deb, cette commande gère l’installation des dépendances.

  • # Collecte des données

    Posté par (page perso) . Évalué à 4.

    Quid de la collecte des données mentionnée sur la page wikipedia ?

    Visual Studio Code collects usage data and sends it to Microsoft, although this telemetry reporting can be disabled. The data is shared among Microsoft-controlled affiliates and subsidiaries and with law enforcement per the privacy statement.

    • [^] # Re: Collecte des données

      Posté par . Évalué à 1.

      C'est quoi dans although this telemetry reporting can be disabled. qui te pose problème?

      Depending on the time of day, the French go either way.

      • [^] # Re: Collecte des données

        Posté par (page perso) . Évalué à 9.

        Si c'est activé par défaut sans que l'on soit explicitement informé, ça me poserait un problème.

        • [^] # Re: Collecte des données

          Posté par (page perso) . Évalué à 8.

          Si c'est activé par défaut sans que l'on soit explicitement informé, ça me poserait un problème.

          C’est activé par défaut, et c’est clairement affiché sur la page d’accueil (tout en bas de la page, d’accord, mais quand même : on ne peut pas dire que ce soit délibérément caché).

          Et le même paragraphe qui annonce la collecte des données fournit le lien vers les instructions pour la désactiver, donc même sur DLFP et même un vendredi je ne pense pas qu’il y ait grand’chose à redire sur ce point.

          • [^] # Re: Collecte des données

            Posté par (page perso) . Évalué à 4.

            Merci pour ces éclaircissements. Je cherchais vraiment à savoir si les utilisateurs enthousiastes issus de ce journal avaient bien conscience de ce mécanisme de collecte.
            Ce n'était pas un troll caché :-)

  • # VSCode -> Electron -> Node.js

    Posté par (page perso) . Évalué à 10.

    Comme indiqué plus haut, c'est en effet une application Electron, qui est émanation de l'éditeur Atom (Electron s'appelait d'ailleurs Atom Shell avant d'être rebaptisé), de la même manière que XULRunner était une émanation de Firefox (oui, ça date…). VSCode, c'est comme si Microsoft avait développé Edge en s'appuyant sur XULRunner (abstraction faite de la licence…).

    En fait, Electron est une application Node.js ; vous trouverez le fameux répertoire node_modules, propre à npm, le gestionnaire de paquet de Node.js, dans le répertoire dans lequel est installé Electron. On peut d'ailleurs utiliser n'importe quel paquet npm avec Electron. Il suffit, après installation desdits paquets, de lancer un electron-rebuild fournit par le paquet du même nom.

    Après avoir utilisé Chromium Embedded Framework, j'utilise maintenant Electron pour développer les interfaces desktop de mes applications. Parce que Electron est plus complet et les application basées dessus beaucoup plus simples à installer, surtout sur macOS. C'est dû à la manière, identique pour toute les plateformes, de lancer une application Electron. Il suffit d'un fichier JavaScript et d'un package.json référençant ce fichier (avec quelques petites choses en plus). On lance alors Electron en passant en paramètre le répertoire contenant le package.json en question, ou alors on lance Electron sans paramètre, et on drag&drop sur la fenêtre qui s'ouvre le dossier correspondant au dit répertoire.

    Comme c'est du Node.js, c'est donc du JavaScript au départ, mais on peut parfaitement écrire tout le code en C++ (on ne se refait pas…) grâce au mécanisme des addons de Node.js. Du coup, je l'utilise autant pour les logiciels propriétaires de mes clients, que pour les Logiciels Libres que je développe. Et tout ça, dans un cas comme dans l'autre, dans le strict respect des licences, puisque Electron est diffusé sous licence MIT

    Freelance en ingénierie logicielle.

    • [^] # Re: VSCode -> Electron -> Node.js

      Posté par (page perso) . Évalué à 4.

      application Electron, qui est émanation de l'éditeur Atom

      Et le prochain truc à la mode s'appellera BBC ou Archimedes ?

      * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

      • [^] # Re: VSCode -> Electron -> Node.js

        Posté par . Évalué à 3.

        Oh purée toi tu es vieux !

        … et moi aussi :p

        La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".

  • # Une vrai communauté

    Posté par . Évalué à 8.

    En plus d'être un éditeur plus que bien (c'est un intégriste de Vim qui parle), VS Code est une vrai communauté. Microsoft joue le jeu sur Github de façon exemplaire. Très très loin de ce que fait Google par exemple où la communauté est souvent réduite aux rapports de bugs.

    On a eu la chance d'avoir une conférence de Anders Hejlsberg au boulot, le créateur de Borland, Delphi, C#, TypeScript et VS Code (rien que ça). Non seulement le type est brillant, mais il était d'une très grande modestie.

    Il sont loin les temps de Steve Balmer, Microsoft a encore beaucoup de talents et n'est pas encore mort.

    • [^] # Re: Une vrai communauté

      Posté par . Évalué à 1.

      Il sont loin les temps de Steve Balmer, Microsoft a encore beaucoup de talents et n'est pas encore mort.

      Même si je te dis que c'est Steve Balmer qui a pris les premières décisions pro opensource chez Microsoft (en ayant validé par exemple l'intégration de git dans les produits de Microsoft)…

  • # Réinvention de la roue

    Posté par (page perso) . Évalué à 6.

    Bon, puisqu'on est vendredi, allons-y. :-)

    J'ai l'impression qu'Atom, Adobe Brackets, VSCode et autres éditeurs du même genre réinventent la roue… Ces efforts ne seraient-ils pas mieux investis en contribuant à améliorer Emacs ? (qui fait déjà tout ce qu'ils font, et plus).

  • # Emacs

    Posté par (page perso) . Évalué à 10.

    Je vois beaucoup de gens passer à Atom/ST/VScode et dire avoir découvert de supers outils sans même être passé par la case Emacs.

    C'est dommage, car Emacs à beaucoup à offrir:
    - Fonctions d'édition de texte très complètes (macro, interversion, kill-ring, fermeture automatique des délimiteurs "'(, etc)
    - Système de sauvegarde de positions dans les textes pour y revenir plus tard (mark-ring)
    - Mécanisme d'édition rectangulaire (démo)(Rectangle commands)
    - Possibilité de définir des marques-pages sur des positions dans des fichiers (bookmarks)
    - Système de registres pouvant sauvegarder des textes, des positions, des chemins de fichiers, des macros, etc
    - Possibilité de nourrir le système d'auto-complétion avec un peut ce qu'on veut (parseur de code et/ou de documentation, mots arbitraires, etc)
    - Pour celles et ceux qui aiment les raccourcis de VI, EVIL est une des meilleurs implémentations de VI
    - Une grande variété de thèmes (Quelques-uns ici)
    - Un gestionnaire de paquets intégré pour les extensions et les thèmes
    - Le dépôt communautaire MELPA trèèèèèès complet
    - Un système transparent d'accès aux fichiers et commandes d'autres systèmes (tramp)
    - Son système polyvalent de modes
    - Org mode
    - Le navigateur de fichier Dired
    - Magit, pour la gestion de Git
    - Système de templates très puissant (Yasnippet)
    - Pouvoir envoyer des e-mails, tout en profitant des autres avantages
    - Un lecteurs de boite e-mail et d'actualité (GNUS)
    - Un client IRC
    - Un shell intégré écrit en LISP (Eshell)
    - Un constructeur d'expressions régulières très pratique qui permet de tester en live sa regexp
    - Un système de démonstration pour les conférences
    - Un gestionnaire de fenêtre intégré
    - Libre et multiplateforme
    - Fonctionne dans un terminal ou en mode graphique
    - Léger avec un système client/serveur très pratique
    - 100% clavier
    - Tutoriel et manuel inclue, y compris pour un grand nombre d'extension
    - Grande possibilité de personnalisation y compris de son propre code et sans redémarrer
    - Écrit en majorité en Elisp
    - Fait aussi feux de cheminé
    - …

    Quelques liens utiles:
    - Site web officiel d'Emacs
    - Petit tour d'Emacs
    - Page de téléchargement
    - Emacs Rocks, quelques vidéos de démo d'Emacs
    - Démonstration/introduction de Org Mode (youtube.com)
    - Démonstration de Magit (youtube.com)
    - Démonstration de Dired (youtube.com)
    - Wiki de la communauté d'Emacs
    - Canaux #emacs et #emacsfr sur freenode (IRC)

    • [^] # Re: Emacs

      Posté par (page perso) . Évalué à 5.

      J'utilise Emacs tous les jours. C'est un formidable éditeur. Mais je le lâcherais volontiers si j'avais une alternative en CLI.

      • C'est moche (ou lourd) et austère
      • Long à customiser
      • Des raccourcis par défaut totalement wtf (donc long à customiser)
      • Avec tous les plugins nécessaires pour bosser dans certains langages, Electron doit pas être si lourd que ça.
      • La base de code doit probablement être bien vieille et assez compliquée à se mettre dedans.
      • De même pour les plugins, faut aimer le lisp
      • C'est pas si stable que ça

      Pour toutes ces raisons, je comprends amplement les utilisateurs d'éditeurs comme ST/Atom/VScode ainsi que leur développeurs et leur communauté. Toutes les fonctionnalités que tu cites sont très largement reprenables avec un éditeurs ayant un langage moderne capable d'attirer une nouvelle génération de dev.

      À mon avis il faut s'inspirer grandement d'Emacs et de Vim (pour des raisons différentes), mais ça serait cool que durant ma vie d'humain on arrive à les dépasser.

      • [^] # Re: Emacs

        Posté par (page perso) . Évalué à 6.

        Est-ce une déplaisante plaisanterie?

        Emacs moche et austère?
        - Sur Emacs est disponible un très grand nombres de thèmes, de quoi ravir la plupart des gouts de chacun
        - Emacs va à l’essentiel, à savoir d'afficher ce qu'on édite afin de pouvoir se concentrer sur son travail sans perdre de surface d'affichage

        Emacs lourd?
        - Emacs tourne sans broncher de façon fluide sur de très petites configs tel des Raspberry là où des applications écrites pour Electron peinent sur des Intel i3
        - Je cumule plus de 5 ans de customisations et d'extensions sur ma config d'Emacs et il reste totalement fluide, même quand je le fait tourner sur des board ARM avec un très petit CPU
        - Un grand nombre d'extensions d'Emacs ajoutent des fonctions qui ne s'exécuteront que si tu en fait appelle.

        Des raccourcis WTF?
        - Emacs a définit ses raccourcis bien avant l'arrivée des bureaux, ils sont naturellement différents
        - Ils sont très logiques, juste différents
        - Tu peux switcher vers des raccourcis plus classiques ou vers les raccourcis de VI

        Base de code vielle et compliquée?
        - Crois-tu vraiment qu'Emacs est sortie dans les années 80 et que personnes n'a touché son code depuis?
        - Emacs a eu largement le temps d'être amélioré, revue et son code simplifié justement de par son age

        Pas stable? On rencontre rarement des logiciels aussi stable qu'Emacs. Quand au Elisp, c'est un langage très simple et très puissant. Si un dév a peur d'apprendre en meilleur langage que le JS, il a peut-être pas choisi la meilleur des vocations…

        • [^] # Re: Emacs

          Posté par (page perso) . Évalué à 5.

          Disclaimer: mon expérience avec Emacs s'est terminée vers 2013, c'est possible que le système de config se soit amélioré depuis.

          Personnellement j'ai arrêté Emacs après m'être rendu compte qu'un sublimetext out-of-the-box répondait mieux à mes besoin que ma conf Emacs dans laquelle j'avais investi des dizaines d'heures sur plusieurs années.

          C'est un peu le syndrome "écosystème javascript" avec des tonnes de paquets faisant tous un petit truc et une lib standard rachitique (ok pas rachitique dans le cas d'Emacs, mais le conservatisme des dévs fait que des fonctionnalités genre multicursors ne sont pas incluses).

          Bien sûr le fun arrive quand on se retrouve avec des fonctionnalités fournies par des paquets différents mais qui s'interpénètrent (exemple: j'ai un module fournissant une minimap du code et j'aimerai qu'il m'indique où se trouve chacun de mes multicurseurs sur celle-ci).

          Au final avec la puissance de Elisp on arrive toujours à s'en sortir… mais à quel prix ! C'est un langage avec une philosophie bien à part, demander à un mec qui veut juste tweaker un truc dans sa conf de l'apprendre c'est un non-sens en terme d’ergonomie.

          Bref on en revient toujours à la courbe d'apprentissage : les anciens ne la voient plus et considèrent les nouveaux qui s'en plaignent comme des incapables. Le fait que j'ai fini par me considérer comme faisant partie de la seconde catégorie après des années d'utilisation régulière d'Emacs témoignera de la dureté de cette courbe (insérer une strip xkcd ici).

      • [^] # Re: Emacs

        Posté par (page perso) . Évalué à 1.

        Long à customiser? Emacs fourni un système de paramétrage très complet avec la commande customize

      • [^] # Re: Emacs

        Posté par (page perso) . Évalué à 2.

        As-tu essayé Spacemacs ? Je trouve que c'est la synthèse réussie entre un VSCode, Emacs et vim.

  • # Pensée du soir

    Posté par . Évalué à 3.

    Si seulement Microsoft pouvait s'occuper aussi de la compatibilité avec Wayland.

  • # Flatpak

    Posté par . Évalué à 2.

    À noter qu'il y a un flatpak disponible sur flathub : https://flathub.org/apps/

  • # Éditeur de code sans le code

    Posté par . Évalué à 3.

    Bonjour,

    Toujours étonné de ces controverses professionnelles sur les éditeurs dans le monde des devs.
    Perso, je suis chercheurs en sciences humaines et j'ai fait au fil des années une lente pente de libreoffice vers vim+markdown (avec un passage LaTeX) pour écrire des articles scientifiques…. Aujourd'hui, je prends mes notes avec Vim, mes tâches avec Vim (via taskwarrior), ma biblio aussi, mon agenda avec Khal…. et je sors plus du terminal.
    Firefox + Terminal = un grand sentiment d'autonomie pro avec peu de ressources mobilisées.
    Ça tourne partout, c'est mobile, c'est durable.
    Suis content et vous remercie tous de contribuer à ces projets merveilleux, utiles et parfois beaux ;-)

    • [^] # Re: Éditeur de code sans le code

      Posté par (page perso) . Évalué à 5.

      Il n'y a pas vraiment de controverse. Simplement, on passe beaucoup de temps dans un éditeur, c'est notre principal outil de travail, après tout. Et c'est bien d'avoir le choix entre différents outils, qui fonctionnent différemment et du coup conviennent aux besoins de chacun. Je suppose que c'est le cas aussi dans la plupart des autres métiers.

Suivre le flux des commentaires

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