Discussion :

[microhft]

Bonjour,

Avec tout le bien que je lis sur emacs sur la toile (vim aussi mais là n'est pas la question), j'ai décidé de m'y mettre vraiment pour voir de moi même pourquoi certains disent que c'est mieux qu'un IDE.

J'ai donc pu tester son fameux outil Gnus et j'ai pu envoyer un mail avec, bon ca c'est bien. Maintenant entre l'interface que j'aie de gmail et celle de emacs, franchement je ne peux pas quoi....encore pour programmer je peux comprendre qu'il peut avoir des avantages (que je n'ai pas encore pu trouver d'ailleurs), mais lire ses mails avec.... je ne comprends plus.

Svp, y'en a t ils parmi vous qui l'utilisent "vraiment" pour lire et envoyer leurs mails quotidiennement, ou est ce que c'est juste un gadget sympa mais sans plus.

J'ai toujours programmé avec emacs (en ne retenant que C-x C-s) mais l'année dernière j'ai découvert Visual studio qui est un excellent IDE à mon avis (moi qui déteste windows), si on ne m'avait pas obligé à l'utiliser au travail, je ne l'aurai jamais découvert je crois et je n'aurai jamais gouté à la joie d'avoir un débugger (je précise que je n'avais jamais utilisé gdb car je débuggais tout seul) et l'autocomplétion. Malgré moi, je ne peux plus m'empêcher de faire des comparaisons entre emacs et Visual, et je ne comprends pas vraiment les gens qui disent qu'ils sont vraiment plus productifs avec emacs qu'avec un IDE, je commence même à me dire que "c'est juste qu'ils sont vieux, qu'ils l'ont tjr utilisé et maintenant ils ont du mal à s'en séparer.... comme ma grand mère quoi avec sa très vieille télé".

Oui oui, on va me rétorquer qu'il existe tel module ou tel truc pour faire ca, et que l'avantage c'est qu'on peut le configurer etc... et moi je vais répondre à ca: mon but c'est de programmer, ça ne m'interesse pas de configurer un éditeur de texte pour qu'il devienne un IDE alors qu'ils y'en a d'autres tout prêts et qui sont faits pour ca. D'ailleurs même ces modules, ne donnent en général pas de très bons résultats.

Ne comprenez pas mal mon post, j'adore Linux, j'adore la programmation et j'aime vraiment emacs (je l'utilise tout le temps pour travailler sur de petits fichiers), c'est juste que maintenant que j'ai découvert le sex avec Visual, j'ai du mal à y renoncer. Néanmois, Emacs m'aura quand même fait prendre de sales habitudes:

- Programmer tout un projet dans un même fichier.
- Pour débugger, j'affichais les variables dans le terminal.

Qu'est ce que je ne vois pas?

Ps: Je parle de visual, mais je sais qu'ils y'en a d'autres sur Linux.

Merci

[lennelei]

Si ce post était daté du 1er avril, j'aurais compris mais là...

Déjà Visual Studio est certes très bien mais :

1. il coûte un bras (et je ne parle pas de la licence Windows)
2. il reste limité à certains langages
3. il reste limité à Windows
4. il est assez lourd (toute proportion gardée)

Ensuite, emacs, pour les emails, je n'ai jamais testé, mais bon, ça n'est pas non plus le but premier
C'est un peu comme si tu utilisais open office comme firewall.

Quand au fait d'accuser emacs de t'avoir fait prendre de mauvaise habitude, tu n'as qu'à t'en prendre à toi même... c'est un peu comme si tu disais que de manger au mc do t'a fait prendre l'habitude de manger avec tes doigts...

Pour finir, c'est quoi ta question exactement ? Savoir si quelqu'un utilise emacs comme client email ?!

[frp31]

le problème d'emacs, c'est que c'est un outils de geek voir de gourous pour tout implémenter dans une usine à tout faire.

emacs fini par remplacer purement et simplement le shell chez certains "fous fous" (dans le fichier passwd !!!! sisi !!! véridique j'en ai vu)....

le problème que ça pose ? bha c'est surtout étique en fait....

avec tous les outils/scripts/macros/raccourcis... ça fini par ressembler à plus rien, certes ça marche, certes c'est stable, certes ça fait tout, mais c'est l'usine, et personne ne sait plus vraiment comment marchent les macros etc...etc... mais parfois moins efficace ou rapide que les mêmes actions sous un shell, surtout en cas d'erreurs.

c'est quand même plus simple et surtout plus universel et migrable, d'avoir un vrai shell avec quelques alias et vim pour l'édition de fichiers multiples, si en plus on utilises screen là ça devient du bonheur... voir même plus que emacs ....

[gangsoleil]

Bonjour,

En gros, tu t'es mal servi d'emacs pendant des annees, et tu as ensuite appris a bien te servir de Visual, et tu demandes pourquoi l'un est mieux que l'autre ?

Tout programmer dans un seul fichier, je ne l'ai jamais fait, alors que je ne code que sous emacs ou sous vim. La dessus, tu ne peux t'en prendre qu'a toi, et le multi-fenetre (c-x 3 sous emacs, :vs sous vim), ca existe de base, et ca permet d'afficher 2 fichiers cote a cote.

Pour debugger, tu affichais des variables dans un terminal. Bah oui, c'est le niveau 0 du debug, et tu en es reste la. Le fait que tu aies choisi de ne pas faire la meme chose sous Visual (qui permet lui aussi de ne pas utiliser un debugger), c'est encore une fois ton probleme. Mais la aussi, rien a voir avec l'editeur.

L'auto-completion, elle aussi, existe dans vim et emacs. Le fait que tu ne t'en sois jamais servi est, encore une fois, ton probleme, mais n'a rien a voir avec l'editeur (tu peux aussi utiliser Eclipse sans utiliser l'auto-completion, ni le debugger, ni quoi que ce soit d'autre, et trouver que c'est moins bien que notepad car plus lourd).


J'ai beau lire et relire ton post, je ne vois de ta part qu'une mauvaise utilisation d'emacs, et du coup, lorsque tu es passe a un autre editeur que tu as bien utilise (enfin mieux que l'autre), tu le trouves mieux. Ca semble raisonnable de ta part, mais ca ne dit rien sur les possibilites de l'un ou de l'autre des editeurs.

[microhft]

Pour répondre dans l'ordre:

Alek-C:


1. il coûte un bras (et je ne parle pas de la licence Windows)

Ce n'est pas moi qui paye, c'est l'entreprise. En plus, je parlais des IDE en général (fin de mon post).

2. il reste limité à certains langages

Je programme en C/C++/C#, ca me suffit.

3. il reste limité à Windows

Même réponse que 1, je parlais des IDE en général.

4. il est assez lourd (toute proportion gardée)

Emacs avec tous les modules qu'on doit lui rajouter pour être vraiment exploitable, devient aussi lourd que Visual.

Ma question: comment est ce que c'est possible d'être plus rapide avec Emacs, qu'avec un vrai IDE?

frp31:

J'étais d'accord avec toi jusqu'à ta dernière ligne, la version de base d'Emacs fait tout autant de choses que vi. Comparer vi/Emacs ne m'interesse pas, chacun utilise celui qu'il veut. C'est plus la comparaison vi-Emacs/IDE qui m'interesse.

gangsoleil

Tout programmer dans un seul fichier et Auto-completion: Car Emacs n'avait à l'époque aucun bon gestionnaire de projet, d'ailleurs je suis sur que même aujourd'hui et avec le CEDET/ECB ce n'est guère beaucoup mieux.

Debug: Bon là, on entend toujours les personnes qui sont contre l'utilisation de la souris, dis que c'est mieux. Je ne suis absolument pas d'accord. Prenez le cas de quelqu'un qui a envie de mettre 10 break-points et regarder à chaque arrêt les valeurs de trois/Quatres variables (pas toujours les mêmes) dont les noms ne sont pas très courts.

Avec Visual: 10 cliques pour les BP+1 pour lancer en ensuite on fait bouger la souris pour voir les valeurs. Donc facile.

Avec Emacs: M-x compile pour compiler. M-x gdb et mettre 10bp au clavier en tachant de ne pas se tromper dans les numéros des lignes. Ensuite on lance, et la à que fois, print truc print truc2 print truc3.....

Qui est ce le plus rapide?

Je reprécise le sens de mes questions: Trouver pourquoi Emacs rend plus rapide pour l'utiliser à la place des IDEs.

[frp31]

Pour répondre dans l'ordre:

frp31:

J'étais d'accord avec toi jusqu'à ta dernière ligne, la version de base d'Emacs fait tout autant de choses que vi. Comparer vi/Emacs ne m'interesse pas, chacun utilise celui qu'il veut. C'est plus la comparaison vi-Emacs/IDE qui m'interesse.

rassures toi je ne milites pas pour vi ni contre emacs mais plustot contre le fait que des softs parfait pour jouer leur rôles sont transformés en usines pour une toute petite population d'utilisateurs... rien de plus rien de moins..

manifestement me suis mal exprimé donc.

quand à comparer les outils et un IDE ça dépasse mon niveau de développement donc je ne permet pas de polluer le sujet.

[lennelei]

Edit: j'avais pas fait gaffe à ça

Trouver pourquoi Emacs rend plus rapide pour l'utiliser à la place des IDEs.

Qui a dit que c'était plus rapide ? Quand je lis ton premier post, tu nous parles d'email avec emacs, que ça t'a fait prendre de mauvaise habitude... etc...

Bref, comparer Emacs à Visual Studio me semble idiot, ça serait comme comparer une roue à un 36 tonnes.

N'empêche que si tu ne sais pas ce que c'est qu'une roue, le jour où ton 36 tonnes crève, tu as l'air malin




Tu es au courant que l'histoire de l'informatique n'a pas commencé avec Windows XP ?

Il existe des gens qui ont commencé à travailler sur des machines bien avant que tous les artifices actuels n'existent : je pourrais citer le grand système par exemple car c'est le plus vieux sur lequel j'ai eu l'occasion de travailler, mais d'autres personnes plus âgées que moi auront certainement des souvenirs encore plus intéressants... Le grand système, c'est quoi ? Grosso modo, un terminal en mode texte avec (quand même), des couleurs : pas de graphisme, pas de "gestionnaire de projet", pas de "gestion de version", pas d'auto complétion, peu de débogage... etc. Mais il n'empêche que des sacrés applications ont été créées et tournent toujours depuis toutes ces années !

Il y a des gens qui bossent sur des serveurs avec un simple accès ssh...

etc...

[gangsoleil]

Bien,

Donc nous comparons ici un editeur texte (pardon, un interpreteur LISP) avec les derniers IDE graphiques, independamment de la plateforme sur laquelle ils tournent, de l'OS ou du prix des licences, ou encore des langages de programmation geres.

Pour les arguments de vitesse que tu avance, je pense que c'est assez paradoxal avec le developpement en C, qui demande pas mal de temps de par le faible nombre de fonctions disponibles dans la norme C (89 ou 99).
Si tu passais, par exemple, a Java, tu te rendrais compte que la gestion des bases de donnees via hibernate est beaucoup plus rapide que via un driver ODBC.
Est-ce que, pour autant, Java est mieux que le C ? Non, ni mieux ni pire.

Il en est de meme pour Emacs et les gros IDE : ils n'ont pas les memes fonctionnalites, et n'offrent pas les memes services.

Tu aimes bien les gros IDE et la souris ? Libre a toi. Moi, je reste sous emacs/vim, avec un clavier et des macros. L'un de nous deux est-il systematiquement plus rapide que l'autre ? Je ne pense pas.

[microhft]

Merci, vous avez répondu à ma question. Voici ce que je retiens: L'important n'est pas l'IDE qu'on utilise mais la maîtrise que l'on a de ce dernier.

L'origine de ma question:

- Des dizaines de posts (en anglais) où des gens racontent qu'ils ont abandonné un IDE du type Visual pour Emacs et qu'ils sont vraiment plus productifs avec ce dernier.

- Des grands noms du Logiciel libre qui disent utiliser Emacs/Vi pour leur développement.

Donc en ce qui concerne les premiers, je me dis que finalement c'est juste qu'ils ont le problème inverse du mien, ils n'ont jamais su bien utiliser leur IDE et ils ont bien appris à utiliser Emacs, d'où l'impression d'être plus productif avec. Pour les seconds, je met ça sur le compte de l'habitude et la maitrise de Emacs/vi.... de plus un Stallman qui utilise Emacs ce n'est pas vraiment absurde

[ben.IT]

Salut,
je viens de tomber sur cette discussion et je la trouve très intéressante.

En effet, je suis actuellement en train de faire le cheminement inverse de microhft, c'est à dire délaisser mon IDE (eclipse) pour passer à Emacs.
Je précise ce qui motive mon choix, je suis amené à pratiquer de plus en plus de languages de scripts, perl,bash ... et je trouve que pour cet usage (i.e. des développpements courts) un éditeur tel que Emacs (ou ViM) est suffisant.

De plus mon usage est orienté web, il est agréable de pouvoir visualiser le résultat de ses modifications sur le serveur de développement sans passer par sftp même si le plugin est intégré à Eclipse.

Je me permets de citer le dernier message de microhft :

Merci, vous avez répondu à ma question. Voici ce que je retiens: L'important n'est pas l'IDE qu'on utilise mais la maîtrise que l'on a de ce dernier.

L'origine de ma question:

- Des dizaines de posts (en anglais) où des gens racontent qu'ils ont abandonné un IDE du type Visual pour Emacs et qu'ils sont vraiment plus productifs avec ce dernier.

- Des grands noms du Logiciel libre qui disent utiliser Emacs/Vi pour leur développement.

Donc en ce qui concerne les premiers, je me dis que finalement c'est juste qu'ils ont le problème inverse du mien, ils n'ont jamais su bien utiliser leur IDE et ils ont bien appris à utiliser Emacs, d'où l'impression d'être plus productif avec. Pour les seconds, je met ça sur le compte de l'habitude et la maitrise de Emacs/vi.... de plus un Stallman qui utilise Emacs ce n'est pas vraiment absurde

Je suis entièrement d'accord avec toi, les points que tu énonces sont pour moi une motivation vers ma "migration" vers emacs.

Voici mon avis, mon utilisation est certainement moins avancée que la votre.


à bientôt,
ben

[jack-ft]

Avec Visual: 10 cliques pour les BP+1 pour lancer en ensuite on fait bouger la souris pour voir les valeurs. Donc facile.

Avec Emacs: M-x compile pour compiler. M-x gdb et mettre 10bp au clavier en tachant de ne pas se tromper dans les numéros des lignes. Ensuite on lance, et la à que fois, print truc print truc2 print truc3.....

Qui est ce le plus rapide?

Je reprécise le sens de mes questions: Trouver pourquoi Emacs rend plus rapide pour l'utiliser à la place des IDEs.

Je ne suis pas un pro de gdb, mais, généralement, dans emacs, on peut rappeler les commandes précédentes de l'historique.
Je suppose que, quand on a tapé une fois "print truc print truc2 print truc3", on n'est pas obligé de le retaper à chaque fois: quelques M-p doivent suffire.

Avec emacs, on peut apprendre progressivement de nouveaux raccourcis clavier qui sont généralement plus rapides que l'usage de la souris.