Programmer sous linux

Luc Hermitte · Le 13/10/2009, à 14:48

J'ai : ça.

Pour la doc, une fois que l'on a l'adresse (que je retrouve toujours via vim.wikia.com), et que l'on connait le format des tags (encadrés par des apostrophes pour les options, terminés par des () pour les fonctions, préfixés par des ':' pour les commandes, etc) on peut naviguer dans la doc en ligne facilement. Il faut juste savoir ce que l'on cherche...

Le Farfadet Spatial · Le 13/10/2009, à 20:24

Salut à tous !

Creak a écrit :

Ensuite, d'un point de vue pédagogique, il faut rendre l'outil intéressant dès le début plutôt que de lui dire que plus tard il verra l'intérêt. Si l'utilisateur est intéressé, il sera curieux de savoir comment sa marche et il farfouillera dans les fichiers de config.
Edit> Mon message pour Luc Hermitte s'applique aussi au Farfadet Spatial

Bon, je fais vite, parce que c'est du hors-sujet : ne t'en fais pas, lorsque j'enseigne à des débutants, je commence par leur faire utiliser Eclipse.

Simplement, il ne faut pas leurrer les étudiants : l'apprentissage est un effort. Certes, c'est un effort gratifiant, mais il ne faut pas mentir en disant que tout viendra tout seul -- auquel cas, d'ailleurs, cela n'aurait rien de gratifiant. Plus généralement, je trouve que l'on a perdu l'habitude de prendre le temps, d'aller au fond des choses : on veut tout, tout de suite et tant pis si, sur le long terme, ça ne vaut rien. Pourtant, bien souvent, lorsque l'on prend son temps au début, on en gagne beaucoup par la suite

Disons que c'est une exaspération passagère.

À bientôt.

Le Farfadet Spatial

Khyl · Le 13/10/2009, à 20:53

Le Farfadet Spatial a écrit :

Simplement, il ne faut pas leurrer les étudiants : l'apprentissage est un effort.

C'est sur ce point que beaucoup se trompent et croient que tous les éditeurs de texte se maîtrisent à la première utilisation. Malheureusement, des éditeurs aussi puissants que ViM ou Emacs nécessitent un temps d'apprentissage, ils sont très bons mais il faut effectivement prendre le temps d'apprendre les commandes, le fonctionnement et la configuration.

On veut bien apprendre un langage de programmation mais l'orgueil n'aime pas se rendre compte qu'un éditeur de texte, en mode texte apparemment simple, mérite un temps d'apprentissage parce que Monsieur et Madame Toulemonde utilisent un petit éditeur de texte graphique peu puissant qui se maîtrise en 10 minutes et qui s'utilise à grands coups de clics de souris.

Dernière modification par Khyl (Le 13/10/2009, à 20:56)

incises · Le 13/10/2009, à 23:06

Je ne résiste pas :
[troll]
Ta réponse n'est évidemment pas inintéressante, mais ça me rappelle soudain des temps lointains : une époque où de bons esprits répugnaient à programmer en C, parce que c'était bien loin de la machine et que rien ne valait l'assembleur, où, là au moins on savait ce qu'on faisait...
[/troll]
Une des caractéristiques de l'évolution de l'informatique c'est de créer sans cesse des outils "de plus haut niveau" plus adaptés à l'être humain, on y perd sans doute parfois quelque chose mais est-ce vraiment toujours une régression ?

Dernière modification par incises (Le 13/10/2009, à 23:10)

grouby · Le 13/10/2009, à 23:14

Khyl a écrit :

On veut bien apprendre un langage de programmation mais l'orgueil n'aime pas se rendre compte qu'un éditeur de texte, en mode texte apparemment simple, mérite un temps d'apprentissage parce que Monsieur et Madame Toulemonde utilisent un petit éditeur de texte graphique peu puissant qui se maîtrise en 10 minutes et qui s'utilise à grands coups de clics de souris.

euh si tu parles d'eclipse la, je suis pas du tout d'accord, c'est plutot un IDE professionel qu'un petit editeur graphique.... et a mon avis, avec le plugins c++, c'est de loin le plus abouti sous linux... et gratuit
Pour rappel micro$soft fait payer quasiment les meme fonctionnalitées pour tres tres cher...

apres vi c rigolo, c vrai que c'est un soft vraiment fou, mais il faut des semaines voire plus pour pretendre le maitriser... on est effectivement loin des 10 minutes

incises · Le 13/10/2009, à 23:20

J'ajouterai encore : ne pas vouloir passer un temps considérable à maîtriser, toute la doc d'Emacs, ni apprendre ou réapprendre le Lisp, le Lisp-pour-Emacs (un langage passionnant certes) pour simplement pouvoir maîtriser l'outil qu'on va utiliser pour programmer en C++, ce n'est pas forcément de la paresse, du refus de travailler, de réfléchir à fond, mais au contraire ça peut être la volonté de consacrer toute son énergie à ce qu'on estime, à un certain moment, l'essentiel, par exemple ici l'art de la programmation en C++

Cela dit j'adore Emacs et ma propension serait peut-être d'y perdre d'une certaine façon mon temps... se plonger dans l'outil cela peut être aussi une certaine forme de paresse, d'esquive...

Dernière modification par incises (Le 13/10/2009, à 23:33)

Khyl · Le 13/10/2009, à 23:56

Je parlais des éditeurs textes mais c'est valable pour Eclipse aussi qui est un bon très éditeur en mode graphique que j'utilise principalement pour les projets en Java.

Mon discours est de dire qu'on peut utiliser certains outils pratiques qui sont facilement abordables mais qu'il y a aussi d'autres outils plus puissants qui permettent de bien programmer quand on commence à les utiliser au mieux de leurs possibilités mais pour lesquels un apprentissage est nécessaire.

Luc Hermitte · Le 14/10/2009, à 01:05

grouby a écrit :

a- euh si tu parles d'eclipse la, je suis pas du tout d'accord, c'est plutot un IDE professionel qu'un petit editeur graphique.... et a mon avis, avec le plugins c++, c'est de loin le plus abouti sous linux... et gratuit
b- Pour rappel micro$soft fait payer quasiment les meme fonctionnalitées pour tres tres cher...
c- apres vi c rigolo, c vrai que c'est un soft vraiment fou, mais il faut des semaines voire plus pour pretendre le maitriser... on est effectivement loin des 10 minutes

a- Je ne suis franchement pas convaincu. Mes wizards C++ pour vim sont bien plus C++-aware que ce que l'on trouvera jamais pour eclipse (si encore il était codé en C++, il y aurait peut-ête une communauté vraiment initiée au C++ qui tourne sous eclipse -- je sais, c'est du troll facile, et pourtant...).
Dès que j'aurais le temps de raffiner mon extract-method, il n'y aura plus grand chose à envier sous vim.
Sinon, emacs a bien plus de refactoring C++ (payants) qu'eclipse.

Re-cf mon exemple de eclipse+ant+cpptask+gcc+cdt qui ne sait pas intégrer le résultat de la compilation pour sauter aux lignes d'erreur.
Sans parler qu'il n'est pas si plug'n'play l'eclipse : sous MacOSX, je viens de devoir mapper <cmd>+<space> sur l'expansion des snippets de JDT, et je cherche encore, pour Java, comment ne pas taper T deux fois dans "T p = new T()" surtout quand T provient d'un cots et qu'il fait 3 kilomètres de long -- parfois on s'attend à tellement de choses suite au hype derrière ces outils que l'on en tombe de haut.

b- VC++ express ?
C'est déjà un excellent compromis en gratuit dans la famille VC++.

c- A peu près autant de temps que le C++, si ce n'est moins...

incises · Le 14/10/2009, à 10:53

Je voudrais poser une question à comprendre comme une simple véritable question non pas comme troll stérile... : les IDE en général vous créent automatiquement un Makefile, est-ce que ce n'est pas au fond une bonne chose que de ne pas avoir, du coup, à apprendre à pratiquer toute la syntaxe Makefile (comme on est semble-t-il obligé de le faire si on travaille avec un éditeur de texte) ?
Je m'intéresse au cas général, pas à telle ou telle situation extrêmement particulière dans laquelle on pourrait avoir besoin d'un Makefile très pointu et très spécial.

Dernière modification par incises (Le 14/10/2009, à 10:55)

Keldath · Le 14/10/2009, à 11:06

Le Makefile créé par ton IDE n'est pas forcément portable. Si un contributeur/collègue veut travailler sur le même projet mais n'a pas le même outil, ça peut coincer.
Pour t'affranchir de la création d'un Makefile tu as des outils tel que les Autotools (beurk), CMake et SCons.
Bon, ça reste un outil à apprendre, mais nettement moins compliqué - je pense - que la syntaxe Makefile.

Par exemple avec CMake, tu peux créer les fichiers projet pour VisualStudio, Eclipse, un Makefile UNIX...

Dernière modification par Keldath (Le 14/10/2009, à 11:08)

Luc Hermitte · Le 14/10/2009, à 11:16

Si tu compiles la nuit via cron, ou que les gens à qui tu livres tes sources doivent compiler, en particulier sous *nix, tu n'auras pas d'IDE pour gérer ton cycle de compilation là où tu compiles, sans parler que tout le monde n'utilise pas les mêmes outils, même parmi les utilisateurs D'IDE -- je ne pense pas que l'informatique professionnelle peut-être qualifiée de "cas non général" comparé au développeur dilettante qui joue chez lui avec C::B ou Kdevelop.

Donc la présence d'un Makefile ou assimilé (autotools (qui dominent dans l'open-source nixien), cmake, (b)jam, ant, scons, .....) est requise. Ton EDI devra donc en générer un. Quelle en sera sa qualité ou sa portabilité (multi-archi/distrib/install, multi-EDI) ? Ca, je serais bien incapable de le dire.

Personnellement, j'aime bien gérer mes Makefile à la main.

Le Farfadet Spatial · Le 14/10/2009, à 11:39

Salut à tous !

incises a écrit :

[troll]
Ta réponse n'est évidemment pas inintéressante, mais ça me rappelle soudain des temps lointains : une époque où de bons esprits répugnaient à programmer en C, parce que c'était bien loin de la machine et que rien ne valait l'assembleur, où, là au moins on savait ce qu'on faisait...
[/troll]
Une des caractéristiques de l'évolution de l'informatique c'est de créer sans cesse des outils "de plus haut niveau" plus adaptés à l'être humain, on y perd sans doute parfois quelque chose mais est-ce vraiment toujours une régression ?

Me dire ça à moi, qui répète régulièrement sur ce forum : « arrêtez vos conneries avec l'assembleur » -- bon, je le dis moins directement... J'en rage, j'en désespoir, j'en vieillesse ennemie !

Cela dit, d'une part, je ne parlais pas uniquement de Vim ou Emacs, mais des outils en général. D'autre part, oui, on crée sans cesse des outils de plus haut niveau. Mais il reste cette chose indéniable : quelle que soit l'outil, il y a un temps d'apprentissage et il faut faire un effort.

Après, des EDIs, j'en ai testé pas mal et j'ai fait l'effort de les maîtriser : d'une part, cela demande à peu prêt le même apprentissage que d'apprendre Emacs ou Vim si on ne veut pas rester à la surface, d'autre part je n'ai jamais atteint la même productivité avec Eclipse (excellent au demeurant) qu'avec Emacs. Je veux bien qu'il soit plus sexy, mais ce qui m'importe c'est son efficacité.

Ne pas se tromper : ce n'est pas parce qu'on a de jolis icônes qu'on est nécessairement plus « avancé » ou plus « haut niveau » que celui qui n'en a pas.

les IDE en général vous créent automatiquement un Makefile, est-ce que ce n'est pas au fond une bonne chose que de ne pas avoir, du coup, à apprendre à pratiquer toute la syntaxe Makefile (comme on est semble-t-il obligé de le faire si on travaille avec un éditeur de texte) ?
Je m'intéresse au cas général, pas à telle ou telle situation extrêmement particulière dans laquelle on pourrait avoir besoin d'un Makefile très pointu et très spécial.

En utilisant Scons, je mets autant de temps à gérer un projet qu'en le faisant à grands coups de clics avec Eclipse. Il en va de même pour un habitué de CMake. Donc, la productivité est la même.

L'avantage : je maîtrise finement mon projet et je suis certain que le tout est portable (cf. les réponses qui t'ont déjà été faites).

À bientôt.

Le Farfadet Spatial

Totor · Le 14/10/2009, à 12:05

Le Farfadet Spatial a écrit :

Ne pas se tromper : ce n'est pas parce qu'on a de jolis icônes qu'on est nécessairement plus « avancé » ou plus « haut niveau » que celui qui n'en a pas.

Voilà quelque chose à laquelle j'ai toujours adhéré ! Cela va dans le même sens de quelque chose que j'ai toujours dis : la beauté ne fait pas la fonctionnalité ni la productivité

incises · Le 14/10/2009, à 12:35

Totor a écrit :

Le Farfadet Spatial a écrit :
Ne pas se tromper : ce n'est pas parce qu'on a de jolis icônes qu'on est nécessairement plus « avancé » ou plus « haut niveau » que celui qui n'en a pas.
Voilà quelque chose à laquelle j'ai toujours adhéré ! Cela va dans le même sens de quelque chose que j'ai toujours dis : la beauté ne fait pas la fonctionnalité ni la productivité

je suis entièrement d'accord, et je ne confonds en rien "entité de haut niveau" et icônes...

Le Farfadet Spatial a écrit :

Mais il reste cette chose indéniable : quelle que soit l'outil, il y a un temps d'apprentissage et il faut faire un effort.

avec ça, je suis 100% d'accord...

ça a l'air joli Scons (quand je dis "joli", je ne veux pas dire "tout plein d'icônes", hein), merci pour le tuyau... et merci à tous pour vos réponses...

Dernière modification par incises (Le 14/10/2009, à 12:43)

Creak · Le 14/10/2009, à 16:04

Ouais enfin c'est une discussion sans fin qui ne peut que finir en troll les discussion sur Vim-Emacs-IDE c'est un peu comme Linux-Windows ou GNOME-KDE...

Reste que, pour en revenir au sujet qu'est l'apprentissage de Vim (ou Emacs), je pense quand avoir donné un peu du mien pour apprendre. Et je constate, en toute bonne foi, que malgré mes efforts, je ne suis pas encore au niveau de base que j'espérais trouver.

Pour reprendre Luc Hermitte, si avec un IDE tu tombes de haut, pour le moment avec Vim je dois sauter très très haut!

Corrigez-moi si je me trompe, ou donnez-moi des astuces, mais voici les problèmes que je rencontre pour coder en C++ sur Linux:
- Est-ce qu'il existe un truc pour faire marcher les breakpoints directement à l'intérieur de vim?
- J'ai cru comprendre que gdb gérait mal le C++, c'est vrai? à quel point?
- C'est moi ou c'est impossible de faire marcher cmake dans Vim sans pourrir ses dossiers source?

Creak · Le 14/10/2009, à 16:16

Au fait, j'ai découvert un bug dans l'omnicompletion, quand on déclare une méthode de cette manière:

T const & get() const { return m_t; }

L'omnicompletion ne comprend pas, alors que comme ça:

const T & get() const { return m_t; }

Ca marche.

C'est dommage, j'aime bien la première façon de faire, quand il y a plein de variables à déclarer, je préfère cette écriture qui aligne les types des variables:

Tree const & tree = getTree();
int num = tree.getNumChildren();
Node const & node = tree.getNode(num - 1);

Plutôt que cette écriture qui casse l'alignement:

const Tree & tree = getTree();
int num = tree.getNumChildren();
const Node & node = tree.getNode(num - 1);

C'est encore plus flagrant avec la coloration syntaxique.

Luc Hermitte · Le 14/10/2009, à 16:35

Creak a écrit :

a- Pour reprendre Luc Hermitte, si avec un IDE tu tombes de haut, pour le moment avec Vim je dois sauter très très haut!
Corrigez-moi si je me trompe, ou donnez-moi des astuces, mais voici les problèmes que je rencontre pour coder en C++ sur Linux:
b- Est-ce qu'il existe un truc pour faire marcher les breakpoints directement à l'intérieur de vim?
c- J'ai cru comprendre que gdb gérait mal le C++, c'est vrai? à quel point?
d- C'est moi ou c'est impossible de faire marcher cmake dans Vim sans pourrir ses dossiers source?

Il y a une énorme différence. Aucun néophyte sous vim ne va s'attendre à se que cela marche du premier coup sans devoir intervenir dans la conf. Sous les IDE, on se s'attend pas à avoir à configurer quoique ce soit.

b- pyclewn

c- templates, simplification des symboles de la SL, et exploration des conteneurs standards sont des points régulièrement critiqués avec les débuggueurs sous *nix. Je soupçonne que tu trouveras les critiques à l'encontre de gdb sur la page de zerobugs0

d- Il n'y a pas le moindre rapport entre cmake, vim et tes répertoires.

A toi de maintenir ton cmake/ta chaine autotools/ton makefile/... de ton côté et où tu le désires.
Depuis vim il te faudra alors positionner les &makeprg pour compiler avec un simple appel à la commande :make.

Depuis vim, il te faudra aussi opter sur une politique d'exploration de tes fichiers. Il y a des partisans de l'approche classique windowsiennne (?) où on se ballade dans une hiérarchie de répertoires depuis vim (cf des plugins commes Nerdtree ou project), et des partisans de "je connais des morceaux du nom de mon fichier à ouvrir, à vim de me le trouver" (cf les plugins fuzzy_finder, searchinruntime, ...) (j'appartiens à cette seconde catégorie).
En parallèle de cet aspect, il y a les options propres à chaque projet ; elles peuvent concerner le style de codage (avec des plugins comme les miens), le positionnement de la chaine de compilation et ses options (comme sTLfilt), où trouver les templates propres au projet (licence et autres en-têtes). Cf des plugins comme project ou local_vimrc.

Ou alors tu veux dire que cmake va rajouter des info dans chaque répertoire, auquel cas, vim n'y est strictement pour rien. Il en serait alors de même avec des IDE -- en exploitant le format des noms des fichiers générés, on peut dire à vim de les ignorer pour la complétion automatique.

(tiens il faudra que je vois comment mes fonctions d'analyse traitent "const T&" et "T const&")

Creak · Le 14/10/2009, à 18:32

Ben en fait, pour le pb de cmake, c'est juste qu'il semble être conseillé (étant noob du cmake, je préfère prendre des pincettes) de se mettre dans un dossier à part, que l'on nomme build et de lancer cmake à partir de ce dossier.

Du coup, ça chie un peu dans la colle pour le :make de vim... Mais y a encore une zone de flou, comment vim fait pour savoir s'il faut regénérer les Makefiles? En gros, est-ce qu'il existe une commande dans Vim qui, à l'instar de :make, permettrait de lancer une commande pour générer les Makefile (i.e. "./configure" ou "cd build && cmake ..").

Je sais pas si je suis clair...

Sinon, je v regardé de plus près fuzzy_finder et searchinruntime... J'ai pris Project pour le moment car ça semble être le plugin de base pour gérer les projets. Mais bon... on voit assez vite les limites...

Luc Hermitte · Le 14/10/2009, à 18:57

Creak a écrit :

a- Du coup, ça chie un peu dans la colle pour le :make de vim... Mais y a encore une zone de flou, comment vim fait pour savoir s'il faut regénérer les Makefiles? En gros, est-ce qu'il existe une commande dans Vim qui, à l'instar de :make, permettrait de lancer une commande pour générer les Makefile (i.e. "./configure" ou "cd build && cmake ..").
b- Je sais pas si je suis clair...
c- Sinon, je v regardé de plus près fuzzy_finder et searchinruntime... J'ai pris Project pour le moment car ça semble être le plugin de base pour gérer les projets. Mais bon... on voit assez vite les limites...

c- SiR va permettre la complétion en ligne de commande uniquement + des options pour sauter d'un split ouvert à l'autre. fuzzy_finder ne repose pas sur la ligne de commande limitée (en termes de complétion) pour à la place saisir dans un buffer dédié le nom du fichier qui nous intéresse.

b- peut-être
a- Pour le configure, la chaine complète est un chouilla plus complexe quand on part de rien. Mais supposons que tu aies un script/makefile qui fasse cela, l'appel se limite à définir un :let &l:makeprg="(cd $BUILDDIR && script_qui_va_bien $*)". Chose pipeable sur STLfilt (un must have en C++ (qq soit l'éditeur/compilo)) si tu le veux -- chose que j'ai pseudo automatisée avec une approche pas encore assez idiot-proof à mon goût : BTW
script_qui_va_bien peut très bien être cmake.

Maintenant, comment le positionner ce 'makeprg' local ?
Au choix, comme je le sous-entendais, avec project ou avec local_vimrc -- ce qui permet en fonction du buffer courant de compiler un projet ou un autre, si tant est que le $BUILDDIR est repositionné dans le local_vimrc de même que la chaine exacte de compilation.

hunterkiller · Le 14/10/2009, à 19:55

c'est un sujet a troll mais je vais essayer de rester dans le droit chemin.
si tu veux faire du c limite c++ utilise emacs il incorpore tout ce qu'il faut (completion de base>> vraiment de base, svn, gbd et il customizable a mort)
sinon ya Vim mais je developperai pas car je suis un emacs user et je ne connais que les defaut de Vim et il a aussi des qualites (a ce qu'il parait XD)
sinon si tu veux faire du php/java/c++ eclipse est bien il gere tout (svn, completion de malade corrige ta syntaxe il code a ta place le man est bien)
pour du script genre sh, python, perl, ruby et autres emacs (ou Vim) sont biens

Creak · Le 14/10/2009, à 20:40

J'avoue, j'ai pas tout compris de ton dernier message Luc Hermitte
SiR vs fuzzy_finder: aucun des deux n'est parfait si je comprend bien? STLfilt, kécécé? :let &l:makeprg... koi? et le local_vimrc, je comprends l'idée, mais je sais pas si j'en aurais un jour besoin.
C'est pas de la mauvaise foi, mais ça fait bcp d'info à ingurgiter je pense.

Sinon, j'ai installé pyclewn. Bon, ça marche... c'est déjà ça!
http://creak.foolstep.com/pub/capture-gvim-pyclewn.png
[petitroll]L'infobulle, c'est du bonheur, enfin de la technologie dans tout ça![/petitroll]
Mais c'est encore une fois un peu la croix et la bannière... déjà, si je comprends bien, je ne dois plus démarrer gvim, mais pyclewn... Ou alors il faut s'y prendre autrement (un raccourci pour lancer pyclewn?)

De ce que je comprend du débugage, on ne peut breaker que sur un symbole (fonction main par exemple) et il faut se faire les raccourcis de next etc à la pogne, car je me vois mal faire :Cbreak main :Cnext :Cnext :Cnext :Cnext :Cnext :Cnext :Cnext :Cnext :Cnext pour arriver où je veux dans mon code.
Y a bien une histoire de copier .pyclewn_keys.gdb dans $HOME et de décommenter les lignes, mais ça marche pas du tout... je suppose que je fais (encore...) qqch pas comme il faut...

Dernière modification par Creak (Le 14/10/2009, à 20:50)

Luc Hermitte · Le 15/10/2009, à 01:18

Creak a écrit :

a- SiR vs fuzzy_finder: aucun des deux n'est parfait si je comprend bien?
b- STLfilt, kécécé?
c- :let &l:makeprg... koi? et le local_vimrc, je comprends l'idée, mais je sais pas si j'en aurais un jour besoin.
d- C'est pas de la mauvaise foi, mais ça fait bcp d'info à ingurgiter je pense.

a- Une question de goût et d'habitudes.

b- Un truc que tous les développeurs C++ devraient installer et utiliser -- il y a une limite au masochisme. Je suis sérieux, c'est vraiment un must-have et peu importe le compilo utilisé (GCC, dmc, VC, comeau, ...)

c- makeprg (:h makeprg) est l'option qui spécifie l'action que :make exécutera en réalité. Normalement, cela se positionne avec un set, mais cela fait rajouter quantité de backslashs, d'où l'utilisation de :let. Et quand on manipule une option de vim via :let, on accède à l'option en rajoutant une esperluette devant son nom.
Quant au l:, c'est pour que son positionnement soit limité au buffer courant. Ce qui permet d'ouvrir des fichiers de répertoires différents correspondants à des projets différents, ou même d'ouvrir d'autres types de fichiers qui sont compilés autrement. On retrouve le principe de :setlocal.

d- Je comprends bien.

Pour pyclewn, vous allez vous demander ce que je fais là. Cette sur-couche à vim exige d'utiliser gdb (voire même sur une machine linux). Or mon compilo n'est jamais GCC en ce moment, et je ne compile jamais sous linux non plus ... ^^'

Creak · Le 01/05/2010, à 14:15

hunterkiller a écrit :

c'est un sujet a troll mais je vais essayer de rester dans le droit chemin.
si tu veux faire du c limite c++ utilise emacs il incorpore tout ce qu'il faut (completion de base>> vraiment de base, svn, gbd et il customizable a mort)

Quand tu dis qu'Emacs incorpore gdb... Tu vois ça comment? Parce que j'en n'ai strictement aucune idée et j'imagine déjà une fenêtre avec la callstack et une autre avec la liste des variables que j'espionne, le tout relié directement à des breakpoint inséré dans emacs... si tu me dis que emacs sait faire ça, je quitte direct Vim!

(EPITA power! )

yohann · Le 01/05/2010, à 14:36

c'est à peut prêt ça en fait
(soit dit en passant j'ai vu des hack permettant d'intégrer gdb à vim à peu pret de la meme manière)
re en passant emacs est l'éditeur utilisée à l'épitech (petite soeur d'épita si je comprend bien...) donc tu devrait pas avoir de mal à trouver des gens pour t'aider avec emacs.

.....

....

Et qu'on aille pas dire que les vimeurs détestent les emacsiens...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#76 Le 13/10/2009, à 14:48

Re : Programmer sous linux

#77 Le 13/10/2009, à 20:24

Re : Programmer sous linux

#78 Le 13/10/2009, à 20:53

Re : Programmer sous linux

#79 Le 13/10/2009, à 23:06

Re : Programmer sous linux

#80 Le 13/10/2009, à 23:14

Re : Programmer sous linux

#81 Le 13/10/2009, à 23:20

Re : Programmer sous linux

#82 Le 13/10/2009, à 23:56

Re : Programmer sous linux

#83 Le 14/10/2009, à 01:05

Re : Programmer sous linux

#84 Le 14/10/2009, à 10:53

Re : Programmer sous linux

#85 Le 14/10/2009, à 11:06

Re : Programmer sous linux

#86 Le 14/10/2009, à 11:16

Re : Programmer sous linux

#87 Le 14/10/2009, à 11:39

Re : Programmer sous linux

#88 Le 14/10/2009, à 12:05

Re : Programmer sous linux

#89 Le 14/10/2009, à 12:35

Re : Programmer sous linux

#90 Le 14/10/2009, à 16:04

Re : Programmer sous linux

#91 Le 14/10/2009, à 16:16

Re : Programmer sous linux

#92 Le 14/10/2009, à 16:35

Re : Programmer sous linux

#93 Le 14/10/2009, à 18:32

Re : Programmer sous linux

#94 Le 14/10/2009, à 18:57

Re : Programmer sous linux

#95 Le 14/10/2009, à 19:55

Re : Programmer sous linux

#96 Le 14/10/2009, à 20:40

Re : Programmer sous linux

#97 Le 15/10/2009, à 01:18

Re : Programmer sous linux

#98 Le 01/05/2010, à 14:15

Re : Programmer sous linux

#99 Le 01/05/2010, à 14:36

Re : Programmer sous linux

Pied de page des forums