Cher Nal,
Je t'écris aujourd'hui pour m'expliquer. En effet je pense devoir avouer que je suis un troll.
Mais loin du terme galvaudé utilisé par le commun des mortels pour qui un geek est un client d'Apple shooté à la pub, je suis ce que je considère un troll dans le sens positif qu'on peut lui donner.
Je vais expliquer ça avec mon dernier troll : emacs/vim vs sublime text/zed/atome vs intellij/eclipse (qui s'est passé ici)
Le troll ce n'est pas tout à fait moi qui l'ai commencé mais je doute qu'il aurait pris sans mes multiples interventions. J'ai un peu taquiné les utilisateurs d'emacs et c'était parti.
Mais pourquoi faire ça ? T'es qu'un idiot ! En plus t'a perdu pleins de points de karma !
Déjà le karma, je m'en fou. Mais surtout parce qu'on est passé d'une excellente dépêche avec des commentaires plats (à base de "super dépêche ! J'utilise emacs depuis 25 ans et il me plaît toujours autant j'ai hate qu'il soit packagé dans ma distribution"), à une excellente dépêche suivi d'excellents commentaires (des fois humouristiques). J'ai appris pleins de choses et je suis sûr que je ne suis pas le seul.
Un petit compte rendu rapide (et pas exhaustif) des pépites qu'on peut trouver dans les commentaires de la dépêche
(j'aime les titres concis)
Emacs
D'abord de quoi s'en mettre pleins les yeux avec un site pleins d'utilisation assez avancées d'emacs : http://emacsrocks.com/.
Un paquet de modules :
- highlight tail, qui laisse une trainée colorée de comète lorsqu'on tape :
- rainbow-mode qui affiche les couleurs à l'écran quand t'en as besoin, c'est vraiment utile pour faire de la css (/less/sass/etc.) :
- mu4e une interface pour utiliser emacs comme client email
- Dired gestionnaire de fichier pour emacs
- helm-projectile pour aller chercher des fichiers de manière plus efficaces http://tuhdo.github.io/helm-projectile.html
Pour ceux qui veulent de l'autocomplétion intelligente :
- C et C++ : Yasnippet qui semble un peu limité
- C et C++ : auto-complete-clang et sa version asyncrhone
- python : ropemacs qui utilise rope (ça marche aussi pour python)
Des astuces :
- édition de regexps avec un retour visuel : http://wikemacs.org/wiki/Regexp#Search_and_replace_with_visual_feedback
- pour chercher des commandes, on peut soit utiliser
M-x
et taper le nom de la commande soit C-h b pour avoir la liste des commandes. - la lecture de PDF directement dans emacs :
Pour ceux qui font du java, il existe une sorte de « pont » eclipse-emacs qui est peut être satisfaisant http://www.skybert.net/emacs/java/
vim
On peut découvrir un module pour avoir de multiples curseurs : https://github.com/terryma/vim-multiple-cursors
Comment passer en mode édition dans une commande vim : q:i
(marche aussi pour les recherches).
Pour mapper ça directement sur le :
/
?
, à mettre dans le .vimrc
:
nnoremap : q:i
nnoremap / q/i
nnoremap ? q?i
En vrac
- Pour le refactoring avec Ocaml, on découvre merlin
- Le module zmv de zsh http://zshwiki.org/home/builtin/functions/zmv
- qmv http://mylinuxbook.com/qmv-qcp-copy-rename-files-quickly/
- un petit rappel qui ne fait pas de mal sur rename :
rename 's%foo-bar%foo_bar%' *.xx
- Zed un éditeur de texte à la sublime text : http://zedapp.org/ Il est construit avec les technos web (htlm, javascript, CSS, etc). Les autres avantages comparé à Atom qu'il met en avant sont:
- on peut l'utiliser comme extension Chrome
- gestion native d'édition à distance à travers ssh
- les extensions n'ont pas de dépôt centralisé (comme Sublime ou Atom)
- effectivement, il utilise des buffers et pas des onglets (avec C-t on peut quand même voir une arborescence de fichiers)
Et la liste est loin d'être exhaustive.
Mais pourquoi je vous parle de ça ?… Ah ! Oui ! C'est pour d'une part faire remonter des choses qui me paraissaient intéressantes (on est pas loin du journal multibookmark là, non ?) et pour parler de manière un peu positive du troll de qualité comme on en trouve pas beaucoup ailleurs qu'ici.
Bon aller nal, j'te laisse et bon week-end
PS : Je ne place pas ce contenu sous licence CC-by-sa car je suis pas sûr d'en avoir le droit : des parties sont des copier-coller de commentaires qui ne m'appartiennent pas. Je n'ai d'ailleurs pas cité les auteurs, mais il y a un lien vers la dépêche initiale.
# Atom
Posté par neil . Évalué à 7. Dernière modification le 14 novembre 2014 à 18:19.
J’utilise pratiquement exclusivement Emacs et vim depuis une quinzaine d’année, je ne pense pas changer prochainement, mais les screenshots que tu montres sont des fonctionnalités bateaux et qui datent.
L’un des avantages des nouveaux éditeurs et d’avoir plus que le mode texte (avec couleur d’avant et d’arrière plan, comme pour
comet
etrainbow
) ou des images non-manipulables (PDF). Par exemple, sous Atom on peut faire des graphes pour exprimer les commits gits, éditer joliment du markdown avec aperçu instantanné, rajouter une barre d’outil type multimédia pour explorer les changements, demander à stackoverflow et obtenir les réponses formatées dans l’éditeur, afficher des labels par dessus des emplacements du texte comme sous vimperator pour y sauter directement au clavier et visuellement, avoir un éditeur graphique de Béziers pour les CSS, et j’en passe et des meilleures. Tout ce graphisme permet d’utiliser un peu mieux les moniteurs 4k et surtout notre cortex visuel.Le second avantage est que tout ça est configurable avec des technologies bateaux du web (CSS, CoffeeScript, CSON). Ça démocratise largement la création d’extensions, et sépare nettement le visuel, le script, et la configuration.
C’est juste dommage que ça consomme autant (Chrome inside).
[^] # Re: Atom
Posté par barmic . Évalué à 5.
:) D'une j'ai pas dis qu'elles étaient bateau, de deux je doute que tout le monde les connaisse (pas moi par exemple), de trois j'ai l'impression que les barbus semblent atteind d'un défaut de théorie de l'esprit.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Atom
Posté par Sébastien Wilmet . Évalué à 1.
Un aperçu instantané ne suit pas la philosophie de Markdown.
Markdown est justement fait pour être le plus lisible possible en format texte, si on suit quelques bonnes pratiques.
[^] # Re: Atom
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
Le gars il nous expliquer que le défaut des éditeurs de Markdown, c’est de ne pas couper les lignes à 80 colonnes, ce qui estpas joli quand la fenêtre d’affichage ne fait pas 80 colonnes.
Ben justement, s’il veut 80 colonnes, qu’il retaille sa zone d’impression à 80 colonnes ! Et s’il veut absolument une fenêtre large, et bien qu’il utilise un outil qui coupe ses colonnes à l’affichage ! Idem pour de l’impression écran que sur papier… Ce n’est qu’un paramètre de rendu, personnalisé.
Et puis personnellement, je n’écris jamais mon texte d’une traite sans jamais revenir dessus. Le seul moyen d’avoir 80 colonnes sans se prendre la tête quand on rajoute un mot dans une ligne qui fait déjà 80 colonnes, c’est de laisser ce boulot à un éditeur.
Ensuite le gars recommande aux autres de mettre deux espaces après les points parce que lui aime ça. Et si je réinventais ma typographie moi aussi ?
La contrainte d’être lisible en texte brut ne contraint pas d’écrire en texte brut. De même, la contrainte d’être lisible en texte brut ne contraint pas à ne pas l’interpréter… Justement, Markdown est un langage écrit pour être à la fois lisible en texte brut et à la fois interprétable, ce que fait un éditeur.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Atom
Posté par Sébastien Wilmet . Évalué à 0.
Si l'éditeur de texte retaille le paragraphe automatiquement à 80 colonnes quand on rajoute un mot au milieu, ça c'est un outil pratique.
« le gars »: c'est loin d'être n'importe quel « gars », Miguel de Icaza…
En anglais il est recommandé de mettre deux espaces après un point en mode texte. C'est assez courant sur les mailing lists, dans les commentaires de code, etc, même si tout le monde ne le fait pas.
Miguel fournit deux liens avec plus d'explications sur ça, donc ce n'est pas lui qui réinvente la typographie, loin de là…
[^] # Re: Atom
Posté par neil . Évalué à 2. Dernière modification le 21 novembre 2014 à 18:52.
Joli argument d’autorité.
Pas du tout, ça a été le cas dans la première partie du vingtième siècle, ça a été à la mode un peu avant, mais c’est depuis largement obsolète dans la grande majorité des ouvrages de typographie anglophones, comme l’indiquent les nombreuses références de l’article Wikipédia associé.
Il dit surtout que ça sert à mieux repérer le début des phrases (!). Ne parlons même pas des liens qui sont des blogs remplis d’arguments pseudo-scientifiques pour justifier l’antique pratique, avec des preuves spectaculaires à coup de Gimp (!). En rajoutant des espaces, non seulement on perd de l’information contextuelle lors des saccades pour la lecture, mais on perd aussi de l’espace dans des terminaux, on rajoute de la complexité à l’éditeur, et on grossit ses documents. Heureusement tout cela reste tout à fait mineur.
Pour ceux qui ne connaîtraient pas le personnage, on peut consulter sa page Wikipédia, avec tout ses bons conseils du moment : utiliser Mac OS X plutôt que Linux, utiliser OOXML plutôt qu’ODF ou encore utiliser .NET sous Linux. Il reste pertinent pour avoir initié GNOME et Midnight Commander dans les années 90.
[^] # Re: Atom
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Miguel est une autorité compétente et recevable pour des problématiques liées à Mono par exemple, mais ce n’est pas du tout une autorité pour Markdown.
C’est comme si François Hollande donnait son avis sur le noyau Linux, être président de la république ne le rend pas compétent en dev noyau.
On a bien inventé l’espace insécable fine à placer avant une ponctuation double, ils n’ont qu’à inventer l’espace long à placer après le point s’ils veulent vraiment inventer quelque chose…
Un des gros défaut de Markdown est qu’il y a toute une partie de la spec qui hérite directement du langage de programmation Whitespace, avec des caractères de contrôles invisibles : alinéa, verbatim… et Miguel veut rajouter de la typographie… Non, s’il vous plaît, pitié !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Atom
Posté par barmic . Évalué à 4.
Avec vim,
gqq
ougqap
.De rien
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Atom
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Et est-ce que ça récupère le premier mot de la ligne suivante pour le mettre à la fin de la ligne actuelle si je supprime un mot sur la ligne actuelle ?
Dans le cas où l’éditeur sait récupérer les mots de la ligne suivante pour garder une moyenne proche de 8, que se passe-t-il si je veux volontairement placer un alinéa mais pas un saut de paragraphe ?
Bref, la coupure automatique à 80 colonnes est defective by design. Elle ne marche que pour les machines qui pondent du texte sans modifier l’existant.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Atom
Posté par claudex . Évalué à 5.
gqq ne va travailler que sur la line (ou la sélection en mode visuel), tu peux aussi spécifier des ranges. Après, l'alinéa sans saut de paragraphe devrait être puni de mort (mais si tu y tiens vraiment, il doit y avoir moyen de faire une macro qui ne touche pas à aux lignes qui commencent par un espace).
Le plus gros problème, ce sont les URL de plus de 80 caractères (même moins, ça rend très moche),
« 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
[^] # Re: Atom
Posté par dzecniv . Évalué à 3.
C'est très joli mais pour moi, justement, cela équivaut à des pertes de fonctionnalité. Exemples ci-dessous.
sous Emacs aussi (bien sûr), avec magit
officiel: http://magit.github.io/master/magit.html
présentation avec screenshot sur "logging": http://www.masteringemacs.org/article/introduction-magit-emacs-mode-git
Comme dit dans d'autres commentaires, cela casse l'esprit du markdown. On n'a pas vraiment besoin de l'apperçu dans Emacs, car le formattage est légèrement pris en compte lorsqu'on ouvre un fichier .md: les italiques sont mis en italique, les titres mis en avant, les blocs de source aussi, etc. Je n'ai pas trouvé de paquet Atom pour faire la même chose. J'en ai un qui aide à l'écriture, mais pas qui formatte le buffer. En apparté, une des raisons pour lesquelles je préfère le org-mode est qu'il va encore plus loin: les liens dont la syntaxe est [titre [url]] sont directement transformés en lien hypertexte, il offre plein de commandes et raccourcis pour créer des tableaux, tableurs, etc.
Bref, il est aussi possible d'avoir un apperçu du markdown en live (dans le navigateur) https://github.com/syohex/emacs-realtime-markdown-viewer
Aaargh… on est obligé d'utiliser la souris ! Et quand on clique, on ne sait pas quelle fonction du paquet est appelée. Du coup, comment apprendre son éditeur ? Comment scripter son usage ? Avec Emacs, on appelle la commande directement. Si on passe par le menu (ou la souris), on peut lui demander le nom de la fonction appelée (C-h k + clic sur bouton menu).
Pour Emacs, je pense à git-timemachine: https://github.com/pidu/git-timemachine quand on entre dans ce mode-là, on utilise n et p pour naviguer.
Très joli, mais je ne vois pas le gain d'usabilité si on est obligé d'utiliser sa souris. On ne peut même pas mettre le curseur dans la partie Stack, ce qui permettrait de chercher un mot-clef, de copier-coller uniquement notre sélection, etc.
Avec emacs-sos (Stack Overflow Search) https://github.com/omouse/emacs-sos , toutes les réponses sont listées dans un buffer formatté avec org-mode !!! On peut donc tout faire… à commencer par sauvegarder ce buffer s'il est vraiment intéressant.
ça c'est facile, on a ace-jump-mode autant sous vim que Emacs depuis longtems http://wikemacs.org/wiki/Ace-jump
Là je suis sec !
Je veux bien en voir plus, pour l'instant je ne suis point impressionné :)
Certes… je ne vais pas sortir un discours d'amour au emacs-lisp, qui est un peu trop bizarre à mon goût, mais j'ai appris à apprécier. Tout est scriptable, découvrable, modifiable avec un appel de fonction (language fonctionnel). Et je pense préférer ça à aller modifier des json pour modifier un raccourci clavier.
# Lecteur de PDF ?
Posté par stopspam . Évalué à 10. Dernière modification le 14 novembre 2014 à 18:42.
Dans un
IDEéditeur de code, fallait oser !Si je résume : en installant seulement systemd et emacs sur un pc, on couvre 99% des besoins.
Ça devrait pourtant simplifier la tâche des mainteneurs de paquets. Pourquoi sont-ils contre le changement ? Le changement, c'est pourtant toujours bien !
[^] # Re: Lecteur de PDF ?
Posté par eingousef . Évalué à 10.
Il manque juste un bon éditeur de texte et un bon système d'init !
*splash!*
[^] # Re: Lecteur de PDF ?
Posté par Guillaume D. . Évalué à 10.
tu peux meme faire plus simple :
http://www.informatimago.com/linux/emacs-on-user-mode-linux.html
a+
# rename
Posté par Tonton Benoit . Évalué à 4.
Attention la commande rename qui fait partie des util-linux ne fonctionne pas de cette façon (pas de regexp).
Debian fournit un rename qui fonctionne comme-ça, mais pour les autres il faudra l'installer manuellement (en version C ou Perl)
Et pour avoir le rename traditionnel sous Debian, c’est la commande rename.ul.
[^] # Re: rename
Posté par groumly . Évalué à 10.
Tu veux dire que sur les autres distro, il manque ul?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: rename
Posté par Bayet Thierry . Évalué à 9.
en fait, oui et non. Il manque ul dans un coin, pour être précis… -->[
# transformation
Posté par dzecniv . Évalué à 2.
De créature trollesque tu t'es transformé en un athlétique elfe. (en tant que fan d'Emacs,) Beau journal :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.