Profitons de la torpeur estivale pour présenter Atom, un éditeur de code source multi plates-formes développé par GitHub et que nous n'avons pas encore eu l'occasion de présenter ici même. Depuis plus d'un an en version bêta, il s'est vu gratifier il y a quelques semaines du numéro de version symbolique 1.0 par son éditeur (il est actuellement en 1.0.7).
NdM : ce logiciel Atom ne doit pas être confondu avec le format ouvert de syndication Atom, utilisé par LinuxFr.org par exemple.
Écrit en CoffeeScript sur la base de Chromium, il se repose sur un mécanisme d'extensions en Javascript sur la base de Node.js pour les fonctionnalités et de personnalisation par thèmes. Tout comme pour Vim ou Emacs, vous pouvez le transformer en un environnement de développement intégré (IDE) très puissant et unique taillé pour votre usage. Partagez-les en commentaires.
Rapide description
Comme précisé sur le site web, Atom :
- est multi-plateforme (Linux, Mac OS X et Windows) ;
- propose un gestionnaire de paquets et de thèmes ;
- est un logiciel libre : le cœur Atom et les nombreux paquets de base fournis par GitHub sont sous licence MIT ;
- propose une auto-complétion relativement bien faite ;
- a une interface avec onglets et de multiples panneaux ;
- sait gérer l'ensemble des fichiers d'un projet, avec une vue arborescente façon Eclipse par exemple ;
- a une interface de base épurée et fonctionne principalement à base de commandes clavier. Si vous n'en avez qu'une à retenir, c'est [Ctrl]+[Shift]+[P] qui affiche le sélecteur de commandes ;
- est écrit entièrement avec des technologies web récentes : HTML, Javascript/CoffeeScript, CSS, Node.js, etc.
- s'interface naturellement et par défaut avec git, on peut s'en douter.
L'écran de bienvenue vous permet de démarrer assez rapidement et vous informe aussi explicitement que l'outil collecte quelques statistiques anonymes (hum, hum…) que vous pouvez très vite désactiver en retirant le paquet metrics.
Le nombre d'extensions disponibles pour Atom est déjà très important. Plus de 2 500 au moment de l'écriture de cette dépêche. Cela va de la mini-carte du code source à l'« embellisseur » de code en passant par des modes vim/emacs plus ou moins complets ou encore la désactivation de touches ou la gestion de la syntaxe Markdown. Pratique pour rédiger des dépêches sur LinuxFr.org !
Petit historique
L'histoire, racontée un peu partout veut que l'un des fondateurs de Github, Chris Wanstrath soit un grand fan d'Emacs, de son mécanisme d'extension et surtout de sa profonde « bidouillabilité ». Mais il était gêné par le fait qu'il faille utiliser Lisp (voire une version spéciale Emacs de Lisp) pour le hacker.
Il s'est donc lancé en 2008 dans le codage d'un éditeur avec le même niveau de bidouillabilité mais avec des technologies plus modernes, basées sur celles du web. Comme c'était un projet en marge de Github qui lui demandait beaucoup d'attention, il y allait piano en espérant qu'un éditeur moderne et répondant à ses attentes s'impose. Mais voyant que rien ne sortait vraiment et que Github était sur les rails, il s'est remis à l'ouvrage pour sortir Atom 1.0 sous une licence libre. Désormais une personne est embauchée à temps plein pour travailler dessus.
Désormais, l'outil commence à réellement montrer sa polyvalence, avec Facebook qui a créé Nuclide, un IDE spécial et adapté pour gérer et coder sur l'immense base de code interne. D'autres comme Nylas le transforment en un logiciel de traitement de courriels.
Aller plus loin
- Annonce d'Atom 1.0 (Ne manquez pas la vidéo, elle mérite le détour) (1056 clics)
- Site web d'Atom (1232 clics)
- Wired : GitHub Atom’s Code-Editor Nerds Take Over Their Universe (176 clics)
- FAQ d'Atom (177 clics)
- Documentation complète d'Atom (298 clics)
- Code source d'Atom (166 clics)
# Oui..., mais...
Posté par rdhlnn . Évalué à 10.
Oui c'est un bon éditeur qui fonctionne directement, qui est beau (graphiquement) et qui est facilement installable et utilisable. Cela pourrait être à conseiller pour des gens qui commencent à s'intéresser à la programmation. Je l'ai d'ailleurs conseillé à quelqu'un qui débutait la programmation (python), et qui se mettait à écrire en Markdown et LaTeX.
Mais je l'ai très vite déconseillé (peut-être est-ce de l'intransigeance) en découvrant avec stupeur l'opt-in de google analytics et sa lenteur par rapport aux autres éditeurs (à cause du javascript ?). Vous avez aussi remarqué comme c'est lent ?
Alors qu'ai-je conseillé à la place ? D'apprendre à utiliser vim (un tuto interactif), c'est toujours utile de connaître les déplacements vim, et de regarder ce qui convient le mieux entre vim et emacs (et les perspectives nouvelles, neovim et spacemacs par ex., ça paraît intéressant). C'est dans les vieilles casseroles qu'on fait les meilleurs code spaghettis.
[^] # Re: Oui..., mais...
Posté par Sébastien Douche . Évalué à 3.
C'est pour l'instant le point qui me bloque pour passer sur Atom. Si la vitesse n'est pas trop déconnante sur i5 récent, c'est une véritable catastrophe sur mon vieux i3. J'ai vu aussi des versions qui ne voulaient pas s'upgrader, des bugs GUI ici et la…
Même si certains plugins donnent vraiment envie, c'est pas aujourd'hui que je lâcherais ST3. Mais je teste Atom régulièrement pour voir.
[^] # Re: Oui..., mais...
Posté par M.Poil (site web personnel) . Évalué à 6.
Vous me faites plaisir, des collègues ne jurent que par cet éditeur, sur mon PC (pourtant un Core I7 de 3e Génération et un SSD) j'ai toujours l'impression de latence qui le rend très désagréable d'utilisation …
Bref pour le moment je reste à mon VIM + Syntastic
Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
[^] # Re: Oui..., mais...
Posté par cluxter . Évalué à 2.
J'ai un vieux Core2 Duo T9200 @2.5 Ghz et pourtant il est très réactif, mais je suis sous Arch.
Je l'ai testé sous Windows 7 avec un Core i5 et là c'était l'enfer (jusqu'à plus d'une seconde de décalage quand j'ai plusieurs logiciels d'ouverts, alors que la RAM est loin d'être saturée).
Donc l'OS joue quand même un grand rôle. Ceci étant dit ce n'est tout de même pas normal.
[^] # Re: Oui..., mais...
Posté par khertan . Évalué à 1.
Mouais …
Je tourne sur une debian avec i3 sans compositeur, que ce soit sur le laptop (x200 core2duo) ou le desktop (un i5 16go de ram), je trouve cela lent pourtant j ai juste un terminal d ouvert à coté et c est lent.
De base il est pas trés réactif. Mais dés que l on rajoute un ou deux plugin … cela devient un carnage. J aime beaucoup SublimeText3 aussi mais le coté non libre me gène, alors je cherche toujours une alternative à vim ou pourquoi je n arrive a me satisfaire de vim :)
[^] # Re: Oui..., mais...
Posté par cluxter . Évalué à 2.
Finalement j'ai mis Archlinux dans une machine virtuelle sous Virtualbox, et je fais tourner Atom dedans, plutôt qu'en natif sous Windows. Et croyez-le ou non, c'est beaucoup plus réactif !
[^] # Re: Oui..., mais...
Posté par karteum59 . Évalué à 7.
A la limite, ce n'est pas la lenteur CPU qui me choque, mais plutôt la consommation de RAM (mon vieux laptop est au max de son extensibilité avec ses 4 GB de RAM, et entre Firefox (ou Chrome) avec qq onglets + une ou deux sessions Atom, mon ordi se met rapidement à swapper et devient inutilisable !)
[^] # Re: Oui..., mais...
Posté par G.bleu (site web personnel) . Évalué à 6.
J'étais dans le même cas avec mon thinkpad de 2010, j'ai acheté 8go de ram pour 60€ et ça m'a fait économiser un nouveau pc à 1000€ (plus le plaisir de ne pas avoir créé de déchets inutilement)
Franchement ça + 150€ de ssd n'importe quel pc est paré pour les années à venir !
…
Bon par contre j'ai toujours pas osé retenter Atom tellement c'était lent la dernière fois (je sens que le troll sur les applications java desktop lentes va être remplacé par celui des application basées sur webkit…)
[^] # Re: Oui..., mais...
Posté par karteum59 . Évalué à 6. Dernière modification le 18 août 2015 à 11:16.
Oui je suis d'accord, mais tu as lu mon commentaire ? :)
(mon vieux laptop est au max de son extensibilité)
[^] # Re: Oui..., mais...
Posté par Olivier . Évalué à 3.
J’ai réessayé la dernière version il y a quelques jours. L’éditeur fige tout simplement pendant plusieurs minutes au démarrage, probablement à cause d’un fichier du projet qui est un peu gros (plus de 2000 lignes). Parfois, il plante.
J’ai un octocœur et, oui, ça rame pas mal.
[^] # Re: Oui..., mais...
Posté par Plume . Évalué à 4.
Tu as beau avoir 36-milles cœurs, si ton programme n'en utilise que un ou deux, ça ne change rien.
[^] # Re: Oui..., mais...
Posté par Christophe B. (site web personnel) . Évalué à 1.
Vim bien sur
[^] # Re: Oui..., mais...
Posté par pouleta . Évalué à 1.
Ah le sale troll !
J'utilise les deux \o/
[^] # Re: Oui..., mais...
Posté par woprandi . Évalué à 0.
Evil
[^] # Re: Oui..., mais...
Posté par Christophe B. (site web personnel) . Évalué à 2.
Comme quoi les bons vieux trolls … font toujours leur petit effets
Juste un petit point d'avance pour Emacs … allons Vimien
Ne vous laissez pas avoir par ces bêtes poilus à 6 doigts que sont les emacsiens
# Et un anglicisme, un…
Posté par whity . Évalué à 10.
Dois-je comprendre que, bien qu’étant en version 1, l’outil est instable ? ( http://www.cnrtl.fr/definition/versatilité.
On dit polyvalence dans la langue de Molière ;).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Et un anglicisme, un…
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 5.
C'est corrigé, merci. C'est surprenant que
LanguageToolne me l'ait pas signalé.[^] # Re: Et un anglicisme, un…
Posté par spider-mario . Évalué à 1.
Pas si surprenant que ça puisque ça aurait du sens aussi (mais pas le même). LanguageTool ne peut pas (toujours) lire dans les pensées. :p
# Manque un truc
Posté par Blount (site web personnel) . Évalué à 8.
Je l'avais déjà lancé pour voir à quoi il ressemblait.
Un truc qui me manque et qui m'est indispensable, c'est la possibilité de cliquer sur une fonction/méthode/etc. et d'aller directement dans le fichier et à la ligne concerné.
Par exemple, dans Eclipse, je fais Ctrl + clic sur une méthode et ça ouvre le fichier où se trouve la classe et ça me met au bon endroit dans le fichier.
Alors peut-être qu'il existe un package le permettant mais bon, 2500 packages ce n'est pas si bien que ça en fin de compte car il n'est pas évident de trouver le package qui va bien.
[^] # Re: Manque un truc
Posté par Yuul B. Alwright . Évalué à -1.
Ɛmacs le fait.
[^] # Re: Manque un truc
Posté par gyscos . Évalué à 1.
ctags a des intégrations pour beaucoup d'éditeurs.
[^] # Re: Manque un truc
Posté par Stibb . Évalué à -10.
bienvenue dans le monde réel néo. La modularité a pour corollaire qu'un packet peut apparaitre demain pour ajouter cette fonctionnalité. Il faut regarder du coté des actualités des extensions, essayer, recommencer, en gros, se bouger soi-même au lieu d'attendre l'éditeur de texte ultime 'out-of-the-box"
[^] # Re: Manque un truc
Posté par barmic . Évalué à 10.
Ou alors il utilise celui qui fait déjà le boulot ?
Le fait qu'il ai essayé et donné son avis ne l'empêche pas de retourner à son éditeur habituel.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Manque un truc
Posté par rogo . Évalué à 10.
Je suis d'accord. Comme IDE, contrairement à ce que qu'affirme la dépêche, Atom est très limité et ne mérite guère ce titre. J'avais aussi tiqué sur l'allégation tout subjective qu'il « propose une auto-complétion relativement bien faite. »
À mon sens, un vrai IDE (il n'y a pas de définition officielle) est formé d'un éditeur de code, d'une intégration des outils annexes (compilation, déboggeur, tests automatiques, etc), et de complétions et navigations intelligentes (et affichage ciblé de documentation). Pour un langage objet, si je complète la propriété d'une variable, l'IDE doit utiliser sa classe pour me faire une proposition adéquate, et afficher aisément la doc associée à cette propriété. Eclipse et Netbeans sont des IDE libres qui peuvent très bien faire ça, non seulement pour du Java, mais même pour des langages faiblement typés comme PHP.
Malheureusement, les remèdes à base de ctags sont des pis-allers très limités. La complétion est "stupide". Naviguer vers la définition d'une méthode est souvent pénible, puisque chaque méthode homonyme (par exemple surchargée) est listée comme source possible. Et bien sûr, on n'a ni complétion ni documentation pour les fonctions du langage, sans parler des problèmes de désynchronisation de l'indexation.
Et non, Emacs ne sait pas naviguer intelligemment dans le code. En dehors d'Exuberant ctags, il y a CEDET (parser syntaxique en lisp) mais le projet est moribond et à peine utilisable, même si on se limite à du C. Le seul langage de programmation pour lequel j'ai vu une navigation et une complétion au point dans Vim/Emacs, c'est Haskell, grâce au fonctionnement client-serveur de Ghcmod qui fournit à la volée les informations à l'éditeur de code.
[^] # Re: Manque un truc
Posté par flan (site web personnel) . Évalué à 9.
Je suis tout à fait d'accord.
Je rajouterais qu'un IDE correct doit s'adapter à la version du langage utilisé. Par exemple, avec PyCharm, je peux préciser que je veux un code compatible Python 2.7 et Python 3.3/3.4, et il me mettra des avertissements quand j'utilise des fonctions ou des constructions qui sont invalides avec l'une de ces versions.
[^] # Re: Manque un truc
Posté par François (site web personnel) . Évalué à 2.
CEDET n'est pas mort mais il y a presque exclusivement qu'un développeur et le projet avance très doucement. De plus C/C++ est largement favorisé et les fonctionnalités sont, dans ce cas de figure, sont tout à fait sophistiquées.
[^] # Re: Manque un truc
Posté par Yuul B. Alwright . Évalué à 3.
Ɛmacs permet ce genre de complétion en Python avec Jedi.
Et il me semble qu'il y a une extension pour le C/C++ qui utilise Clang.
CEDET c'est plus qu'un parser syntaxique. Mais ils devraient le séparer de CEDET et le rendre plus modulaire, extensible à de nouveaux langages par les modes majeurs et multi-paradigme.
En attendant, on utilise les extensions comme Jedi et ça fonctionne bien.
[^] # Re: Manque un truc
Posté par NilugeKiWi . Évalué à 2.
CEDET n'a pas d'intégration d'outils modernes comme CMake, et est bien trop lent pour de gros projets (>10Mloc)…
Un analyseur de code prometteur utilisable dans emacs: RTags, basé sur clang, on y gagne en robustesse d'analyse, architecture client/server qui permet d'utiliser plusieurs cœurs sans impacter emacs. Il avait des soucis de consommation mémoire il y a plusieurs années, ça a l'air d'avoir été corrigé depuis.
# Atom, atom et atom => la soupe aux tags
Posté par Seazor . Évalué à 3.
C'est pourtant ce que fait linuxfr.org avec ses tags : entre cet éditeur, la syndication et le processeur intel, un volontaire pour faire le tri chez les modérateurs ?
[^] # Re: Atom, atom et atom => la soupe aux tags
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Ils s'appellent tous Atom, il n'y a pas de raison que le tag Atom ne soit pas utilisé pour les désigner. Maintenant ils pourraient aussi être tagués avec un autre tag différenciant (et il n'y a pas besoin d'être modérateur pour ça).
[^] # Re: Atom, atom et atom => la soupe aux tags
Posté par Thomas Douillard . Évalué à 3.
Toujours personne pour implémenter le tagging Wikidata ? /o\
[^] # Re: Atom, atom et atom => la soupe aux tags
Posté par Tonton Th (Mastodon) . Évalué à 5.
Sans oublier cette machine méconnue du siècle dernier : https://en.wikipedia.org/wiki/Acorn_Atom. Ah, que de souvenirs…
# Comment dire…
Posté par Jiehong (site web personnel) . Évalué à 10. Dernière modification le 17 août 2015 à 13:36.
Plusieurs choses :
Sinon, je pense qu'historiquement, c'est une réaction à Sublime Text (non libre). Adobe a sorti Brackets, qui rejoint un peu cette idée (aussi sous MIT).
Je trouve que le principal avantage de ces éditeurs, c'est qu'ils font bouger les anciens. Par exemple, Emacs s'est vu doté d'un gestionnaire de paquets (ça manque de peaufinage, mais bon), et du travail sur des FFI sont en cours, histoire de pouvoir, peut-être un jour, développer des extensions en autre chose qu'Emacs lisp.
S'il y a bien une chose que des projets comme Vim ou Emacs devraient s'approprier c'est bien l'identité visuelle et la présentation (genre les logos ou les pages d'accueil de vim et sa perceuse d'il y a 15 ans, ou celle d'Emacs avec une capture d'écran pas super )
Mais je ne suis pas concepteur de sites webs…
[^] # Re: Comment dire…
Posté par Enj0lras . Évalué à 10.
Ça bouge chez vim aussi sous forme de fork avec neovim même si pour l'instant c'est du travail de fond peu visible pour l'utilisateur
# un peu fort
Posté par Stibb . Évalué à 10.
je trouve cela vraiment fort de café de citer 'vim' mais d'oublier SublimeText comme source inspiration, tellement Atom est un repompé de Sublime!
[^] # Re: un peu fort
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 4.
Désolé, je ne connais pas tous les éditeurs de code dans la nature, encore moins les propriétaires. C'est justement pour ça que les commentaires sont là. Il aurait été plus constructif de dire en quoi SublimeText est une source d'inspiration.
[^] # Re: un peu fort
Posté par Philippe F (site web personnel) . Évalué à 8.
Alors, je me lance, vu que j'ai renoncé à Vim pour SublimeText…
SublimeText, c'est:
un éditeur qui est beau graphiquement quand on le lance (vim et emacs puent encore le vt100 à plein nez !)
des tab bien évidemment
des vues que tu peux organiser selon des layout, genre ficher en haut de l'écran et fichier en bas, ou fichier ds une colonne, fichier ds la 2e colonne, fichier ds la 3e colonne. Sous vim, il faut faire des split à tour de bras pour faire ça il me semble.
une configuration assez poussée pour tout un tas d'options, qu'on peut facilement éditer en json
bien sur, une coloration syntaxique pour tous les langages de la terre
un gestionnaire de package hyper facile à utiliser ( https://packagecontrol.io/ )
des package pour étendre les fonctionnalités dans tous les sens (3150 package à l'heure où j'écris cette dépèche)
un mode vim qui tient la route fourni de base
le support de curseur multiples pour faire des changements multiples dans un fichier (cf la démo sur http://www.sublimetext.com/ , c'est plus simple à utiliser qu'une macro vim et surtout on voit le résultat en direct)
dispo sur linux, mac, windows
closed-source
utilisable gratuitement indéfiniment, il te propose juste d'acheter la licence de temps en temps quand tu sauves (ce que j'ai fait, l'auteur le mérite)
de la complétion, un peu bof de base, mais étendable à merci. On arrive à compléter du C++ et du Python de façon correcte
rapide
écrit en Python et corollaire, étendable en Python, soit un langage plutôt facile à appréhender
agréable à utiliser
un mode compilation adapté à tous types de compilateur (l'équivalent de :make dans vim, sauf que là, ça marche de base pour des tests unitaires Python, des erreurs en Lua, du Gcc et j'en passe)
détection automatique de l'indentation, de l'encodage du fichier, du type de newline du fichier (pour l'indentation, vim ne l'a toujours pas mais vous pouvez utiliser mon "plugin")
des raccourcis pour faire des opérations simples mais pratiques sur du texte. Par exemple, je me sers souvent de la fonctionnalité pour dupliquer une ligne (oui, c'est plus rapide que yyp), monter ou descendre des lignes
du code folding
Le curseur multiple, on pourrait dire que c'est la killer feature. Mais même sans ça, c'est un éditeur très très complet, facile à étendre, qui reste pourtant accessible et rapide.
Atom ressemble clairement à une tentative de faire la même chose par un développeur qui maitrise la stack web et qui veut un éditeur open-source. Autant je comprends le 2e point, autant le 1er est un peu bizarre. Cela dit, j'ai vu un debuggeur python construit sur une stack web qui avait l'air de tenir autrement mieux la route que les pauvre GUI qu'on se tape en Python alors pourquoi pas…
En tout cas, vim a du mouron à se faire, entre les SublimeText, Kate, NeoVim et Vile, on trouve des clone qui tiennent la route et qui convertissent des aficionados !
A ce propose, qq'un a déjà utilisé SublimeText 3 et est-ce que ça vaut le coup par rapport au 2 qui marche très très bien ?
[^] # Re: un peu fort
Posté par barmic . Évalué à 6.
Il est vraiment très rapide. Ouvrir un fichier de quelques centaines de méga se fait bien (l'ouverture n'est pas instantanée mais une fois ouvert plus aucun problème).
Tu as aussi oublié la minimap qui est sympa.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: un peu fort
Posté par Porkepix . Évalué à 6.
Juste une correction : les API exposées pour étendre l'éditeur sont en Python.
Mais à ma connaissance, il est plutôt écrit en C(++), pas en Python. J'adore Python, mais je doute qu'il soit capable de ces performances, et c'est ce qui fait la grosse différence entre Atom et Sublime Text. Des performances même pas comparables vu le gouffre entre les deux.
Par ailleurs, j'avais testé il y a quelques temps pour l'empreinte mémoire : une centaine de Mo pour Sublime Text + quelques plugins (peu) et quelques dizaines de fichiers ouverts dans plus d'une dizaine de fenêtre.
~300Mo pour Atom…sans aucun plugins…et aucun fichier ouvert. Complètement nu.
Je trouve ça…choquant. Mais facilement expliqué par la base Chromium sur laquelle il tourne.
(Test pas effectué sous 'nux, malheureusement, faudrait que je reteste dessus).
[^] # Re: un peu fort
Posté par whity . Évalué à 1.
C’est à dire, correcte ?
Est-ce que c’est au niveau d’un QtCreator ou d’un Visual C++ (aka vraie complétion contextuelle) ?
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: un peu fort
Posté par Stibb . Évalué à 1.
non, ce n'est pas au niveau de visual studio ou qtcreator. Apres on doit faire un choix…
[^] # Re: un peu fort
Posté par Joalland . Évalué à 2.
J'ai cru comprendre que le développement de SublimeText n'avait pas bougé depuis plusieurs années, non ?
Pour ma part, c'est le seul logiciel propriétaire dont je ne peux me passer. La sélection multiple est une tuerie et il est vraiment vraiment rapide, comparé à Atom.
[^] # Re: un peu fort
Posté par barmic . Évalué à 4.
La dernière version est sortie en mars.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: un peu fort
Posté par Stibb . Évalué à 2.
Le gars qui fait l'éditeur sort quelques versions par an. Il ne s'occupe que du moteur, tous les autres feature, autocomplétion, etc, ont l'effort reporté dans la communauté.
[^] # Re: un peu fort
Posté par Jiehong (site web personnel) . Évalué à 5.
Cette fonction a d'ailleurs été si intéressante qu'elle est sous Emacs depuis pas mal de temps maintenant.
Vim possède également cette fonction !
[^] # Re: un peu fort
Posté par Stibb . Évalué à 4.
Je suis sous le 3 depuis un moment. Au vu de la qualité et de la vitesse d’édition, j'ai déboursé les 70 € de la license avec grand plaisir.
Atom commence à lui faire de l'ombre, et il est libre, ce qui lui manque encore c'est la rapidité. Sublime est hyper rapide. Vraiment.
Je pense pas qu'il joue dans la même catégorie que vim. Certains sont plus confortable avec sublime, d'autres avec vim.
Par contre, sublime ou atom, le coté hyper modulaire pose probleme: un package qui est génial un jour peut arrêté d'être maintenu, concurencé par un autre (Anaconda vs SublimePythonIDE pour la completion Python), il y a donc beaucoup de veille, de test à faire.
Le secret c'est de versionner son dossier config (dropbox, github,…)
# Gouffre à ressources
Posté par romu . Évalué à 9.
Bonjour,
J'ai testé très vite fait Atom car je voulais essayer Nuclide, l'IDE pour le web dont Facebook est à l'origine. Et c'est juste un gouffre à ressources ce truc. Là où Brackets (que j'adore) occupe 160 Mo sur mon disque (Fedora pour ma part), j'ai vu que Atom + Nuclide prenait plus de 1.2 Go !!! Et là, j'ai arrêté le téléchargement des modules, et viré le bouzin.
[^] # Re: Gouffre à ressources
Posté par NicolasG . Évalué à 2.
Pour envoyer les hommes sur la Lune, y’aura toujours nos caltos de dispo. Ça va être rigolo le jour où les informaticiens seront contraints de réapprendre à faire attention aux ressources (le b.a.-ba de la prog. quoi…).
[^] # Re: Gouffre à ressources
Posté par romu . Évalué à 2.
C'est clair. En plus, j'ai toujours l'impression de passer pour le chi… de service quand je dis autour de moi de ne pas utiliser Chrome qui bouffe la RAM et la batterie, et autres trucs du même genre.
[^] # Re: Gouffre à ressources
Posté par barmic . Évalué à 10.
Si tu dis aux gens quoi faire de leur machine alors oui c'est pas qu'une impression.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gouffre à ressources
Posté par G.bleu (site web personnel) . Évalué à 6.
C'est sûr qu'on va pas dire à Barret Michel quoi faire de sa RAM !
[^] # Re: Gouffre à ressources
Posté par Zenitram (site web personnel) . Évalué à 0.
Ca dépend de comment c'est dit.
Si une personne se plaint que ça machine ne tient pas assez longtemps sur batterie mais choisit des logiciels sans se soucier de l'impact en énergie, et ne change rien quand tu lui dis que c'est son choix qui fait que ça ne tient pas longtemps le chieur est celui qui se plaint (car il se plaint que pour le plaisir, sans avoir la moindre envie de savoir d'où ça vient ni de corriger)
PS : je ne sais pas si FF fait tenir la batterie plus longtemps, je me base sur l'idée émise dans le commentaire précédent que Chrome serait plus gourmant en énérgie que FF. Quelqu'un sait-il si cette assertion est exacte?
[^] # Re: Gouffre à ressources
Posté par karteum59 . Évalué à 5. Dernière modification le 18 août 2015 à 11:25.
N.B. le commentaire précédent ne dit nulle part que son alternative à Chrome était FF. Je pense que s'il préconise Lynx (ce qui est compatible avec "passer pour le ch… de service"), il est bien possible que ce soit plus économe en énergie… :)
[^] # Re: Gouffre à ressources
Posté par Zenitram (site web personnel) . Évalué à -1.
Exact, je corrige : par rapport à une offre qui a les mêmes fonctionnalités mais qui consomme moins.
La, ce serait clairement un chieur de service car préconiserait quelque chose qui n'a rien à voir.
J'ose espérer qu'il préconise quelque chose d'autre!
D'ailleurs, qu'est-ce qu'il préconise donc?
[^] # Re: Gouffre à ressources
Posté par romu . Évalué à 2.
Perso plutôt FF. Je commence à avoir une allergie prononcée aux produits Google qui visent, quoi qu'on en dise, à monnayer nos vies numériques.
Chrome mange aussi plus de batterie : http://www.forbes.com/sites/ianmorris/2014/07/14/googles-chrome-web-browser-is-killing-your-laptop-battery/
… et plus de RAM (ok, ça date un peu, j'en conviens) : http://blog.en.uptodown.com/browser-comparison-chrome-firefox-explorer-opera/
[^] # Re: Gouffre à ressources
Posté par Zenitram (site web personnel) . Évalué à -2.
Pas très logique comme argument, vu tout ce que FF interroge sur les serveurs de Google…
[^] # Re: Gouffre à ressources
Posté par karteum59 . Évalué à 1.
Mouais, si tu parles du moteur de recherche par défaut, ça se change en 3 clics…
[^] # Re: Gouffre à ressources
Posté par karteum59 . Évalué à 2. Dernière modification le 18 août 2015 à 23:06.
Si tu es prêt à faire quelques entorses au libre, tu peux utiliser Opera (même si j'avoue ne pas comprendre quel est leur business-model en 2015, et depuis l'abandon de leur moteur maison…). OK ce n'est pas libre mais j'ai toujours trouvé (à l'époque où je l'utilisais) que c'était un excellent browser et que les devs faisaient du très bon boulot.
Sinon, il existe des alternatives libres. En particulier, j'aime bien qupzilla (je ne l'utilise pas quotidiennement car je le trouve encore trop instable, et/ou pas si léger que ça à cause de ses memory leaks, mais je reteste régulièrement et c'est vraiment prometteur…)
[^] # Re: Gouffre à ressources
Posté par NicolasG . Évalué à 2.
Links au moins dispose d’un mode graphique ; je l’utilise parfois pour de la grosse lecture. W3m lui affiche les images en mode texte. Ils explosent effectivement la concurrence en terme de rapidité et de consommation. Dans une moindre mesure je préfère leur “confort”.
# Mille feuilles ?
Posté par barmic . Évalué à 10. Dernière modification le 17 août 2015 à 14:20.
Un mille feuille comme ça, ça ne me paraît pas très digeste ;-)
Pourquoi pas :
Oh ! Un oiseau !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Re:
Posté par Wendigo . Évalué à 3.
Pour ma part, j'utilise toujours SublimeText 3, les plus puristes m'en voudront certainement :p
L’avantage d'Atom c'est déjà qu'il est open-source/libre et basé sur les technos du web, donc facilement hackable ( modifiable ), … mais c'est encore consommateur de ressources.
J'ai peu le tester lors de sa sortie initiale en 0.1, où l'on tapait plus vite que ça n'écrivait, ça prouve bien qu'il y a eu beaucoup de travail entre-temps, mais c'est encore pas mal lent et c'est assez déconcertant je dois dire.
# Meilleur éditeur depuis.. longtemps
Posté par Jeanbon . Évalué à 2.
Le point fort pour moi est la facilité d'installation des extensions comparé à vim ou emacs, qui peuvent vite devenir pénible voir impossible sous windows, il y'en a beaucoup et sont très utiles( par exemple minimap, beautify, linter, color picker etc )
Une fois qu'on connait les commandes cet éditeur est le top !
Le seul défault que je lui trouve est sa lenteur, mais le reste que propose l'application outrepasse ce point et en fait mon éditeur favori.
[^] # Re: Meilleur éditeur depuis.. longtemps
Posté par pouleta . Évalué à -4.
c'est une blague ?
pour installer des plugins sous vim c'est une ligne dans le fichier de conf, et ensuite un :PluginInstall,
sous emacs c'est C-x package-install.
c'est de la mauvaise foi, un manque de connaissances ou de la bêtise ?
[^] # Re: Meilleur éditeur depuis.. longtemps
Posté par Jeanbon . Évalué à 1. Dernière modification le 18 août 2015 à 13:36.
Ah ? Essaye d'installer youcompleteme rien qu'avec une petite ligne dans le fichier de configuration et un plugininstall sous windows.
[^] # Re: Meilleur éditeur depuis.. longtemps
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Et la politesse, ça s'installe facilement aussi sous Vim ?
[^] # Re: Meilleur éditeur depuis.. longtemps
Posté par Moonz . Évalué à 2.
:help :PluginInstallE149: Sorry, no help for :PluginInstallEt Google n’a pas l’air d’en savoir plus sur cette commande.
[^] # Re: Meilleur éditeur depuis.. longtemps
Posté par Jeanbon . Évalué à 1.
C'est parce qu'il faut installer vundle avant ( https://github.com/VundleVim/Vundle.vim )
# Lent ?
Posté par mikael.vallerie . Évalué à 2.
Je comprends mal les commentaires critiquant la lenteur présumée d'Atom…je m'en sers tous les jours (je ne développe plus qu'avec ça en fait) sur un i3, et j'ai pas tous ces problèmes =/. Je trouve que ça marche même très bien.
Perso' j'arrive tout droit des IDE "old-gen" type Eclipse, Netbeans, Idea, et tous les autres, ce qui peut expliquer en partie mon ressenti. C'est sûr que ça reste plus lent que Vi(m) ou Emacs, mais dans mon utilisation au quotidien, cette "lenteur" n'a jamais été au point de pénaliser ma productivité.
[^] # Re: Lent ?
Posté par barmic . Évalué à 9.
Alors je viens d'essayer. Sur ma « petite conf » (16Gio, un Core i5 4300U et un SSD) il rame gravement. Toutes les actions ne sont pas lentes, mais quand j'écris, il répond qu'après un certain temps (je tape, au bout d'1s il affiche d'un coup tout ce que j'ai écris et continue d'afficher en temps réelle ce que je continue pendant 1/2s puis rebloque pendant 1/2s, etc).
Il est très loin de sublime text.
netbeans est lent, eclipse j'ai pas essayé, mais intellij est plutôt rapide. Je le fais ramer sur de gros fichiers (moins qu'atom, mais plus que sublime text et bien plus que vim), mais sinon je n'ai jamais rencontré de problème particulier.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Lent ?
Posté par Guillaume Denry (site web personnel) . Évalué à 6.
J'ai une conf beaucoup plus modeste que la tienne (laptop dell latitude E6410), avec pas mal de packages (linters, git, etc) et ce que j'écris apparaît instantanément à l'écran sans jamais entraver ma frappe.
Je veux pas dire que cet éditeur est parfait mais il me semble que tu as un soucis quelque part.
[^] # Re: Lent ?
Posté par mikael.vallerie . Évalué à 3. Dernière modification le 18 août 2015 à 13:36.
Tu as un gros souci quelque part à mon avis :). Non sérieusement, c'est vraiment pas normal. Idea plus rapide qu'Atom…
Ceci étant c'est un problème récurrent pour plusieurs users d'Atom selon les issues github. Quel système ? Si *Linux, quel kernel ?
Le seul truc que l'éditeur met plusieurs secondes à effectuer chez moi, c'est son lancement.
[^] # Re: Lent ?
Posté par barmic . Évalué à 7. Dernière modification le 18 août 2015 à 14:23.
Une debian stable avec un noyau 4.0 installé par mes soins, un système de fichier btrfs et quelques trucs de lancés qui sont consommateurs en mémoire (cassandra, firefox, thunderbird et intellij) mais il lui reste une bonne moitié de la mémoire (soit 8Gio), j'utilise awesome comme gestionnaire de fenêtre.
Je veux bien que mon expérience surprenne et ne soit pas une généralité, mais SublimText passe sans problème (évidement mon gvim et emacs tournent sans le moindre problème), Chrome passe sans problème, je n'ai pas de choses si particulière que ça.
Le fait de n'avoir aucun problème par ailleurs me fait dire que c'est sa stack logiciel qui pose problème sur ma machine. Peut-être qu'il y a une bizarrerie avec node, sinon je ne vois pas. Là où c'est dommage, c'est que je m'en fou. Des éditeurs de texte j'en connais pleins qui me satisfont pleinement (j'use et j'abuse de gvim, sublim et intellij), je n'ai pas grand intérêt à prendre du temps pour tenter d'améliorer atom (d'autres le feront).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Lent ?
Posté par mosfet . Évalué à 1.
Bon je suis sous Windows10 (pas taper) et je lis régulièrement linuxfr (je ne sais plus trop bien pourquoi mais j'aime bien même si je passe beaucoup moins de temps sous linux. De plus je trouve que les débats ici sont plutôt intéressants).
Bref tout ça pour dire que je viens de tester sur cet os et ça n'est pas lent du tout sauf si je tape comme un singe sur le clavier. Prochaine étape tester sur un linux (virtualisé car je n'ai plus de double boot et que j'ai la flemme de booter sur une clé USB).
En terme d'occupation mémoire j'ai ca:
atom 45492
atom 9980
atom 50672
atom 32912
atom 6208
ce qui fait en gros 145Mo ce qui n'est pas énorme
[^] # Re: Lent ?
Posté par zurvan . Évalué à 1. Dernière modification le 20 août 2015 à 18:48.
idem, j'ai lancé atom sur mon i5 (8 go de ram), c'est assez lent à démarrer au début (13 secondes), mais ensuite ça ne semble pas particulièrement lent, quand je tape ça affiche immédiatement (et même lorsque je tape « comme un singe »).
Je vais continuer à le tester, on verra bien. Le système de greffon semble pas mal.
Par contre ce que j'apprécie dans Vim c'est de pouvoir l'utiliser de la même façon (même raccourcis) que je suis en local ou à distance (ou dans une console), avec atom ça ne semble pas possible (atom-remote passe par des transferts, si le réseau coupe entre temps… bref)
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Lent ?
Posté par mikael.vallerie . Évalué à 1.
Pour moi, c'est effectivement une bizarrerie liée à la stack. A la limite tu peux essayer d'autres applications basées sur Electron et voir ce que ça donne.
[^] # Re: Lent ?
Posté par barmic . Évalué à 3.
Il y a un article très intéressant récent sur idea :
http://blog.jetbrains.com/idea/2015/08/experimental-zero-latency-typing-in-intellij-idea-15-eap/
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Atom : une alternative complémentaire
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0.
Ce n'est certes pas un IDE comme Eclipse ou Netbeans (Pas de débogueur, d'autocompilation, de complétion par analyse du code…), mais il possède de sérieux atout et un gros potentiel.
J'apprécie l'extension "remote-atom". Elle permet d'ouvrir en local un fichier en une commande sur un serveur distant. Alors quand la connexion est lente et bagotte, j'apprécie d'ouvrir mon fichier en local sans avoir a le copier outre le côté clickodrome de la souris.
J'utilise vim pour des modification distante rapide, Netbeans pour le dévellopement C/C++ (pour son débogeur et sa génération de makefile/compilation), Gedit pour la visualisation d'un fichier basique et la prise de note. Atom se positionne parfaitement entre Netbeans (très lourd) et Vim/Gedit (trop minimaliste).
L'outils polyvalent, léger… parfait n'existe pas. Alors quand on a une grande utilisation (Professionnel ou passioné) on se doit d'avoir plusieurs outils, chacun adapté a l'utilisation. C'est vrai pour tout métier.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Très bon éditeur
Posté par Emeric . Évalué à 1.
Voilà plus d'un mois que je n'utilise plus qu'Atom pour développer en Meteor.Js.
Il est très bien et pas de lenteur même sur un vieux Core 2 Duo 2.4 Ghz.
Je trouve sa philosophie de fonctionnement très naturelle.
# D'autres éditeurs dans la lignée de sublime text
Posté par G.bleu (site web personnel) . Évalué à 10.
On a beau dire, je pense que sublime text a révolutionné l'éditeur de text (j'étais Emacs avant, rien que les multicurseurs sont un tel bonheur qu'ils justifient à eux seuls le changement)
De là, son (seul ?) défaut étant de ne pas être open-source, il est normal qu'une foule d'enfants illégitimes soient nés de sa hanche :
Light Table
Le développeur est un ancien de l'équipe Visual Studio, il a lancé en 2012 un kickstarter qui a atteint 316k$ ! (ha ! la mode des kickstarter faramineux !)
Après une telle réussite l'équipe s'est agrandie (je crois qu'ils sont 3 à plein temps) et le projet avance.
Comme pour Atom, l'idée est d'utiliser webkit/v8 pour pouvoir gérer l'interface comme une page web
Au niveau du langage, c'est du clojure script (clojure, un genre de lisp de ce que j'en ai compris, compilé en javascript).
Zed
Le cousin fauché (en terme d'argent hein, pas de talent !) de Atom et Light Table : webkit/v8 (mais cette fois ci le dev à décidé de partir sur du pur javascript)
Il s'agit du travaille commencé en 2013 d'une seule personne (le mec a pris 6mois~1an sabbatique pour travailler à temps plein sur le projet)
Perso j'ai bien aimé l'idée d'utiliser des buffers (comme sur emacs, on tappe le nom du fichier auquel on veut accéder) plutôt que d'ouvrir des fichiers dans des onglets (on se retrouve toujours avec 50 onglets dont les 3/4 inutiles qui rendent la navigation désagréable et oblige à tout fermer régulièrement pour faire le nettoyage)
L'autre idée sympa est de pouvoir l'installer comme extension Chrome (permettant de synchroniser sa configuration de manière instantanée et automatique)
Lime
On change radicalement de techno pour un éditeur
godé en cocodé en GoEn réalité l'éditeur est divisé en un backend et plusieurs frontends : qml (le plus avancé), html et mode console
D'après l'équipe, le projet est encore au stade de béta. Ça se voit dans la procédure d'installation très "unix style" (installation de ouatmille dépendances, compilation etc.) au lieu d'une bête archive pré-compilée.
Brackets
L'éditeur de Adobe, toujours webkit/v8 + javascript. Je le cite pour la forme et ne me suis pas attardé sur lui.
Conclusion
À titre personnel, j'ai testé les deux premiers, mais suis vite retourné à SublimeText, notamment à cause des habitudes : les raccourcis ne sont pas les mêmes (surtout avec zed qui me rappel quand je dois éditer un fichier avec vim…), l'absence de minimap (une autre killer-feature de SublimeText)
Par contre je suis intéressé à vos retours (et si vous connaissez d'autres éditeurs), en particulier de Bracket que je n'ai pas encore eu le temps d'essayer.
Et pour finir un article (qui date d'un an déjà) d'un comparatif de tout ce beau monde
[^] # Re: D'autres éditeurs dans la lignée de sublime text
Posté par mikael.vallerie . Évalué à 1.
Je suis bien d'accord avec toi sur Sublime. Il a lancé la "mode" de l'éditeur léger, graphique (par opposition à console), et avec plein de commandes au clavier ! Mais je n'ai jamais réellement compris pourquoi Sublime tentait de relancer une autre mode un peu moins "clean" : celle du shareware.
LightTable je m'en suis servi pendant un temps. Jusqu'à il y a quelques mois j'avais la désagréable impression que le projet était en train de mourir…visiblement ils partent plutôt sur un gros refactoring à base d'Atom-shell aka Electron à la place de Node webkit.
Brackets, les features sont assez poussées en ce qui concerne l'intégration d'un design en HTML / CSS (d'ailleurs l'éditeur à été pensé pour ça à la base). Pour le reste, je le trouve en dessous d'Atom, mais je ne m'en suis pas assez servi sur la durée pour donner un avis pleinement objectif.
Zed et Lime, jamais utilisés (tout au plus lancés et testés pendant cinq minutes). Mais j'ai entendu beaucoup de bien sur Zed.
[^] # Re: D'autres éditeurs dans la lignée de sublime text
Posté par \o/ . Évalué à 2.
Merci pour la liste!
Je pense qu'on peut y ajouter Visual Studio Code de Microsoft qui est peut se situer dans cette catégorie d'après ce que j'ai pu en voir de loin. C'est aussi je pense le premier logiciel Microsoft Linux en dehors des rachats et en dehors de contributions noyaux nécessaires pour tourner sur hyper-v.
[^] # Re: D'autres éditeurs dans la lignée de sublime text
Posté par SlowBrain (site web personnel) . Évalué à 1.
Je me demandais si quelqu'un allais en parler.
Si mes souvenirs sont bon, il as comme base une vielle version de Atom.
Et même si proprio et de Microsoft, c'est un éditeur que j'apprécie. Même si ce journal me donne envie d'en essayer d'autres (Plus libre)
# Incompréhension
Posté par Muchacho . Évalué à 0. Dernière modification le 24 août 2015 à 20:46.
Autant l'écriture d'extension en Javascript est un grand bol d'air frais (c'est quand même plus human/dev-friendly que le Lisp) à la limite du nécessaire.
Autant j'avoue ne pas comprendre pourquoi il n'y a pas d'outils similaire écrit avec un langage compilé (pour des raisons de performance exécution/mémoire).
Quand je vois ma consommation CPU/RAM avec emacs, j'ai le fâcheux réflexe de sourire avec une grande satisfaction.
[^] # Re: Incompréhension
Posté par Porkepix . Évalué à 3.
Il existe, même si malheureusement propriétaire : Sublime Text.
Il ne souffre d'aucun problème de performances, et est extensible via Python (ce qui est, pour moi, mieux que Javascript :) )
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.