Tu es lassé des discutions sans fin sur les thématiques égalitaristes de genre ? Tu trouves que le troll emacs meilleur que vim est périmé depuis au moins une décennie ? (Le consensus semblant être que vim est un meilleur éditeur de texte mais que Emacs est un meilleur OS) Tu souhaiterai que le trolldi tombe un jeudi plutôt qu'un vendredi parce que tu penses trop au week-end pour mouler efficacement ? Tu voudrais recentrer les débats sur la pertinence du JavaScript pour écrire des applications lourdes ?
Si tu as répondu oui à au moins une de ces questions, ce journal est fait pour toi !
À l'époque, j'utilisais SublimeText (même que j'ai acheté la licence) par que ça me permettait de retrouver la même config de travail sous Linux, Mac et Windows.
Mais j'étais chagrin parce que c'est pas libre.
Du coup, quand GitHub a commencé à bosser sur Atom, je l'ai essayé. J'ai pas aimé, ça manquait beaucoup trop de réactivité à mon goût.
Pis un jour j'ai appris que Microsoft avait sorti VSCode. Je me suis dit lol, et parce que je suis une moule de mauvaise foi, j'ai refusé de l'essayer par principe parce que Microsoft bouhcaca, toussa toussa.
Pis un jour, Sam et Max on fait un article dessus. Suite à ma lecture, j'ai décidé de lui laisser sa chance. Et depuis, c'est mon éditeur de développement par défaut.
Et toi, tu es plutôt Atom ou VSCode ?
Si tu as aimé ce journal, n'hésite pas à me mettre un pertinent, à faire un don pour mon tipi et à t'abonner au flux RSS pour ne pas rater les futurs journaux.
# VSCodium
Posté par nico4nicolas . Évalué à 10.
Aux utilisateurs de VSCode, je conseille l'utilisation de VSCodium, une recompilation des sources de VSCode sans ajout de module supplémentaire (Microsoft étant suspecté d'ajouter un module de télémétrie). Le seul changement notable est l'icone et le changement de nom.
[^] # Re: VSCodium
Posté par Ruminant . Évalué à 9.
Le module de télémétrie n’est plus caché depuis quelques temps. Hem, depuis que certaines personnes l’ont découvert justement.
[^] # Re: IT téléphone maison
Posté par Yves (site web personnel) . Évalué à 2.
Le même que celui de la calculatrice ?
->[]
[^] # Re: VSCodium
Posté par Arthur Accroc . Évalué à 4.
Les distributions Linux ayant l’habitude de compiler elles-mêmes les logiciels qu’elles empaquettent, y a-t-il une réelle différence entre la version de VSCode qu’elles proposent et VSCodium ?
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: VSCodium
Posté par Lawless . Évalué à 9.
Le binaire de Visual Studio Code téléchargé sur le site de Microsoft est un logiciel propriétaire avec une licence propriétaire (l'ingénierie inverse, la décompilation ou désassemblage sont interdits) alors que le binaire de VSCodium est logiciel libre sous licence libre MIT.
La licence MIT utilisé par Microsoft pour Visual Studio Code permet à Microsoft d'en faire un logiciel propriétaire. On suppose que Microsoft a juste ajouté la télémétrie. Mais bon impossible de vérifier vu que la licence propriétaire de Visual Studio Code interdit la la décompilation ou le désassemblage :-)
Si Microsoft diffuse des sources en open source, ce n'est pas pour autant pour faire du logiciel libre, puisque tous les logiciels vendus ou données par Microsoft sont des logiciels propriétaires.
[^] # Re: VSCodium
Posté par Yves (site web personnel) . Évalué à 2.
À ce propos, je suppose que le paquetage code dans Archlinux est équivalent à VSCodium, puisque la description dit : « The Open Source build of Visual Studio Code (vscode) editor ».
# VSCode...
Posté par Elfir3 . Évalué à 10.
… mais uniquement pour de l'angular (et encore..). Sinon, difficile d'utiliser autre chose qu'emacs.
# Pour quel langage ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
En général, les éditeurs sont optimisés pour un langage en particuliers. Et ils sont entre pas top et pitoyable pour certain autre.
"La première sécurité est la liberté"
[^] # Re: Pour quel langage ?
Posté par Christie Poutrelle (site web personnel) . Évalué à 6.
Surtout Vim.
[^] # Re: Pour quel langage ?
Posté par jtremesay (site web personnel) . Évalué à 6.
Il dispose d'un système de plugins pour ajouter facilement des langages qui ne seraient pas supportés par défaut.
Je l'utilise pour tout ce qui n'est pas C++ (car dans ce cas j'ai une préférence pour Qt Creator), c'est à dire principalement python, bash, tcl, rust, verilog, plain text.
[^] # Re: Pour quel langage ?
Posté par Wendigo . Évalué à 5.
J'utilise VSCode pour du C, et cela fonctionne impec :) Alors qu'à la base c'est un éditeur en JS pour les technos du web.
[^] # Re: Pour quel langage ?
Posté par cosmocat . Évalué à 6.
Avec Vscode, Microsoft a proposé un serveur Web https://langserver.org/ qui a permis d'avoir un support des fonctionnalités de base pour de nombreux languages (donc il est nul pour presque aucun) et qui est adopté par de plus en plus d'éditeurs.
J'ai vu que Kate était en train de l'implémenter,par exemple.
Ça a permis que vscode ne soit pas mauvais pour beaucoup de languages, ce qui me semble, à créé une certaine synergie et du coup pas mal d'extensions on été développées et il semble qu'il est devenu très bon pour beaucoup.
Il semble qu'il soit particulièrement bon pour python.
# Gros fichiers ?
Posté par Nico C. . Évalué à 2.
Et il se comporte comment avec de "gros" fichiers (genre un log de 25Mo) ?
Parce qu'Atom est extremement mauvais pour gérer ça. Sublime est bien meilleur…
[^] # Re: Gros fichiers ?
Posté par nico4nicolas . Évalué à 3.
Chez moi, quelques secondes pour ouvrir l'éditeur et un fichier de log d'environ 100Mo.
[^] # Re: Gros fichiers ?
Posté par Nico C. . Évalué à 5.
Je viens d'essayer avec un fichier de 350Mo et effectivement il s'en sort très très bien…
Bon, je crois avoir tout ce qu'il me faut avec ce truc. En plus c'est gratuit, y'a pas de popup relou qui me demande d'acheter 10x par jour et c'est pas trop un bloatware.
Mais ça fait chier que ce soit MS quand même… 😆
[^] # Re: Gros fichiers ?
Posté par Matthieu Moy (site web personnel) . Évalué à 10.
Après, bon, Atom, c'est essentiellement un produit GitHub, et donc pas loin d'être un produit Microsoft non plus …
[^] # Re: Gros fichiers ?
Posté par jtremesay (site web personnel) . Évalué à 2.
Les gros fichiers «bruts», il gère très bien.
Ça peut mouliner un peu si il faut appliquer de la coloration syntaxique sur un fichier de 100k lignes de codes…
[^] # Re: Gros fichiers ?
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 10.
Si on a un fichier de 100.000 lignes de code, on a sans doute d’autres problèmes plus graves que la coloration syntaxique…
[^] # Re: Gros fichiers ?
Posté par El Titi . Évalué à 4.
J'aime bien ouvrir les fichiers JSON que je sérialise par exemple avec l'utilisation de TinyDB pour les inspecter.
VS Code finit par péter sur des fichiers d'à peine 20.000 records dès que le parsing doit s'effectuer. C'est un peu dommage.
Mais je conviens que ce n'est pas l'usage courant.
[^] # Re: Gros fichiers ?
Posté par nico4nicolas . Évalué à 2.
Il existe (au moins) une extension de coloration syntaxique applicables aux fichiers de log.
# Eclipse
Posté par Christie Poutrelle (site web personnel) . Évalué à 3.
Depuis 2005, ça marche sur Mac, Windows et Linux, et en plus, ça plante moins souvent que VSCode et gère beaucoup mieux les gros projets avec énormément de fichiers.
Et puis tu mens, VSCode n'est pas écrit en JavaScript, mais en TypeScript.
[^] # Re: Eclipse
Posté par nico4nicolas . Évalué à 7.
Si j'apprécie l'environnement d'Eclipse, je le trouve lourd, surtout au démarrage. Je préfère les éditeurs légers comme… vim.
[^] # Re: Eclipse
Posté par Christie Poutrelle (site web personnel) . Évalué à 1. Dernière modification le 17 octobre 2019 à 18:41.
J'ai un peu menti, pour prendre des notes vite fait, j'utilise (mettre ici le préfixe de ton environnement de bureau)-(edit|notepad|…) (le plus souvent gedit pour ma part).
[^] # Re: Eclipse
Posté par _kaos_ . Évalué à 5.
Salut,
C'est peut-être une question d'usage.
Quand je dois partir sur une session de code, je lance eclipse une fois et c'est parti pour quelques heures. Ce qui est totalement différent de quelques notes dans des fichiers épars pour lesquels j'ouvre et ferme un éditeur "rapide".
Le temps de chargement est donc en O(1) par jour travaillé en ce qui concerne eclipse ;)
Matricule 23415
[^] # Re: Eclipse
Posté par Christie Poutrelle (site web personnel) . Évalué à 1.
Oui oui je suis tout à fait d'accord :)
[^] # Re: Eclipse
Posté par Ruminant . Évalué à 7.
Eclipse qui ne plante pas ? Hem…
[^] # Re: Eclipse
Posté par Christie Poutrelle (site web personnel) . Évalué à 1.
Ça fait bien longtemps (ça se compte en année) qu'Eclipse ne m'a pas lâché dans les mains. Et généralement, ça m'arrive que quand j'utilise des plugins en nightly (oui, je suis un grand malade, mais ceux que j'utilise en nightly sont incroyablement stables).
[^] # Re: Eclipse
Posté par Ruminant . Évalué à 2.
C’est qu’ils se sont améliorés depuis la dernière fois que je l’ai tenté. J’ai eu l’habitude de systématiquement le voir se gaufrer sur une simple ouverture de fichier.
Maintenant, je dois bien dire que tu as quand même un peu raison pour VSCode et même Vim, et bien souvent ce n’est pas l’éditeur en lui-même mais les plugins.
Je bosse avec Go et Python et il se trouve que Go ayant pété la compatibilité avec une myriade d’outils, je me retrouve à relancer Vim à chaque fois que le serveur de complétion s’est planté… c’est pénible.
Fin bref, je veux bien te croire que ça ai changé ;)
[^] # Re: Eclipse
Posté par jtremesay (site web personnel) . Évalué à 7.
[^] # Re: Eclipse
Posté par Christie Poutrelle (site web personnel) . Évalué à 1.
Ah ! Tu avoues !
# J'alterne entre Geany, VS Code et vi
Posté par totof2000 . Évalué à 3.
Avec une grande préférence pour Geany (probablement parce que j'ai pas à chercher trop longtemps comment faire ce que j'ai à faire).
# Ni l'un, ni l'autre
Posté par flan (site web personnel) . Évalué à 9.
Vim (de moins en moins) et PyCharm (ou équivalent dans un autre langage).
J'ai eu du mal à me faire à PyCharm (j'ai longtemps été un pur adepte de vim), mais une fois adapté, je n'ai jamais pu retrouver la même efficacité ni la même qualité de code en utilisant vim (même si je tape plus vite avec vim, j'ai moins de choses à taper avec PyCharm).
[^] # Re: Ni l'un, ni l'autre
Posté par nlgranger . Évalué à 1.
J'ai eu la même expérience, j'ai essayé d'autres éditeurs mais aucun ne propose le même niveau de fonctionnalités ni la même qualité d'intégration ou des performances.
[^] # Re: Ni l'un, ni l'autre
Posté par Shyne . Évalué à 2. Dernière modification le 17 octobre 2019 à 21:21.
J'ai longtemps utilisé PyCharm aussi, depuis 2 mois je suis passé sur VSCode et c'est vrai que c'est agréable à utilisé (une fois qu'il est paramétré)
Par contre il faut reconnaître qu'avec PyCharm il n'y a pas grand chose à faire pour avoir un environnement prêt à l'emploi.
Avec VSCode il m'a fallu beaucoup plus de temps et c'est pas encore parfait.
[^] # Re: Ni l'un, ni l'autre
Posté par YBoy360 (site web personnel) . Évalué à 3.
Intellij écrase tout (la base de PyCharm), est OpenSource et fonctionne sur Windows, Mac et Linux.
On ne peut pas parler d'IDE sans le mentionner.
[^] # Re: Ni l'un, ni l'autre
Posté par El Titi . Évalué à 7.
Non, comme tous les IDE de Jetbrains, tu as un core open source et certains modules, souvent indispensables, sont proprio.
https://www.jetbrains.com/pycharm/features/
(Pas de Web development par exemple)
C'est de l'opensource washing comme IBM l'a pratiqué en son temps avec Eclipse/WAS.
Avec VS Code, Microsoft joue le jeu jusqu'au bout.
[^] # Re: Ni l'un, ni l'autre
Posté par barmic 🦦 . Évalué à 3.
Je ne suis pas d'accord. Je ne considère vraiment pas le web comme étant une fonctionnalité essentielle à un IDE python. C'est tellement pas essentiel que je l'utilise depuis 5 ans en version community sans frustration. J'ai essayé la version ultimate, j'en ai même une licence avec la boîte où je travaille, mais la version community me convient amplement.
Par contre j'ai arrêté les EAP de la version 2019.4 qui n'étaient pas très stables.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# neovim
Posté par Psychofox (Mastodon) . Évalué à 10. Dernière modification le 17 octobre 2019 à 19:31.
parce qu'atom et vscode pour moi c'est bonnet blanc et blanc bonnet. Ça démarre pas mégavite, ça prend une tétrachiée de ram et ça ne tient pas dans un terminal.
# Embrace, extend and extinguish
Posté par Eric . Évalué à -1.
Pour ceux qui aurait la mémoire courte (Atom et VSCode étant des produits Microsoft):
[Embrace, extend and extinguish]
[^] # Re: Embrace, extend and extinguish
Posté par barmic 🦦 . Évalué à 4.
Cette comptine ne fonctionne que pour les formats, les standards et tout ce qui revient à des interactions. Tu ressemble à l'existant, tu en fais plus et une dis que tu es suffisamment gros tu as la main mise sur le domaine.
Tu ne peux pas faire ça avec un éditeur de texte.
Surtout qu'une bonne partie de l'intelligence du truc a été volontairement architecturée pour être utilisable ailleurs et est utilisé ailleurs (par eclipse par exemple). Et ça résous un casse tête pour les créateurs de langage.
Donc au lieu d'affirmer que les gens ont des problèmes de mémoire, je veux bien que tu nous montre que tu n'as pas de problème de compréhension de ce que tu met en lien ;)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Embrace, extend and extinguish
Posté par nico4nicolas . Évalué à 3.
Atom a été développé avant l'acquisition de Github par Microsoft. Atom est un logiciel libre (licence MIT). VSCode a deux licences, le code source est libre (licence MIT), le binaire est propriétaire.
Le fait que les sources soient libres, cela permet de forker facilement (ex : VSCodium) et la stratégie "Embrace, extend and extinguish" ne me parait pas possible dans ce contexte.
[^] # Re: Embrace, extend and extinguish
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Ou alors, c'est GitHub qui a été développé avant l'acquisition d'Atom par Microsoft, et s'ils ont mis 7,5 M$ pour acheter un éditeur de texte, ils devaient avoir une idée derrière la tête ;-).
[^] # Re: Embrace, extend and extinguish
Posté par Eric . Évalué à 1.
La page du wikipédia anglais donne plus d'exemples :
Embrace, extend and extinguish
# VSCode
Posté par Dafyd . Évalué à 10.
J’utilise souvent VSCode, je trouve que c’est un très bon outil. Il a des performances très correctes comparé à Atom. Ça bouffe beaucoup de RAM par contre, Électron inside… mais quand même, chapeau bas aux dev de chez MS, qui ont réussi à pondre un éditeur très performant avec un framework aussi bloaté.
Maintenant, je n’aime pas cette tendance à rajouter un moteur JS dans tout et n’importe quoi. Même Qt s’y est mit, avec Qt Quick, ou l’art et la manière de faire une appli qui fait la même chose qu’avant mais en consommant 5 fois plus de RAM. Exemple concret : le text editor qui est fourni dans les tuto de QtCreator. La version QWidgets prend environ 20Mo de RAM sur ma machine. La version QtQuick, 100. Pour le même périmètre fonctionnel.
Pour moi, Electron c’est pareil, et c’est symptomatique de l’état d’esprit de beaucoup de dev Web : la fuite en avant vers des frameworks toujours plus hype et toujours plus bloatés. Qu’importe si le butineur doit déployer des trésors d’optimisation pour réussir à afficher 1 pauvre page à l’écran en moins de 10 secondes.
C’est pas parce que les PC ont plein de RAM qu’il faut en bouffer le maximum possible pour tout et n’importe quoi…
[^] # Re: VSCode
Posté par cosmocat . Évalué à 5.
Je suis un peu du même avis même si il faut reconnaitre à cette stratégie quelques avantages:
# Electron non merci
Posté par David Demelier (site web personnel) . Évalué à 10.
J'ai essayé Atom et VSCode quand j'étais dans une entreprise qui faisait du développement Web. J'ai été abasourdi par la lenteur de ce dernier alors que j'avais une machine de guerre.
En plus, la consommation excessive de RAM sur les gros projets ont déclenché par plusieurs fois l'OOM sur Linux chose rare (ayant pourtant 8Go de RAM). Tout cela parce que je faisais du VSCode + npm + Slack. 3 « applis » qui suffisent à mettre une machine KO, c'est du délire.
De toute façon je suis trop féru de vim, je l'utilise en éditeur par défaut (texte, C++, shell) et met l'extension partout où je peux (pour Visual Studio à mon emploi actuel par exemple, rendant fous mes collègues quand ils passent chez moi).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Electron non merci
Posté par Firwen (site web personnel) . Évalué à 10.
+1
Si j'apprécie le nombre de fonctionnalités de ces éditeurs. Ils sont souvent aussi réactif et consommateur de mémoire, et long à charger que Eclipse à ses pires heures de honte.
Car c'est Vendredi, Je dirai que Electron a réussi à associer la consommation mémoire infame des Apps Java, la réactivité horribles des GUI Web, et le truffage de bug de la programmation événementiel mono-threadé à la Visual Basic. C'est assez respectable comme combo, c'était dur à faire.
[^] # Re: Electron non merci
Posté par j_m . Évalué à 2. Dernière modification le 19 octobre 2019 à 18:31.
Quelqu'un sait d'où vient cette réputation de consommation mémoire de java?
Je programme sur la JVM et j'ai l'impression d'avoir un certain contrôle sur la mémoire. Moins je charge de données/de classes moins je consomme de mémoire. Alors qu'est-ce qui fait que les gens se plaignent?
[^] # Re: Electron non merci
Posté par nokomprendo (site web personnel) . Évalué à 2.
Peut-être d'ici : https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java.html
[^] # Re: Electron non merci
Posté par Firwen (site web personnel) . Évalué à 5. Dernière modification le 20 octobre 2019 à 10:45.
Tout programme utilisant un Garbage Collector utilise en moyenne de 3X à 10X la mémoire d'un programme ayant une gestion manuelle ( C, C++, Rust) ou ARC (Swift, Python).
C'est un fait qui a été longuement étudié. Si il est possible de réduire cette surconsommation, mais ça se fait au détriment des performances.
Dans le cas des Apps Java clients, l'effet est encore pire due au modèle objet très verbeux utilisé par Swing et autre ToolKit GUI qui a tendance à créer un grand nombre de petits objets en mémoire.
[^] # Re: Electron non merci
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
lua ou erlang utilisent un garbage collector et ont des consommations mémoires beaucoup plus raisonnables.
Java vient avec une énorme et gigantesque bibliothèque (le JRE), on l'utilise généralement avec des énormes et gigantesques framework (Spring) pour coder d'énormes et gigantesques applis métiers.
Bigger is bigger.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Electron non merci
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Pas seulement. J'ai souvenir du transfert d'un objet c++ qui représentait un document à un objet en Java, le modèle java était 10x plus gros.
Cela peut s'expliquer par le boxing assez systématique en Java (structure tout seul avec un pointeur dessus, et non directement embarqué dans l'objet parent), donc plein de pointeur partout en plus.
"La première sécurité est la liberté"
[^] # Re: Electron non merci
Posté par claudex . Évalué à 8.
Il y a aussi que c'est un langage très utilisé dans les entreprises qui emploient des pisseurs de code^W^W^W développeurs à la chaîne et que ces derniers sont dans des conditions où il faut sortir vite une fonctionnalité quelque soit le coût (presque). L'optimisation n'est fait que si on n'arrive pas à trouver un machine pour faire tourner le soft.
Ça fait qu'on fait tourner des softs qui consomment beaucoup de mémoire.
(accessoirement, si on leur demandait de faire ça en C/C++, on aurait des programmes qui segfault remplies de failles de sécurité. Et c'est pour ça qu'un langage comme rust n'est pas prêt de remplacer java, vu le coût en fonctionnalité qu'il apporte)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Atom / VSCode
Posté par flagos . Évalué à 6. Dernière modification le 18 octobre 2019 à 15:24.
C'est plus que prometteur, ca marche pas mal sur emacs ce fameux LSP. Je l'utilise pour développer du python, ca doit faire un an environ et pas de soucis majeur. Je confirme pour magit, c'est juste une tuerie ce truc.
Je plussoie également ton aversion des menus. La seule bonne interface pour un IDE, c'est de n'afficher que le code. Les menus sont une perte de temps, ca sert juste à distraire les newbies, mais en vrai ca sert a rien. Je ne sais même pas comment on peut qualifier de "bonne" une interface qui n'affiche que 50% de code. Enlevez les menus de vos interfaces et apprenez les raccourcis claviers, c'est le seul moyen d'être productif. Une fois que vous en êtes la, vous êtes prêts à passer a emacs ou vim :-)
Une autre feature d'emacs (ou de vim) que l'on ne retrouve pas sur les machins en javascript, c'est de marcher dans screen. Lorsque je travaille avec un seul écran, screen est très pratique car je met mon emacs dans une "window". Avec ca, je peux rester des heures sans toucher la souris.
Allez, je suis d'humeur, je partage ma petite config emacs si ca en intéresse quelques uns:
https://github.com/flagos/emacs-config
[^] # Re: Atom / VSCode
Posté par barmic 🦦 . Évalué à 1. Dernière modification le 20 octobre 2019 à 00:57.
C'est surprenant d'utiliser screen comme ça. Moi je préfère utiliser juste Emacs. Tant que je n'ai pas besoin de sessions persistantes (et encore je ne suis pas sûr que ça n'existe pas dans emacs), je préfère amplement tout faire via emacs. C'est plus logique et nettement mieux intégré.
Si je ne trouve pas de sessions persistantes dans emacs, j'utiliserai screen (ou tmux) uniquement pour ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Et toi, tu es plutôt Atom ou VSCode ?
Posté par rewind (Mastodon) . Évalué à 4.
Kate me satisfait pleinement ! Et avec le plugin LSP qui va bientôt arriver, ça promet d'être encore mieux.
[^] # Re: Et toi, tu es plutôt Atom ou VSCode ?
Posté par blobmaster . Évalué à 2. Dernière modification le 18 octobre 2019 à 10:16.
Excuses moi si je débarque mais que veux tu dire par "le plugin LSP" ?
[^] # Re: Et toi, tu es plutôt Atom ou VSCode ?
Posté par cosmocat . Évalué à 3.
https://linuxfr.org/nodes/118371/comments/1787255
[^] # Re: Et toi, tu es plutôt Atom ou VSCode ?
Posté par blobmaster . Évalué à 2.
Merci.
# Pour ceux qui sont un peu perdus…
Posté par jseb . Évalué à 10.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
# Vis
Posté par karchnu . Évalué à 10. Dernière modification le 18 octobre 2019 à 12:02.
Alors, c'est très peu connu pour l'instant, mais l'éditeur que j'utilise en ce moment pour écrire du Crystal, mes mails, des scripts, et tout un tas d'autres trucs, c'est vis.
Pour faire simple : c'est vim mais sans le code historique, avec
Et les développeurs ont aussi déterminé des non-objectifs clairs qui me font dire qu'ils vont dans le bon sens (pour un éditeur de code, pour la simplicité du code, pour garder un éditeur qui ne fait qu'éditeur, etc.).
Je reconnais cependant que tant qu'on n'aura pas implémenté le Language Server Protocol, il restera moins intéressant que n'importe-quel autre éditeur pour ceux qui veulent un outil les aidant à l'écriture de code.
Mais voilà, pour moi c'est une vraie bonne piste.
[^] # Re: Vis
Posté par Jean-Max Reymond (site web personnel) . Évalué à 1.
j'étais alléché par ce commentaire et je me suis empressé de l'essayer. Mais essayer, n'est pas l'adopter. Tout d'abord, pas de nouvelle version depuis quasiment deux ans, cela sent l'abandon en rase campagne. Ensuite, à l'utilisation, je me suis rendu compte qu'avec vim, j'utilise très souvent l'historique des commandes. Ainsi, pour une recherche, je fais /lin et avec la flèche vers le haut, je vais essayer de retrouver dans l'historique des commande une recherche commençant par lin. idem pour les global substitute. Le ZZ m'interpelle aussi en faisant systématiquement une écriture et en modifiant donc la date de dernière écriture.
Sinon, c'est un très bon début mais qui semble arrêté.
[^] # Re: Vis
Posté par karchnu . Évalué à 2.
Ce n'est pas un projet mort, mais oui, il bouge assez peu et comme toi je me retrouve avec pas mal de commandes qui me manquent. Je voulais surtout montrer quelque-chose qui sort du lot, et je pense qu'il ne manquerait pas grand chose pour remplacer mon vim complètement.
# Mon amour reste Sublime
Posté par Philippe F (site web personnel) . Évalué à 3.
J'avoue que je reste fidèle à Sublime. J'ai essayé VSCode qui était globalement pas mal, sauf que plutôt lent et catastrophique pour le debuggage de Python. Du coup, PyCharm (avec le plugin Vi) pour debugger, Sublime Text pour tout le reste. Je regrette pas d'avoir payé ma licence.
Par contre, ma config Sublime s'est dégradée, j'ai maintenant un contraste pourri pour les couleurs et mon mode Vi est moins performant qu'avant, genre certaines commandes ne passent plus bien. J'imagine que je me suis maillé entre les NeoVintageous, Vintage et autres plugins vi.
# Atom/Juno/Julia
Posté par mac_is_mac (site web personnel) . Évalué à 2. Dernière modification le 19 octobre 2019 à 05:50.
Bonjour,
Pour ma part, j'utilise le plugin Juno pour Atom pour programmer en Julia.
Depuis quelques mois, Julia a un débogueur qui est bien intégré à Juno; c'est très pratique.
Je n'ai pas observé de problème de lenteur.
# VSCode ? Bien ?
Posté par Cᴬᴾᵀ Samavor . Évalué à 1.
J'ai très brièvement testé VSCode y'a quelque-temps (en dev c++) et je n'ai pas été convaincu.
Mais je ne me rappelle plus de ce qui me posait problème. Va falloir que je re-teste.
# VS et Atom: 10aines de milliers de fichiers pour quelques plugins, par utilisateur
Posté par Legrego . Évalué à 2.
Un autre problème avec ces deux éditeurs est qu'ils sont conçus pour des machines avec une poignée d'utilisateurs. Pour avoir quelques greffons (plugins) ils font la création, pour chaque utilisateur, de dizaine de milliers de fichiers dans les .atom/ ou .vscode/.
VScode en met un peu moins dans la racine, mais il en met dans chaque entrepôt git.
Aucun des deux ne sait partager ses fichiers entre utilisateurs.
Bref, quand vous avez un millier d'utilisateurs et des sauvegardes qui fonctionnent fichier par fichier, ils sont un problème.
(Pour compter: du --inodes ~/.atom )
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.