Journal un éditeur de code portable par Microsoft?

Posté par freem le 09 février 2018 à 10:31. Licence CC By‑SA.

Étiquettes :

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 Cheuteumi le 09 février 2018 à 10:39. É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 manatlan (site web personnel) le 09 février 2018 à 12:14. É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 pulkomandy (site web personnel, Mastodon) le 09 février 2018 à 10:42. É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 jtremesay (site web personnel) le 09 février 2018 à 11:26. Évalué à 2. Dernière modification le 09 février 2018 à 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 Cheuteumi le 09 février 2018 à 11:31. Évalué à 2. Dernière modification le 09 février 2018 à 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 jtremesay (site web personnel) le 09 février 2018 à 15:00. É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 Psychofox (Mastodon) le 09 février 2018 à 16:33. É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 Cheuteumi le 09 février 2018 à 16:45. É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 Psychofox (Mastodon) le 09 février 2018 à 11:34. É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 Yuul B. Alwright le 09 février 2018 à 20:19. Évalué à 4.
  
  Emacs tourne sans problème sur Centos 6*. ;)
# retour d'utilisation

Posté par Psychofox (Mastodon) le 09 février 2018 à 11:32. É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 Wawet76 le 09 février 2018 à 11:37. É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 Psychofox (Mastodon) le 09 février 2018 à 11:48. Évalué à 2.
  
  Cette remarque n'est valable que si tu utilises leur dépôts.
- [^] # Re: C'est libre ?
  
  Posté par dguihal le 09 février 2018 à 14:18. É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
  - [^] # Re: C'est libre ?
    
    Posté par lfb4 le 11 février 2018 à 04:17. Évalué à -1.
    
    En bref, c'est un logiciel privateur déguisé en logiciel libre.
    - [^] # Re: C'est libre ?
      
      Posté par Croconux le 11 février 2018 à 13:57. Évalué à 4.
      
      https://github.com/Microsoft/vscode
      
      License MIT
  - [^] # Re: C'est libre ?
    
    Posté par Olivier Abad le 11 février 2018 à 07:12. Évalué à 4.
    Apparemment, il suffit d'ajouter quelques lignes dans le product.json pour que ça fonctionne :
    Can I put the extensionsGallery on my vscode fork?
```
"extensionsGallery": {
    "serviceUrl": "https://marketplace.visualstudio.com/_apis/public/gallery",
    "cacheUrl": "https://vscode.blob.core.windows.net/gallery/index",
    "itemUrl": "https://marketplace.visualstudio.com/items"
}
```
# Rien de lié à un langage de script ?

Posté par Adrien BUSTANY (site web personnel) le 09 février 2018 à 11:40. É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
- [^] # Re: Rien de lié à un langage de script ?
  
  Posté par gnumdk (site web personnel) le 09 février 2018 à 16:22. Évalué à 2.
  
  Je lis Electron, je passe à la suite…
  - [^] # Re: Rien de lié à un langage de script ?
    
    Posté par Guillaume Denry (site web personnel) le 09 février 2018 à 18:54. Évalué à 1.
    
    Ca fait du bien ?
  - [^] # Re: Rien de lié à un langage de script ?
    
    Posté par Sufflope (site web personnel) le 09 février 2018 à 21:02. Évalué à 0.
    
    Deux intellectuels assis iront moins loin qu'un con qui marche.
    - [^] # Re: Rien de lié à un langage de script ?
      
      Posté par wismerhill le 09 février 2018 à 23:39. Évalué à 10.
      
      Si seulement il marchait dans la bonne direction …
      - [^] # Re: Rien de lié à un langage de script ?
        
        Posté par Sufflope (site web personnel) le 10 février 2018 à 12:00. Évalué à -10.
        
        Et ça vous n'en savez rien avec votre attitude de vieux con débile "y a marqué Electron alors c'est forcément nul", vous ne verrez jamais que votre vieux banc pourri. Mais bon on vous tiendra au courant savoir si le futur est cool ! Nan je déconne, on vous laissera y crever en silence, on a autre chose à faire.
        
        [^] # Re: Rien de lié à un langage de script ?
        
        Posté par wismerhill le 10 février 2018 à 12:14. Évalué à 3.
        
        Je ne suis pas celui à qui tu répondais.
        
        [^] # Re: Rien de lié à un langage de script ?
        
        Posté par Philip Marlowe le 12 février 2018 à 18:35. Évalué à 5.
        
        Ça lui fait souvent ça quand il s'est fait moinsser, bizarrement presque tout le temps après un commentaire méprisant, le public ici est vraiment partial. Sûrement un cas médical intéressant.
- [^] # Re: Rien de lié à un langage de script ?
  
  Posté par z8080 le 12 février 2018 à 18:34. Évalué à 3.
  
  Si ça tourne dans un browser ça doit être bien lourd en mémoire, non?
# Electron

Posté par gouttegd le 09 février 2018 à 11:43. É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 syntaxerror le 09 février 2018 à 12:16. É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 vv222 le 23 février 2018 à 17:20. É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 mzf (site web personnel) le 09 février 2018 à 14:04. Évalué à 4. Dernière modification le 24 août 2019 à 18:10.

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 Frank-N-Furter le 09 février 2018 à 15:09. É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 mzf (site web personnel) le 09 février 2018 à 15:15. É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 gouttegd le 09 février 2018 à 15:36. É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 mzf (site web personnel) le 09 février 2018 à 15:54. É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 Claude SIMON (site web personnel) le 09 février 2018 à 14:10. É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…

Pour nous émanciper des géants du numérique : Zelbinium !
- [^] # Re: VSCode -> Electron -> Node.js
  
  Posté par Tonton Th (Mastodon) le 10 février 2018 à 17:27. Évalué à 4.
  
  application Electron, qui est émanation de l'éditeur Atom
  
  Et le prochain truc à la mode s'appellera BBC ou Archimedes ?
  - [^] # Re: VSCode -> Electron -> Node.js
    
    Posté par fasthm le 11 février 2018 à 21:29. É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 Ririsoft le 09 février 2018 à 14:52. É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 cosmocat le 09 février 2018 à 17:33. É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)…
  - [^] # Re: Une vrai communauté
    
    Posté par Ririsoft le 13 mars 2018 à 17:21. Évalué à 1.
    
    Je ne le savais pas :-)
# Réinvention de la roue

Posté par Guillawme (site web personnel, Mastodon) le 09 février 2018 à 19:33. É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).
- [^] # Re: Réinvention de la roue
  
  Posté par G.bleu (site web personnel) le 10 février 2018 à 10:50. Évalué à 5.
  
  Déjà ce serait bien que Emacs et XEmacs se réconcilies, on verra ensuite pour unifier le reste…
  - [^] # Re: Réinvention de la roue
    
    Posté par Guillawme (site web personnel, Mastodon) le 10 février 2018 à 18:51. Évalué à 4. Dernière modification le 10 février 2018 à 18:54.
    
    En moins d'une minute de navigation sur le site de XEmacs, j'apprends que la dernière version stable qu'ils proposent au téléchargement date du 30 janvier 2009, et la dernière version beta date du 24 juin 2013.
    
    D'autre part, GNU Emacs propose une nouvelle version stable en moyenne une fois par an depuis 2001. La plus récente date du 11 septembre 2017. Le plus récent commit sur leur dépôt git date d'aujourd'hui (à l'heure où j'écris).
    
    On peut donc raisonnablement considérer que XEmacs est mort, et que GNU Emacs est la version maintenue et à jour. :-)
# Emacs

Posté par Yuul B. Alwright le 09 février 2018 à 21:58. É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 Sacha Trémoureux (site web personnel) le 09 février 2018 à 22:28. É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 Yuul B. Alwright le 09 février 2018 à 23:37. É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 G.bleu (site web personnel) le 10 février 2018 à 11:27. É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 Yuul B. Alwright le 10 février 2018 à 01:05. Évalué à 1.
    
    Long à customiser? Emacs fourni un système de paramétrage très complet avec la commande customize
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 02 mars 2018 à 14:51. Évalué à 2.
    
    Ce commentaire a été supprimé par l’équipe de modération.
# Pensée du soir

Posté par alexandre.nikolic le 10 février 2018 à 02:24. Évalué à 3.

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

Posté par ff9097 le 11 février 2018 à 11:42. Évalué à 2.

À noter qu'il y a un flatpak disponible sur flathub : https://flathub.org/apps/
# Éditeur de code sans le code

Posté par bepolymathe le 14 février 2018 à 22:54. É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 pulkomandy (site web personnel, Mastodon) le 15 février 2018 à 13:49. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.