https://insights.stackoverflow.com/survey/2018/#development-environments-and-tools
Most Popular Development Environments
[…]
Vim 25.8%
[…]
Emacs 4.1%
PS: je prends un peu d'avance pour vendredi
https://insights.stackoverflow.com/survey/2018/#development-environments-and-tools
Most Popular Development Environments
[…]
Vim 25.8%
[…]
Emacs 4.1%
PS: je prends un peu d'avance pour vendredi
# Comment quitter Vim ?
Posté par Guillawme (site web personnel, Mastodon) . Évalué à 10.
Ce résultat doit venir du fait que tous ces utilisateurs sont coincés et n’arrivent pas à quitter Vim…
[^] # Re: Comment quitter Vim ?
Posté par saltimbanque (site web personnel) . Évalué à 9.
appuyer simplement sur la touche d'échappement, puis sur un signe de ponctuation arbitraire permettant de passer en mode commande, puis sur une lettre q car vous savez que quit commence par q parce que ça vous l'avez appris par coeur, ensuite éventuellement un point d'exclamation quand même, et ensutie entrer. Parce que cliquer sur un bouton pour fermer la fenêtre serait beaucoup trop long.
[^] # Re: Comment quitter Vim ?
Posté par kna . Évalué à 10.
C'est quand même pas évident pour tout le monde : https://stackoverflow.blog/2017/05/23/stack-overflow-helping-one-million-developers-exit-vim/
[^] # Re: Comment quitter Vim ?
Posté par liberforce (site web personnel) . Évalué à 2.
J'ai pertinenté :)
[^] # Re: Comment quitter Vim ?
Posté par David Marec . Évalué à 9.
Ctrl-Z, puis
pkill vim
[^] # Re: Comment quitter Vim ?
Posté par Mimoza . Évalué à 5.
En image :
http://www.commitstrip.com/fr/2017/05/29/trapped/
[^] # Re: Comment quitter Vim ?
Posté par Marotte ⛧ . Évalué à 2.
BD bof bof (selon mes goûts de merde bien sûr) mais commentaire pertinent.
# VSC
Posté par Xinfe (site web personnel) . Évalué à 7.
Et aussi :
[^] # Re: VSC
Posté par Ririsoft . Évalué à 3.
L'explosion de VSC est impressionnante.
On la retrouve dans le survey de Golang ou VSCode devient l'éditeur le plus populaire pour ce langage à 27%.
[^] # Re: VSC
Posté par Christie Poutrelle (site web personnel) . Évalué à 2.
J'ai toujours trouvé ça super étonnant, au vu des problèmes de performance que j'ai eu (sur plusieurs postes, Windows comme Linux) sur des gros projets: des freeze pouvant aller jusqu'à freezer toute la machine (sur Windows surtout) - et le manque de fonctionnalités sur pas mal de langages (à cause du manque de plugins corrects souvent).
[^] # Re: VSC
Posté par ckiller . Évalué à 5.
ca freeze tellement, qu'on dirait eclipse :)
[^] # Re: VSC
Posté par Christie Poutrelle (site web personnel) . Évalué à 5.
Ah c'est malin ça ! Au moins Eclipse il sait faire des trucs :)
[^] # Re: VSC
Posté par pizaninja . Évalué à 1.
Tu vache ! Quand même pas !
[^] # Re: VSC
Posté par Framasky (site web personnel) . Évalué à 5. Dernière modification le 13 mars 2018 à 15:54.
Pas chez les adminSys/Devops ^^
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: VSC
Posté par ʭ ☯ . Évalué à 5.
Oui. Et 50% des réponses sont entre 25 et 34 ans, ils n'ont pas encore appris à utiliser Vim ;-)
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: VSC
Posté par xcomcmdr . Évalué à 0. Dernière modification le 13 mars 2018 à 17:27.
J'ai appris à utiliser Vim, et puis je me suis souvenu de toutes les raisons pour lesquelles j'utilise Visual Studio.
En vrac :
- Complétion de code qui a du sens et qui est pertinente, out of the box ™
- Coloration syntaxique de plusieurs langages (Python, C, C++, C#, …) qui est juste lisible, out of the box ™
- Tout intégré (éditeur, compilateur, signalement des erreurs, débogueur, gestionnaire de paquets NuGet, gestionnaire de versions, gestion des tests, …). Plus besoin de changer de contexte/outil/logique tout le temps. Plus de perte de temps.
Oui j'aurais pu me faire mon "IDE Vim", mais ce qui m'intéresse, c'est de bosser, pas de travailler sur mes outils.
Et vu que je suis moderne et que j'utilise des SSD, le temps de chargement est sans importance. :p
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: VSC
Posté par Yuul B. Alwright . Évalué à 1.
Je ne suis pas fan des outils que réfléchissent à ma place.
Je préfère construire en fonction de mes besoins et préférences.
[^] # Re: VSC
Posté par xcomcmdr . Évalué à -3.
Tu n'aimes pas automatiser, tu n'aimes pas l'informatique.
C'est un choix.
Je préfère écrire ce qui m'intéresse plutôt que de réinventer la roue (carrée)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: VSC
Posté par Yuul B. Alwright . Évalué à 0.
Je n'ai pas dit que je n'aime pas automatiser.
J'ai dit que je ne suis pas fan des outils qui réfléchissent à ma place.
[^] # Re: VSC
Posté par xcomcmdr . Évalué à -1.
Je savais pas que Visual Studio codait à ma place !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: VSC
Posté par Yuul B. Alwright . Évalué à -2.
Le niveau des commentaires de LinuxFR aurait-il rattrapé ceux de PCInpact?
[^] # Re: VSC
Posté par totof2000 . Évalué à 4.
bah moi non plus j'aime pas les outils qui réfléchissent à ma place. Et dans le genre, un qui me gonfle sérieusement c'est MS Word.
Exemple tout bête : il y a peu, j'ai essayé de mettre un cadre autour d'une zone de texte composée de paragraphes et de liste numérotées : impossible : cet imbécile s'est obstiné à mettre un cadre différent autour de chaque paragraphe. Et ça c'est pas la seule chose qu'il fait : avec ce genre d'outil, je passe de plus en plus de temps à défaire ce qu'il a mal fait à ma place. C'est pareil pour les guillemets/quotes/doubles quote. Il ne fait jamais ce que je veux qu'il fasse, faut se battre avec pour obtenir ce que l'on veut.
Un autre exemple : l'autocompletion avec les parenthèses et les quotes dans certains éditeurs de texte: Plus d'une fois sur deux je dois supprimer la parenthèse ou la double quote qu'il m'a mis en trop (dernièrement ça m'est arrivé avec geany sous freeBSD).
[^] # Re: VSC
Posté par Michaël (site web personnel) . Évalué à 3.
En même temps, est-ce que tu connais un seul éditeur de texte “riche” qui utilise les “sticky tags” (le style du dernier mot colle à la suite) et n'est pas cassé au point que c'est triste à pleurer? J'ai un challenge ouvert à ce sujet au boulot ;)
[^] # Re: VSC
Posté par Tit . Évalué à 4.
pas compris, tu peux expliciter ? "sticky tag" et "cassé" (c'est quoi un éditeur de texte riche cassé (ou pas cassé)) par exemple.
[^] # Re: VSC
Posté par Michaël (site web personnel) . Évalué à 7.
Les sticky Tag c'est ce mécanisme qui fait que si tu tapes de l'italique après de l'italique, ce que tu ajoutes est aussi en italiques. Dans certain cas ça marche pas top.
Si tu veux trouver des comportements étranges, il faut juste se servir un peu d'éditeurs qui font ça (Word, GMail, Jira, Confluence) par exemple. Pour des comportements très étranges il suffit de passer au copier-coller. Par exemple avec Jira, j'obtiens trois formatages différents selon l'ordre dans lequel j'insère mes logs dans le ticket (détail amusant, aucune version n'est la bonne) (Du genre, coller puis formater ne rend pas pareil que formater puis coller.) Sinon prend une liste d'une page web et colle la dans Gmail. etc. En fait je vais commencer une chaîne Youtube je crois.
[^] # Re: geany
Posté par ComputingFroggy (site web personnel) . Évalué à 2.
Tu dois avoir un plugin dans Geany : je l'utilise tous les jours (sur d'Ubuntu) et il ne m'ajoute jamais rien !
[^] # Re: geany
Posté par totof2000 . Évalué à 2.
Oui, je l'ai désactivé, mais au départ ça m'a bien fatigué (et inséré pas mal de bugs dans mon code). Mais ya pas qu'avec Geany que j'ai rencontré le problème : il me semble que c'est aussi le comportement d'Atom (que j'ai viré parce qu'il faisait plein de trucs tordus comme ça dans mon dos). La configuration de vim par défaut sur une redhat/centos me gave également (ajout de # en début de ligne si la ligne précédente en contient) : c'est pénible quand on doit faire des copier/coller de snippets de code (on passe du temps à enlever des choses que le truc soit disant intelligent a fait à ta place). Le pire, comme je le disais plus haut, ce sont les outils qui t'ajoutent des trucs, mais qui insistent pour les remettre lorsque tu les as enlevés.
[^] # Re: geany
Posté par freem . Évalué à 2.
Il y a les commandes "paste" et "nopaste" pour ça. Sinon, tu peux aussi faire un truc du genre "r !xclip -o". Ou, bien sûr, configurer vim en mode "vi", ce qui est ce que Debian fait pour le coup :p
[^] # Re: VSC
Posté par Moonz . Évalué à 5.
C’est bien parce que j’aime bien automatiser que je n’aime pas les IDE.
Un debugger graphique intégré c’est effectivement sympa la plupart du temps. Jusqu’au jour où tu veux automatiser une session de debugging en combinaison avec
git bisect
.Une chaine de build automagique intégré à l’IDE c’est sympa la plupart du temps. Jusqu’au jour où tu veux automatiser le déploiement sur une instance de recette avec docker.
[^] # Re: VSC
Posté par xcomcmdr . Évalué à -1.
Pour appeler le débogueur en dehors de l'IDE, c'est :
On peut aussi l'utiliser depuis la ligne de commande pour bien d'autres choses (déployer, builder, …) :
https://docs.microsoft.com/fr-fr/visualstudio/ide/reference/devenv-command-line-switches
Je rappelle à toute fin utile que VS est utilisé depuis longtemps pour développer des petits projets méconnus tels que Windows, DirectX, et MS Office.
Donc l'automatisation du déboguage, du déploiement, et tout le reste, existe depuis bien longtemps.
Même si c'est un IDE. L'un n'empêche pas l'autre (au contraire !)
Cette extension de Microsoft pour intégrer Docker semble le permettre :
https://marketplace.visualstudio.com/items?itemName=ms-vscs-rm.docker
Par ailleurs, rien n'est caché. Par exemple quand tu fais du natif, il est trivial de récupérer les options passées aux compilateur et de mettre ça dans un script.
Et quand on fait du .NET, soit (pour les besoins avancés) on peut utiliser l'API du namespace Microsoft.Build, soit :
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: VSC
Posté par Marotte ⛧ . Évalué à 6.
Tu as confiance en toi !
[^] # Re: VSC
Posté par barmic . Évalué à 1.
C'est très fallacieux. Il n'y a pas grande différence entre devoir comprendre vim + un autre outil pour trouver comment les utiliser ensemble et utiliser un outil qui fais plus de choses et devoir comprendre comment modifier ce qui te convient quand le besoin se fait sentir. C'est des approches différentes qui ont des avantages et des inconvénients et qui sont plus ou moins pertinents en fonction des situations.
Il n'y a pas besoin de faire des sous-entendu sur l'intelligence ou la capacité de réflexion de ceux qui ne font pas comme toi.
[^] # Re: VSC
Posté par Yuul B. Alwright . Évalué à -1.
Il n'y a aucun sous-entendu dans mon commentaire.
[^] # Re: VSC
Posté par barmic . Évalué à 2.
En disant « je ne fais pas comme toi, moi, je préfère réfléchir », ça peut être interprété comme tel.
[^] # Re: VSC
Posté par Yuul B. Alwright . Évalué à -1.
Je n'ai pas dit ça.
[^] # Re: VSC
Posté par Michaël (site web personnel) . Évalué à 7.
Pour ma gouverne c'est à partir de quelle version que Visual Studio est devenu bien? Ma dernière expérience avec le produit de 2012 et je suis sûr que tu parles d'autre chose. :)
[^] # Re: VSC
Posté par xcomcmdr . Évalué à -2. Dernière modification le 13 mars 2018 à 19:47.
Ça dépend ce qu'on recherche, et par quoi on met derrière le mot "bon".
Perso je pense que VS 2015 (aujourd'hui remplacé par VS 2017), est celui de la maturité :
Bref, globalement on sent vraiment le changement de culture chez MS. Les dévs ont été élevés à l'Open Source, Nadella pousse pour l'Open Source, et ça se voit.
Bien sûr quelle que soit la version, la version anglaise de l'interface est recommandée. La traduction française est souvent… surprenante.
En parlant de Git, Raymond Chen (un vieux de la vielle chez MS) a commencé une série sur Git.
- Stop cherry-picking, start merging, Part 1: The merge conflict :
https://blogs.msdn.microsoft.com/oldnewthing/20180312-00/?p=98215
- Stop cherry-picking, start merging, Part 2: The merge conflict that never happened (but should have) :
https://blogs.msdn.microsoft.com/oldnewthing/20180313-00/?p=98225
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: VSC
Posté par Lutin . Évalué à 5.
Il n'y pas vraiment de débat, toi tu préfères un IDE tout fait, les autres préfèrent un truc qui fait comme ils ont décidé à coup de vim+i3+bidulechose.
D'un autre coté n'exagère pas, configurer son environnement de dev ce n'est pas réinventer la roue, et c'est un truc que tu fais une fois tous les 5 ans et qui prends 10 minutes quand tu sais ce que tu veux.
[^] # Re: VSC
Posté par freem . Évalué à 5.
Et surtout, c'est un truc qu'il faut faire de toute façon même avec un IDE…
[^] # Re: VSC
Posté par xcomcmdr . Évalué à -3.
Non, j'ai pas besoin de :
Temps que je passe à configurer visual sur un nouveau projet :
- Rien. Tout est déjà défini dans les fichiers de la solution.
L'environnement externe à la limite (installer Oracle, par exemple). Encore que, c'est heureusement rare.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: VSC
Posté par Anonyme . Évalué à 7.
Non, mais tu as besoin :
[^] # Re: VSC
Posté par xcomcmdr . Évalué à 0.
Non, et puis d'ailleurs je fais pas de Java.
Non, j'utilise Viaual Studio, le même que pour C, C++, C#, Javascript, SQL, HTML5, CSS, XML, XAML, …
Non, et puis d'ailleurs je fais pas de Qt.
Et pour la partie C++ y'a sûrement moyen avec Visual. :)
Que j'utilise un IDE ou un éditeur de texte, "mais tu feras comment pour le langage X ?" est une fausse question.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: VSC
Posté par Lutin . Évalué à 4.
Rajouter les plugins bidules, tu le fais qu'une seule fois, et ça dure 10 minutes.
Et encore une fois, dans l'utilisation quotidienne, IDE tout fait ou pseudo-IDE en briques, ça revient exactement au même.
[^] # Re: VSC
Posté par xcomcmdr . Évalué à -1.
Une seule fois certes, sauf que les plugins que j'ai trouvé étaient soient pas géniaux, soient n'existaient pas. Rien que pour la complétion au niveau de VS, faut se lever tôt pour trouver un plugin équivalent.
Et puis bon, non, configurer son .vimrc et les plugins bien comme il faut (et surtout chercher/trouver les bons, quand ils existent), ça m'a pas pris 10 minutes, non. Plutôt des jours.
Raison pour laquelle j'ai laissé tomber.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: VSC
Posté par freem . Évalué à 6. Dernière modification le 15 mars 2018 à 14:43.
Balèze.
[^] # Re: VSC
Posté par xcomcmdr . Évalué à 1.
Erreur 404, tout ça. :)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: VSC
Posté par freem . Évalué à 3.
Quand je dois interagir avec un IDE, il me faut:
Et tout ça, pour chaque langage utilisé.
Avec le combo vim+i3+urxvt+cmake+clang+cgdb, tout ces points sauf le 1er sautent, et sans plugins particulier.
Par rapport à tes propres points:
Par contre, y'a bien un plugin qu'il faut installer dans les IDE pour moi. Celui qui permets d'utiliser le système modal de vim.
Je me souviens avec absolument 0 nostalgie de l'horreur de créer un projet qui dépende d'une bibliothèque externe avec Visual Studio. Et la dernière fois que j'ai eu à travailler avec ce machin, ben… ça s'était pas amélioré. C::B fait nettement mieux, sur ce point particulier.
[^] # Re: VSC
Posté par xcomcmdr . Évalué à 1. Dernière modification le 15 mars 2018 à 16:58.
Chez moi elle n'a jamais été utile. Pas une seule fois. Soit j'avais un truc à côté de la plaque, soit… un autre truc à côté de la plaque.
Ça existe depuis VS 2013.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: VSC
Posté par Napin . Évalué à 6.
C'est interessant car j'ai une approche diametralement opposee en suivant le meme chemin :
Ayant a gerer pas mal de trucs via SSH sur diverses machines, vim est quand meme pratique. Un peit
git clone mon_vimrc
et je suis comme a la maison en quelques secondes.Mais l'une des forces de vim, je trouve, c'est qu'on peut le definir comme "Le dernier editeur que j'apprends a utiliser".
Je me suis franchement demande pourquoi je n'ai pas appris l'utiliser "pour de vrai" il y a plus de dix ans : je serais maintenant super productif, alors que mes annees d'utilisation de "click and type" ne m'ont rien apporte de plus dans mon workflow. Et meme de cette maniere, je suis plus productif avec vim qu'avec mon editeur classique (mais j'ai le plugin vim dans VS Code)
La ou je suis certain de gagner en productivite au fil du temps avec vim, je suis quasi sur de rester au meme niveau en utilisant VS Code ou tout autre editeur classique (serieusement, les commandes comme
ct)
ouda{
font gagner un temps incroyable sur une journee).Voila, c'etait juste pour discuter de mon experience. Bonne fin de journee !
[^] # Re: VSC
Posté par Yuul B. Alwright . Évalué à 1.
Fait trop longtemps que je ne suis plus sur VIM, que font ces commandes?
[^] # Re: VSC
Posté par Baviste . Évalué à 2.
La première supprime le contenu jusqu'à la prochaine parenthèse fermante et passe en mode insertion, et la seconde supprime le contenu entre les accolades (comprises)
[^] # Re: VSC
Posté par Napin . Évalué à 2.
Et vu que le contenu supprime se met directement en memoire pour le prochain "coller", c'est vraiment super rapide pour refaire des fichiers complets au propre.
Ou encore, en html le remplacement du contenu d'un tag avec
cit
ou la suppression du tag complet viacat
qui permet de deplacer des morceaux de code de maniere precise et efficace.Sans dec, pour moi vim c'est une sorte de revelation. Sans exageration.
[^] # Re: VSC
Posté par freem . Évalué à 1.
Je ne connaissais pas ces variantes.
J'utilise "d%" moi, même s'il est vrai que ça ne mets pas en mode insertion. De manière générale, j'utilise énormément le %, qui permets de voyager d'une extrémité à l'autre d'un bloc (enfin, pas de tous les types de blocs, ça me marche pas pour les guillemets ou les chevrons (< et >, ça serait utile pour C++ mais probablement pénible à implémenter)) défini par des {},() ou encore [].
# Monsieur essaye de masquer la réalité
Posté par Christie Poutrelle (site web personnel) . Évalué à 6.
Eclipse 18.9%
PHPStorm 9.0%
Emacs 4.1%
Emacs est en dessous de PHPStorm, réveillez vous :D
[^] # Re: Monsieur essaye de masquer la réalité
Posté par ckiller . Évalué à -1.
Troll à part, Emacs n'est juste plus adapté à la jeune génération de développeurs et encore moins d'utilisateurs non développeurs.
Interface vieillotte, possibilité graphique faible, raccourcis clavier exotique, le lisp plus trop à la mode, portable windows moyen.
Ca amuse qui de rebricoler un .emacs à chaque upgrade ?
J'ai gardé emacs jusqu'à l'année dernière pour org-mode qui était une tuerie. mais il est aujourd'hui dépassé, pas facilement connectable/syncronisable.
Mais bon,il y a un certain charme à faire dans le retro mais uniquement le week-end
bref, it's time to move on.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Christie Poutrelle (site web personnel) . Évalué à 3.
On pourrait avoir le même genre de discours à propos de vim, aujourd'hui les IDE apportent tellement de fonctionnalités, et sont tellement bien intégrés avec les différents outillages que ça devient difficile de continuer à faire de la pub pour les bons vieux éditeurs pour doigts magiques.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par freem . Évalué à 10.
Sauf que vim… enfin, vi, à un avantage de poids: il est dans le standard POSIX. Savoir utiliser vi un minimum (et donc vim) implique d'être capable de se démerder «sur la majorité des systèmes Unix actuels» ce qui est un avantage non négligeable contre emacs ou visual machin ou truc bidule.
Ah, et aussi, pas besoin d'interface graphique, DONC utilisable via ssh (bon, ça, emacs et nano aussi, mais emacs est pas installé par défaut sur les distros que j'ai utilisées et nano est franchement limité en fonctionnalités).
Le problème, c'est que je ne connais aucun IDE qui s'intègre à mon shell aussi bien qu'un éditeur de texte du type vi (s'applique aussi à emacs, pour le coup je suppose).
Mais bon, oui, pour ceux qui aiment aller chercher la souris, les IDEs modernes sont superbes. J'en ai utilisés, j'ai même commencé par ça.
Je préfère mon i3+vim, merci (faut que j'arrive à me mettre à kakoune, mais je n'arrive pas à trouver en moins de 15min comment avoir la coloration syntaxique pour le C, le C++ et le sh à minima).
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Meku (site web personnel) . Évalué à 10.
Oui c'est ça le problème, vi est préinstallé par défaut sur les distro Linux et pas Emacs.
Madame michu qui découvre son shell et trouve par défaut cet éditeur de texte, elle ne va pas chercher plus loin car elle ne sait pas. Donc elle ne connaîtra pas l'Alternative. C'est un peu comme si on lui cachait l'existence du tout puissant Emacs !
C'est de la vente liée bordel !
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Kangs . Évalué à 3.
Je suis d'accord, vi est installé par défaut, mais le shell est par défaut en mode emacs, c'est un truc que je n'ai jamais compris sur les UNIX et UNIX like…
[^] # Re: Monsieur essaye de masquer la réalité
Posté par totof2000 . Évalué à 3.
Il me semble que pour Ubuntu ce n'est pas le cas: je crois que c'est un truc plus mal fichu encore (mais je ne me rappelle pas le nom).
[^] # Re: Monsieur essaye de masquer la réalité
Posté par freem . Évalué à 6.
Ils n'ont quand même pas mis powershell?
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Christie Poutrelle (site web personnel) . Évalué à 2.
Pour l'intégration au shell, certes, mais du point d'un développeur d'applications, et non juste d'un simple besoin d'éditer du texte sur un serveur, ça n'a que peu d'intérêt, car finalement le shell n'est lui même, pour beaucoup de développeurs, qu'une interface pour lancer d'autres commandes (utiliser outillage dont je parle en somme), et s'il est intégré dans un logiciel spécifique, le shell n'a plus réellement d'utilité pour beaucoup de gens.
L'automatisation que te fournit ton outil de développement intégré (IDE en toutes lettre pour recentrer le contexte) va, en avance de phase, ordonnancer tout ces outils de manière cohérente selon les technologies que tu utilises, et pour certains tout en restant extrêmement flexibles et configurables, pour ne pas t'enfermer dans les choix d'opinion du développeur de ce dernier.
Toute cette automatisation qu'il prend en charge d'entrée de jeu et sans devoir y installer des dizaines de plugins, ni taper des centaines de lignes de configuration dans dot file, sans même avoir besoin d'en connaître les raccourcis claviers, permet à la fin d'avoir un environnement ISO sur tous les postes de travail sur lequel un développer peut être performant extrêmement rapidement, tout en restant configurable pour ceux qui veulent aller plus loin.
La plupart sont tous aussi automatisables que Vi ou Emacs eux-même, fournissent des débuggeurs contextuels, graphiques et lisibles, des possibilités d'introspection du code puissante et par simple clic, un retour visuel des erreur au fil des actions du développeurs, une UI qui se contextualise en fonction des actions menés, une interface multi-éditeur en onglet, ou pavable, etc, etc, etc.. Ce qui de prime abord, pour réussir à mimer de façon complète dans un Vi ou un Emacs demande un courbe d'apprentissage extrêmement complexe: les gens qui maîtrisent et utilisent quotidiennement ces deux derniers ont tendance à l'oublier.
Quelle idée de travailler via SSH ! Enfin encore une fois du point de vue d'un développeur, ça n'a pas de sens. Si j'ai une machine sous les doigts, je n'ai pas besoin d'une deuxième pour développer, celle que j'ai me suffit, et ce même si ma cible est un environnement radicalement différent, c'est une autre des forces de l'IDE, de pouvoir émuler ce dernier sans avoir besoin d'y redéployer du code en permanence.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par flagos . Évalué à 4.
C'est utile, notamment en télétravail. Tu peux avoir besoin de bosser sur ta machine de dev depuis chez toi, notamment parce que ta machine au boulot est nettement plus péchue que ta personnelle, ou encore parce qu'il ne t'est pas possible de lancer des tests d'integration depuis ta machine chez toi car le reseau chez toi ne contient les dizaines de VM permettant de faire ces tests. Ou encore parce que tu n'as pas envie de prendre le risque de copier les sources sur lesquelles tu travailles sur ta machine perso.
Personnellement, je trouve sincèrement très pratique de pouvoir lancer emacs en ssh et de conserver des features a peu près dignes d'un IDE.
Et c'est assez ultime pour te forcer a ne pas utiliser la souris :-)
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Christie Poutrelle (site web personnel) . Évalué à 0.
Et bien au contraire, j'aime bien utiliser ma souris. Ça me force à ne pas taper trop vite, et évite de faire certaines erreurs très bêtes.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par ff9097 . Évalué à 1.
C'est pratique le développement sur des VM de dev, ça permet de faire tourner un ensemble de briques qui fonctionnent ensemble dessus, iso-prod si possible, ça permet de développer à plusieurs en même temps dessus, ça se créer / clone / supprime facilement. T'as besoin que d'un SSH sur n'importe quel machine pour bosser.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Christie Poutrelle (site web personnel) . Évalué à 2. Dernière modification le 15 mars 2018 à 09:46.
Je travaille avec des VM de dev depuis plusieurs années, et l'avantage d'une VM locale dans ta propre machine, c'est que tu peux monter facilement un partage de fichier, un NFS ou autre SSHFS (nous on utilise SSHFS après avoir expérimenté NFS, j'ai encore des vieilles VM en NFS par ailleurs) et on utilise les outils de développements de la machine hôte pour le projet dans la VM sur le point de montage de la VM.
Plein de gens pensent que le SSHFS est lent, mais que nenni, en vrai j'ai un Eclipse branché dessus, et la différence ne se voit pas (un autre avantage des IDE de manière générale est leur bonne gestion du FS, l'indexation efficace, bien que tous ne soient pas égaux la dessus).
Le mieux du mieux c'est qu'en tant que développeur, je n'ai pas à m'occuper de comment ça marche puisqu'on a un outillage interne qui effectue le déploiement sur nos machines, quelle soit la distribution Linux (et fonctionne aussi avec MacOS). Encore une fois, VIeMacs dans un SSH n'a absolument pas sa place dans cette infra.
Je tiens à préciser que nos VM peuvent par ailleurs contenir des Docker, et de manière générale sont ISO-prod, contiennent les mêmes outils de déploiement, seul leur dimensionnement (nombre de CPU et RAM) change.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Tonton Th (Mastodon) . Évalué à 0.
Et quand la machine est deux rues plus loin, ou à 300km ou de l'autre coté d'un océan, tu fais comment ? Teamviewer, VNC, voire même un deck de 80cols par Chronopost ?
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Christie Poutrelle (site web personnel) . Évalué à 2.
On parle toujours de développement là ? A priori, ça arrive rarement de développer sur une machine de production ou de l'autre côté de la planète non ? Où alors ça peut j'imagine, mais c'est carrément se tirer une balle dans le pied.
Il y a bien sûr quelques exceptions, comme par hasard le développement sur SAP, mais de toute façon là tu oublie le SSH puisque t'es obligé de passer par leur environnement de développement propriétaire, ou le développement sur certains vieux mainframes, mais c'est très spécifique.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par totof2000 . Évalué à 2.
Oui. Tout le monde ne développe pas forcément sur une vpm locale, il y a des développements qui se font sur infra VMWare/xen/autre distants. Il y a un peu lus d'1 an j'étais en mission à un endroit ou je ne pouvais pas installer de vm sur mon poste de travail: ma vm linux était hébergée sur une infra mutualisée.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Guillawme (site web personnel, Mastodon) . Évalué à 2.
Justement avec Emacs pas besoin qu’il soit installé sur le système distant : il suffit d’utiliser TRAMP pour ouvrir les fichiers distants avec ton Emacs local.
Ouvrir un fichier distant à travers une session ssh n’est pas très différent d’ouvrir un fichier local : https://www.gnu.org/software/tramp/#Quick-Start-Guide
J’utilise ça souvent, parfois même quand le fichier distant est sur un ordinateur situé dans la même pièce (parce que cet autre ordinateur n’a pas Emacs).
[^] # Re: Monsieur essaye de masquer la réalité
Posté par freem . Évalué à 3.
Moui, m'enfin, ça, tu peux le faire avec n'importe quel logiciel: il suffit de passer par sshfs. Par contre, je n'ai pas mis l'accent sur le fait que pas besoin d'installer un Xorg pour utiliser vim, emacs ou nano: petit oubli de ma part (parce que quand une machine qui n'est pas destinée à un humain perds le réseau, on est bien contents d'avoir un outil pour modifier la config sans passer par sed).
[^] # Re: Monsieur essaye de masquer la réalité
Posté par flagos . Évalué à 3.
Je suis assez d'accord avec toi, en theorie, ca marche pareil.
En pratique, quand tu passes a travers un VPN et un réseau wifi/d'entreprise/4G qui font des blagues, et ben sshfs est assez peu stable. Il suffit d'en servir quelques jours dans différentes situations pour se rendre compte que ce n'est pas un moyen fiable de travailler.
Tramp la dessus est nettement plus résistant aux erreurs de réseau.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Yuul B. Alwright . Évalué à 3. Dernière modification le 13 mars 2018 à 18:31.
En quoi?
En quoi?
Et alors? En quoi c'est mal de faire différemment?
Et alors?
En quoi?
En quoi?
Tu ne sais pas comment synchroniser des fichiers?
FUD
Avec une phrase aussi condescendante et des affirmations sans preuves, tu n'as pas mis à part le troll.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par ckiller . Évalué à 0.
Essaie de faire des ~~~ sous un mot comme pourrait le faire un correcteur orthographique, impossible.
Essaie de faire apparaître les folders genre impossible
Essaie de faire des cartes genre freemind interactive avec emacs, pas juste afficher un svg, mais pouvoir interragir avec. impossible. (ca aurait été marrant avec org mode)
Faire afficher un symbole en exposant d'un mot, et le rendre interactif ? ben non.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Yuul B. Alwright . Évalué à 2.
flyspell-mode
Flymake
Flycheck
hideshow-mode
M-! freemind
^symbole
C'est à dire?
[^] # Re: Monsieur essaye de masquer la réalité
Posté par ckiller . Évalué à -1.
on parlait de capacité graphique, flyspell c'est du simple souligné (et encore, obligatoirement de la même couleur que le texte
je connais hideshowmode, c'est loin d'être graphiquement à la hauteur de ce que font les ide modernes
bref
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Yuul B. Alwright . Évalué à 2.
Tu as demandé:
[^] # Re: Monsieur essaye de masquer la réalité
Posté par omc . Évalué à 2.
Qu'est-ce que c'est que cette capture d'écran toute vilaine ? Mon Emacs ne ressemble pas (plus) à ça…
[^] # Re: Monsieur essaye de masquer la réalité
Posté par jyes . Évalué à 3.
Je n’utilise pas Emacs, mais je dois avouer que sur cette capture il n’est pas loin d’être aussi beau que mon Vim 😆. Et le souligné zigouigoui qui te tient tant à cœur y semble implémenté.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par ckiller . Évalué à 4.
emacs a une dette technique fort, cela se ressent même sur le choix des raccourci. Même la terminologie de “Meta key” à la place de “Alt key” sent fort la naphtaline. De même que “kill” pour “cut”, et “yank” pour “paste”.
Et je ne te parle pas de frame qui veut dire windows, (RMS propose de renommer en 2014 https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00496.html )
il n'y a aucune plus- value à faire différemment sur ces points, et c'est très perturbant pour les débutants.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Yuul B. Alwright . Évalué à -1.
C'est une question de gout.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par lolop (site web personnel) . Évalué à 6.
C'est une question de gnu
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Michaël (site web personnel) . Évalué à 3. Dernière modification le 13 mars 2018 à 20:03.
Franchement entre Emacs et les produits IntelliJI ou Visual Studio (ok j'avoue VS2010 mais il paraît que de puis c'est devenu bien) et bien franchement je trouve ces machins tout sauf agréable à utiliser – à part le débogueur visuel mais je préfère les langages où on a n'a pas trop besoin de faire du débogage visuel en pas à pas. ;)
C'est peut-être une observation un peu étrange mais j'ai du mal à faire abstraction de toutes ces annotations et pop-up, et, je pèse mes mots, ça me pète grave les couilles de voir un feu d'artifice de couleurs et de fenêtres popup d'auto-complétion et de changement d'états dès que j'ajoute un mot à une liste… L'approche de l'écosystème Emacs est plutôt plus seine – l'info complémentaire est en général affiché dans la petite barre au pied de l'écran et l'analyse de syntaxe est faite à la sauvegarde (merlin pour OCaml) ou à l'évaluation (slime pour Lisp).
Ceci-dit je ne perds pas espoir: depuis quelques années on a fait beaucoup de progrès dans l'UX et beaucoup d'interfaces se sont simplifiées et proposent des choses simples pour des tâches simples au lieu de submerger l'utilisateur d'un dégueulis d'informations et de questions importunes… peut-être que d'ici quelques années on aura aussi des IDEs ergonomiques (à part Emacs ;) ).
Sinon pour le “lisp pas trop à la mode” je pense que le rapport expérience/salaire des développeurs clojure mentionné dans le même rapport pourrait faire figure d'incitation ;)
Je pense que c'est un peu éxagéré!
Ce que me semble refléter ce chiffre est que beaucoup de développeurs sont soit JavaScript, PHP, Java, C ou C++ et que pour l'un quelconque de ces langages il y a des environnements très sophistiqués. Pour moi qui édite en sus des précédents du Lisp, OCaml, Shell, TeX, ansible, du markdown, et du task-juggler, j'ai quand même intérêt à utiliser Emacs – qui sait éditer les fichiers dans un container docker sur une machine distante, et ça aussi c'est pas forcément cochon.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Thomas Douillard . Évalué à 9.
C’est con c’est pas mal pollué la Seine, faudrait pas se plonger dedans :/
# erreur! ce sondage est un grossier faux
Posté par saltimbanque (site web personnel) . Évalué à 10.
alors "development environment", là trop gros ça passera pas.
Non Emacs c'est plutôt une interface vers une autre réalité. A la rigueur avec Emacs on peut faire du développement personnel
[^] # Re: erreur! ce sondage est un grossier faux
Posté par gUI (Mastodon) . Évalué à 4.
Un kernel, Emacs… c'est la vie !
https://www.informatimago.com/linux/emacs-on-user-mode-linux.html
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Stackoverflow
Posté par flagos . Évalué à 6. Dernière modification le 13 mars 2018 à 16:27.
Une petite pépite dans ce sondage:
[^] # Re: Stackoverflow
Posté par flagos . Évalué à 1.
Bon, je viens de voir que le sondage venait de chez Stackoverflow, alors forcement… Mais bon, ca m'a quand meme fait rire.
[^] # Re: Stackoverflow
Posté par aiolos . Évalué à 1.
Ben moi j'ai (re-)découvert que j'avais un compte chez eux en recevant le mail annonçant cette étude :-D
# La vérité est ailleurs
Posté par omc . Évalué à 6.
Si je tape
M-x quit
dans mon minibuffer, vous disparaissez tous# Kate
Posté par raphj . Évalué à 5.
Manifestement, les nombreuses personnes qui utilisent Kate n'ont pas répondu au sondage.
[^] # Re: Kate
Posté par freem . Évalué à 2.
Les développeurs sous KDE utilisent pas plutôt kdevelop?
[^] # Re: Kate
Posté par Chuck #1 . Évalué à 1.
Kdevelop et Kate font appel au même composant - KatePart - pour le widget d'édition de texte.
https://kate-editor.org/about-katepart/
À noter : Kate (et donc Kdevelop) propose un mode d'édition vi (que je n'ai pas testé depuis KDE 2).
Cette signature est publiée sous licence WTFPL
[^] # Re: Kate
Posté par Maclag . Évalué à 4.
Ce qui me fait aussi remarquer l'absence de QtCreator. Mais je suppose que c'est une niche?
[^] # Re: Kate
Posté par YBoy360 (site web personnel) . Évalué à 0.
ou "cat > MONFIC.TXT"
même si pour le suivi de version c'est un peu casse noisette..
Ce que dit le sondage aussi, c'est qu'Intellij est très populaire puisqu'il regroupe Intellij, Android Studio et autres PHPStorm. Pourtant, dans Intellij, il y a Intel, et ça, c'est encore populaire ???
# Fake News
Posté par Meku (site web personnel) . Évalué à 6.
Heureusement, bientôt la loi interdira de poster ce genre d'ignominie insupportable pour les fidèles.
Mais nous devons encore travailler le gouvernement au corps pour qu'il mentionne Emacs dans la constitution. Il ne faut pas relâcher nos efforts de lobbying.
[^] # Re: Fake News
Posté par RyDroid . Évalué à 1.
S'arrêter à la constitution ! Bêtise crasse, mon cher. GNU Emacs est un droit humain, le zérotième d'ailleurs ! À défaut d'ambition de sainte réforme, ce gouvernement devrait au moins faire en sorte d'enseigner Emacs dès le plus jeune, au besoin la sagesse et le pragmatisme réunis imposent d'utiliser ordonnances et 49.3 simultanément. Ô j'entends déjà au loin la protestation des 1%, des saboteurs et saboteuses à en devenir assurément, mais la conjuration du Emacs triomphera et gloire s'en suivra à Saint IGNUcius. En hurd camarades !
# Biais de population
Posté par Alex G. . Évalué à 6.
Le problème c'est la population : les mecs qui vont sur StackOverFlow c'est des gens qui codent par copier/coller, alors forcément ! Tu aurais du titrer "les mauvais développeurs préfèrent vim à Emacs"
PS: c'est de l'humour hein !
# conclusion ?
Posté par pizaninja . Évalué à 3.
L'impression que j'ai parfois, c'est simplement qu'il faut être sacrément bien câblé pour utiliser Emacs, et que peu nombreux sont ceux qui ont le niveau (j'ai pas le niveau).
C'est un peu comme les claviers Dvorak ou bepo… J'ai essayé un temps, et j'ai bien galéré. J'ai fini par abandonner ne voyant pas le bout du tunnel : bien plus nul sur bepo que sur Azerty après 1 mois de galère.
Qu'en penser? Rien, si ce n'est que je suis moins bien câblé que d'autres. Et après ? Est-ce qu'en utilisant les mêmes outils que des surdoués, je deviendrai surdoué ?
Doit-on expliquer aux surdoués qu'ils se trompent car ils ne font pas comme la majorité des gens ? Doit-on niveler par le bas ou par le milieu ?
Je déteste les orientations prises par Microsoft. Mais je dois avouer que VSC est le premier outil MS que j'adopte favorablement à l'usage. Je vois mal la différence fondamentale avec Atom, si ce n'est que VSC me cause moins de pb d'utilisation abusive de mémoire.
[^] # Re: conclusion ?
Posté par totof2000 . Évalué à 1.
Pour ma part j'ai essayé VSC il y a peu et d'après ce que j'en ai vu il m'a l'air bien fichu. Cependant je me méfie : Microsoft (et d'autres) a tendance à casser les trucs qui marchent plutot bien au bout d'un moment, donc à voir.
# Linux / Windows / Geany
Posté par harlock974 . Évalué à 4.
Je ne comprends pas tout du sondage :
Most popular platform : Linux 48.3 % / Windows 35.4 %
Developers' Primary Operating Systems : Windows 49.4 % / Linux 23 %
En plus il y a eu apparemment plusieurs choix possibles dans certaines questions, avec des totaux nettement supérieurs à 100 %, ce qui rend les interprétations un peu difficiles.
Enfin il n'y a pas Geany dans les "Most Popular Development Environments". Pourtant, je l'utilise :D
[^] # Re: Linux / Windows / Geany
Posté par steph1978 . Évalué à 2.
Si on te fournit une machine sous windows, ça ne veut pas dire que c'est ça que tu préfères…
[^] # Re: Linux / Windows / Geany
Posté par Shuba . Évalué à 2.
Il me semble que "Most popular platforms" parle des plateformes cibles pour le code développé. La forte présence de linux peut ainsi s'expliquer par les codes serveurs.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.