Non, mon probleme n'est pas de convertir un vecteur en matrice (j'ai
ecrit quelques programmes en R ;-) mais d'eviter la coercion dans les
operations 'built-in' de R. La raison est simple: j'ai parfois besoin
d'analyser plusieurs proprietees (matrice) ou une seule proprietee
(vecteur) avec le meme programme. Mais la quasi absence de polymorphisme
en R oblige certaines fonctions a avoir un nom different pour les
matrices et pour les vecteurs. De plus une coercion matrice->vecteur
perd definitivement certaines informations comme les noms des colonnes
que j'utilise beaucoup pour leur flexibilite. Comme c'est l'utilisateur
qui choisi le/les proprietes, mon progamme 'plante' s'il n'en choisi
qu'une. Idem si un calcul tombe temporairement sur une sous-matrice de
dim nx1. Je trouve deja penible les coercions table<->matrice pour qu'en
plus il ne vienne pas m'embeter sans arret avec matrice<->vecteur.
Donc meme en faisant un as.matrix apres chaque appel de fonction de R
(sic!) cela ne resoud pas le probleme. Il me faudrait un flags global
qui lui dit de ne jamais convertir une matrice en vecteur. Je trouve
d'ailleurs cette coercion implicite dangereuse surtout en l'absence de
typage.
Si tu peux repondre a mon post:
http://www-gatago.com/cgi-bin/det.pl?type=article&objectB877370
je reste sur emacs!
Non, mon probleme n'est pas de convertir un vecteur en matrice (j'ai
ecrit quelques programmes en R ;-) mais d'eviter la coercion dans les
operations 'built-in' de R. La raison est simple: j'ai parfois besoin
d'analyser plusieurs proprietees (matrice) ou une seule proprietee
(vecteur) avec le meme programme. Mais la quasi absence de polymorphisme
en R oblige certaines fonctions a avoir un nom different pour les
matrices et pour les vecteurs. De plus une coercion matrice->vecteur
perd definitivement certaines informations comme les noms des colonnes
que j'utilise beaucoup pour leur flexibilite. Comme c'est l'utilisateur
qui choisi le/les proprietes, mon progamme 'plante' s'il n'en choisi
qu'une. Idem si un calcul tombe temporairement sur une sous-matrice de
dim nx1. Je trouve deja penible les coercions table<->matrice pour qu'en
plus il ne vienne pas m'embeter sans arret avec matrice<->vecteur.
Donc meme en faisant un as.matrix apres chaque appel de fonction de R
(sic!) cela ne resoud pas le probleme. Il me faudrait un flags global
qui lui dit de ne jamais convertir une matrice en vecteur. Je trouve
d'ailleurs cette coercion implicite dangereuse surtout en l'absence de
typage.
Si tu peux repondre a mon post:
http://www-gatago.com/cgi-bin/det.pl?type=article&objectB877370
je reste sur emacs!
Non, mon probleme n'est pas de convertir un vecteur en matrice (j'ai
ecrit quelques programmes en R ;-) mais d'eviter la coercion dans les
operations 'built-in' de R. La raison est simple: j'ai parfois besoin
d'analyser plusieurs proprietees (matrice) ou une seule proprietee
(vecteur) avec le meme programme. Mais la quasi absence de polymorphisme
en R oblige certaines fonctions a avoir un nom different pour les
matrices et pour les vecteurs. De plus une coercion matrice->vecteur
perd definitivement certaines informations comme les noms des colonnes
que j'utilise beaucoup pour leur flexibilite. Comme c'est l'utilisateur
qui choisi le/les proprietes, mon progamme 'plante' s'il n'en choisi
qu'une. Idem si un calcul tombe temporairement sur une sous-matrice de
dim nx1. Je trouve deja penible les coercions table<->matrice pour qu'en
plus il ne vienne pas m'embeter sans arret avec matrice<->vecteur.
Donc meme en faisant un as.matrix apres chaque appel de fonction de R
(sic!) cela ne resoud pas le probleme. Il me faudrait un flags global
qui lui dit de ne jamais convertir une matrice en vecteur. Je trouve
d'ailleurs cette coercion implicite dangereuse surtout en l'absence de
typage.
Si tu peux repondre a mon post:
http://www-gatago.com/cgi-bin/det.pl?type=article&objectB877370
je reste sur emacs!
On Feb 22, 2:22 pm, Laurent Deniau wrote:James Kanze wrote:Fred wrote:Arcturus wrote:Je dois écrire un peu de C++, 500 lignes max.
Sous windows. Pas de graphismes, fenêtres, etc.
Entre notepad.exe (50ko) et visualC++2005 ~100Mo,
L'idéal serait un petit IDE tout mini avec juste ce qu'il faut,
... et qui soit quand même un peu plus qu'un éditeur.
Je ne sais pas si ce genre de perle existe encore,
sinon, merci de vos conseils avisés.
Emacs! Une fois qu'on s'est fait aux raccourcis, c'est d'une surprenante
efficacité. En plus, on le retrouvera à l'identique sous tout un tas d'OS.
Je préfère encore plus vim
Est-ce que tu peux approfondir ton point de vue en quelques points.
Avant tout, évidemment, c'est une question de goût personnel.
Sans doute lié aussi au fait que je me suis servi de vi pendant
longtemps avant que j'avais même accès à emacs. Reste que je
trouve aussi les commandes qui exigent plusieurs touche de la
même main (avec alt ou meta) pénible à la longue ; je finis
avec des douleurs dans les mains.
3 trucs que j'utilise souvent: le formatage des
macros (l'alignement des ) et du code,
Vim a un formattage de base du code qui est à peu près
équivalent en puissance (mais différent) de emacs. Aussi, il
supporte exceptionnellement bien le filtrage des blocs de textes
à travers des programmes externes. C'est une autre
philosophie : pour quelque chose comme « macroize », en
emacs, tu l'écris en elisp, avec vim, tu en écris un script de
shell, ou un programme C++. (C'est peut-être une autre raison
pourquoi je préfère vim : je suis nul en Lisp, tandis que
j'arrive à me débrouiller en C++ et le shell de Bourne -- awk,
sed, et leurs amis.)
Dans le temps, cette différence de philosophie donnait à vim un
autre avantage notable : il utilise beaucoup moins de
ressources (mémoire, temps CPU). Sur un processeur moderne, en
revanche, et par rapport à certains IDE, on pourrait dire
aujourd'hui que tous les deux sont des solutions « légère » ;
emacs utilise toujours beaucoup plus de ressources que vim, et
est beaucoup moins rapide, mais au moins d'avoir une machine
vieille d'une dizaine d'années, on ne le remarque pas. (Là
aussi : mes premières expériences avec emacs datent de 1992,
environ. Sur des machines avec entre 4 et 8 Mo de mémoire. Quand
le copier-coller en rectangle
et la repetition de sequence de touche (macro). Je cherche en plus a
pouvoir personnaliser le highlight et le formatage du code via une
extension du mode C/C++ (pour COS) et j'ai abandonne l'idee de me servir
de cc-mode avec emacs (et apparement peu de monde sait le personnaliser).
Tout ça existe bien en vim, mais toujours d'une façon bien
différente que sous emacs. Si tu connais bien emacs, tu sais
t'en tirer à le configurer en elisp, et tu n'es pas gené par des
commandes à plusieurs touches de la même main, je ne vois pas de
raison aujourd'hui pourquoi tu changeras. J'ai une préférence
personnel pour vim, mais je reconnais qu'emacs, c'est aussi une
sacrée bête.
On Feb 22, 2:22 pm, Laurent Deniau <laurent.den...@cern.ch> wrote:
James Kanze wrote:
Fred wrote:
Arcturus wrote:
Je dois écrire un peu de C++, 500 lignes max.
Sous windows. Pas de graphismes, fenêtres, etc.
Entre notepad.exe (50ko) et visualC++2005 ~100Mo,
L'idéal serait un petit IDE tout mini avec juste ce qu'il faut,
... et qui soit quand même un peu plus qu'un éditeur.
Je ne sais pas si ce genre de perle existe encore,
sinon, merci de vos conseils avisés.
Emacs! Une fois qu'on s'est fait aux raccourcis, c'est d'une surprenante
efficacité. En plus, on le retrouvera à l'identique sous tout un tas d'OS.
Je préfère encore plus vim
Est-ce que tu peux approfondir ton point de vue en quelques points.
Avant tout, évidemment, c'est une question de goût personnel.
Sans doute lié aussi au fait que je me suis servi de vi pendant
longtemps avant que j'avais même accès à emacs. Reste que je
trouve aussi les commandes qui exigent plusieurs touche de la
même main (avec alt ou meta) pénible à la longue ; je finis
avec des douleurs dans les mains.
3 trucs que j'utilise souvent: le formatage des
macros (l'alignement des ) et du code,
Vim a un formattage de base du code qui est à peu près
équivalent en puissance (mais différent) de emacs. Aussi, il
supporte exceptionnellement bien le filtrage des blocs de textes
à travers des programmes externes. C'est une autre
philosophie : pour quelque chose comme « macroize », en
emacs, tu l'écris en elisp, avec vim, tu en écris un script de
shell, ou un programme C++. (C'est peut-être une autre raison
pourquoi je préfère vim : je suis nul en Lisp, tandis que
j'arrive à me débrouiller en C++ et le shell de Bourne -- awk,
sed, et leurs amis.)
Dans le temps, cette différence de philosophie donnait à vim un
autre avantage notable : il utilise beaucoup moins de
ressources (mémoire, temps CPU). Sur un processeur moderne, en
revanche, et par rapport à certains IDE, on pourrait dire
aujourd'hui que tous les deux sont des solutions « légère » ;
emacs utilise toujours beaucoup plus de ressources que vim, et
est beaucoup moins rapide, mais au moins d'avoir une machine
vieille d'une dizaine d'années, on ne le remarque pas. (Là
aussi : mes premières expériences avec emacs datent de 1992,
environ. Sur des machines avec entre 4 et 8 Mo de mémoire. Quand
le copier-coller en rectangle
et la repetition de sequence de touche (macro). Je cherche en plus a
pouvoir personnaliser le highlight et le formatage du code via une
extension du mode C/C++ (pour COS) et j'ai abandonne l'idee de me servir
de cc-mode avec emacs (et apparement peu de monde sait le personnaliser).
Tout ça existe bien en vim, mais toujours d'une façon bien
différente que sous emacs. Si tu connais bien emacs, tu sais
t'en tirer à le configurer en elisp, et tu n'es pas gené par des
commandes à plusieurs touches de la même main, je ne vois pas de
raison aujourd'hui pourquoi tu changeras. J'ai une préférence
personnel pour vim, mais je reconnais qu'emacs, c'est aussi une
sacrée bête.
On Feb 22, 2:22 pm, Laurent Deniau wrote:James Kanze wrote:Fred wrote:Arcturus wrote:Je dois écrire un peu de C++, 500 lignes max.
Sous windows. Pas de graphismes, fenêtres, etc.
Entre notepad.exe (50ko) et visualC++2005 ~100Mo,
L'idéal serait un petit IDE tout mini avec juste ce qu'il faut,
... et qui soit quand même un peu plus qu'un éditeur.
Je ne sais pas si ce genre de perle existe encore,
sinon, merci de vos conseils avisés.
Emacs! Une fois qu'on s'est fait aux raccourcis, c'est d'une surprenante
efficacité. En plus, on le retrouvera à l'identique sous tout un tas d'OS.
Je préfère encore plus vim
Est-ce que tu peux approfondir ton point de vue en quelques points.
Avant tout, évidemment, c'est une question de goût personnel.
Sans doute lié aussi au fait que je me suis servi de vi pendant
longtemps avant que j'avais même accès à emacs. Reste que je
trouve aussi les commandes qui exigent plusieurs touche de la
même main (avec alt ou meta) pénible à la longue ; je finis
avec des douleurs dans les mains.
3 trucs que j'utilise souvent: le formatage des
macros (l'alignement des ) et du code,
Vim a un formattage de base du code qui est à peu près
équivalent en puissance (mais différent) de emacs. Aussi, il
supporte exceptionnellement bien le filtrage des blocs de textes
à travers des programmes externes. C'est une autre
philosophie : pour quelque chose comme « macroize », en
emacs, tu l'écris en elisp, avec vim, tu en écris un script de
shell, ou un programme C++. (C'est peut-être une autre raison
pourquoi je préfère vim : je suis nul en Lisp, tandis que
j'arrive à me débrouiller en C++ et le shell de Bourne -- awk,
sed, et leurs amis.)
Dans le temps, cette différence de philosophie donnait à vim un
autre avantage notable : il utilise beaucoup moins de
ressources (mémoire, temps CPU). Sur un processeur moderne, en
revanche, et par rapport à certains IDE, on pourrait dire
aujourd'hui que tous les deux sont des solutions « légère » ;
emacs utilise toujours beaucoup plus de ressources que vim, et
est beaucoup moins rapide, mais au moins d'avoir une machine
vieille d'une dizaine d'années, on ne le remarque pas. (Là
aussi : mes premières expériences avec emacs datent de 1992,
environ. Sur des machines avec entre 4 et 8 Mo de mémoire. Quand
le copier-coller en rectangle
et la repetition de sequence de touche (macro). Je cherche en plus a
pouvoir personnaliser le highlight et le formatage du code via une
extension du mode C/C++ (pour COS) et j'ai abandonne l'idee de me servir
de cc-mode avec emacs (et apparement peu de monde sait le personnaliser).
Tout ça existe bien en vim, mais toujours d'une façon bien
différente que sous emacs. Si tu connais bien emacs, tu sais
t'en tirer à le configurer en elisp, et tu n'es pas gené par des
commandes à plusieurs touches de la même main, je ne vois pas de
raison aujourd'hui pourquoi tu changeras. J'ai une préférence
personnel pour vim, mais je reconnais qu'emacs, c'est aussi une
sacrée bête.
Non, mon probleme n'est pas de convertir un vecteur en matrice (j'ai
ecrit quelques programmes en R ;-) mais d'eviter la coercion dans les
operations 'built-in' de R. La raison est simple: j'ai parfois besoin
d'analyser plusieurs proprietees (matrice) ou une seule proprietee
(vecteur) avec le meme programme. Mais la quasi absence de
polymorphisme en R oblige certaines fonctions a avoir un nom different
pour les matrices et pour les vecteurs. De plus une coercion
matrice->vecteur perd definitivement certaines informations comme les
noms des colonnes que j'utilise beaucoup pour leur flexibilite. Comme
c'est l'utilisateur qui choisi le/les proprietes, mon progamme
'plante' s'il n'en choisi qu'une. Idem si un calcul tombe
temporairement sur une sous-matrice de dim nx1. Je trouve deja penible
les coercions table<->matrice pour qu'en plus il ne vienne pas
m'embeter sans arret avec matrice<->vecteur.
Donc meme en faisant un as.matrix apres chaque appel de fonction de R
(sic!) cela ne resoud pas le probleme. Il me faudrait un flags global
qui lui dit de ne jamais convertir une matrice en vecteur. Je trouve
d'ailleurs cette coercion implicite dangereuse surtout en l'absence de
typage.
Je te propose un truc "affreux" (mais je suis devenu un peu pragmatique)
rajouter une ligne ou colonne bidon.
Qu'est ce que ça coûte ?
(et en plus tu trouveras sûrement qq chose à caser dedans)
Non, mon probleme n'est pas de convertir un vecteur en matrice (j'ai
ecrit quelques programmes en R ;-) mais d'eviter la coercion dans les
operations 'built-in' de R. La raison est simple: j'ai parfois besoin
d'analyser plusieurs proprietees (matrice) ou une seule proprietee
(vecteur) avec le meme programme. Mais la quasi absence de
polymorphisme en R oblige certaines fonctions a avoir un nom different
pour les matrices et pour les vecteurs. De plus une coercion
matrice->vecteur perd definitivement certaines informations comme les
noms des colonnes que j'utilise beaucoup pour leur flexibilite. Comme
c'est l'utilisateur qui choisi le/les proprietes, mon progamme
'plante' s'il n'en choisi qu'une. Idem si un calcul tombe
temporairement sur une sous-matrice de dim nx1. Je trouve deja penible
les coercions table<->matrice pour qu'en plus il ne vienne pas
m'embeter sans arret avec matrice<->vecteur.
Donc meme en faisant un as.matrix apres chaque appel de fonction de R
(sic!) cela ne resoud pas le probleme. Il me faudrait un flags global
qui lui dit de ne jamais convertir une matrice en vecteur. Je trouve
d'ailleurs cette coercion implicite dangereuse surtout en l'absence de
typage.
Je te propose un truc "affreux" (mais je suis devenu un peu pragmatique)
rajouter une ligne ou colonne bidon.
Qu'est ce que ça coûte ?
(et en plus tu trouveras sûrement qq chose à caser dedans)
Non, mon probleme n'est pas de convertir un vecteur en matrice (j'ai
ecrit quelques programmes en R ;-) mais d'eviter la coercion dans les
operations 'built-in' de R. La raison est simple: j'ai parfois besoin
d'analyser plusieurs proprietees (matrice) ou une seule proprietee
(vecteur) avec le meme programme. Mais la quasi absence de
polymorphisme en R oblige certaines fonctions a avoir un nom different
pour les matrices et pour les vecteurs. De plus une coercion
matrice->vecteur perd definitivement certaines informations comme les
noms des colonnes que j'utilise beaucoup pour leur flexibilite. Comme
c'est l'utilisateur qui choisi le/les proprietes, mon progamme
'plante' s'il n'en choisi qu'une. Idem si un calcul tombe
temporairement sur une sous-matrice de dim nx1. Je trouve deja penible
les coercions table<->matrice pour qu'en plus il ne vienne pas
m'embeter sans arret avec matrice<->vecteur.
Donc meme en faisant un as.matrix apres chaque appel de fonction de R
(sic!) cela ne resoud pas le probleme. Il me faudrait un flags global
qui lui dit de ne jamais convertir une matrice en vecteur. Je trouve
d'ailleurs cette coercion implicite dangereuse surtout en l'absence de
typage.
Je te propose un truc "affreux" (mais je suis devenu un peu pragmatique)
rajouter une ligne ou colonne bidon.
Qu'est ce que ça coûte ?
(et en plus tu trouveras sûrement qq chose à caser dedans)
James Kanze wrote:On Feb 22, 2:22 pm, Laurent Deniau wrote:James Kanze wrote:Fred wrote:Arcturus wrote:Je dois écrire un peu de C++, 500 lignes max.
Sous windows. Pas de graphismes, fenêtres, etc.
Entre notepad.exe (50ko) et visualC++2005 ~100Mo,
L'idéal serait un petit IDE tout mini avec juste ce qu'il faut,
... et qui soit quand même un peu plus qu'un éditeur.
Je ne sais pas si ce genre de perle existe encore,
sinon, merci de vos conseils avisés.
Emacs! Une fois qu'on s'est fait aux raccourcis, c'est d'une surpren ante
efficacité. En plus, on le retrouvera à l'identique sous tout un tas d'OS.
Je préfère encore plus vim
Est-ce que tu peux approfondir ton point de vue en quelques points.
Avant tout, évidemment, c'est une question de goût personnel.
Sans doute lié aussi au fait que je me suis servi de vi pendant
longtemps avant que j'avais même accès à emacs. Reste que je
trouve aussi les commandes qui exigent plusieurs touche de la
même main (avec alt ou meta) pénible à la longue ; je finis
avec des douleurs dans les mains.
idem pour la main gauche (trop de C-X-s par exemple).
James Kanze wrote:
On Feb 22, 2:22 pm, Laurent Deniau <laurent.den...@cern.ch> wrote:
James Kanze wrote:
Fred wrote:
Arcturus wrote:
Je dois écrire un peu de C++, 500 lignes max.
Sous windows. Pas de graphismes, fenêtres, etc.
Entre notepad.exe (50ko) et visualC++2005 ~100Mo,
L'idéal serait un petit IDE tout mini avec juste ce qu'il faut,
... et qui soit quand même un peu plus qu'un éditeur.
Je ne sais pas si ce genre de perle existe encore,
sinon, merci de vos conseils avisés.
Emacs! Une fois qu'on s'est fait aux raccourcis, c'est d'une surpren ante
efficacité. En plus, on le retrouvera à l'identique sous tout un tas d'OS.
Je préfère encore plus vim
Est-ce que tu peux approfondir ton point de vue en quelques points.
Avant tout, évidemment, c'est une question de goût personnel.
Sans doute lié aussi au fait que je me suis servi de vi pendant
longtemps avant que j'avais même accès à emacs. Reste que je
trouve aussi les commandes qui exigent plusieurs touche de la
même main (avec alt ou meta) pénible à la longue ; je finis
avec des douleurs dans les mains.
idem pour la main gauche (trop de C-X-s par exemple).
James Kanze wrote:On Feb 22, 2:22 pm, Laurent Deniau wrote:James Kanze wrote:Fred wrote:Arcturus wrote:Je dois écrire un peu de C++, 500 lignes max.
Sous windows. Pas de graphismes, fenêtres, etc.
Entre notepad.exe (50ko) et visualC++2005 ~100Mo,
L'idéal serait un petit IDE tout mini avec juste ce qu'il faut,
... et qui soit quand même un peu plus qu'un éditeur.
Je ne sais pas si ce genre de perle existe encore,
sinon, merci de vos conseils avisés.
Emacs! Une fois qu'on s'est fait aux raccourcis, c'est d'une surpren ante
efficacité. En plus, on le retrouvera à l'identique sous tout un tas d'OS.
Je préfère encore plus vim
Est-ce que tu peux approfondir ton point de vue en quelques points.
Avant tout, évidemment, c'est une question de goût personnel.
Sans doute lié aussi au fait que je me suis servi de vi pendant
longtemps avant que j'avais même accès à emacs. Reste que je
trouve aussi les commandes qui exigent plusieurs touche de la
même main (avec alt ou meta) pénible à la longue ; je finis
avec des douleurs dans les mains.
idem pour la main gauche (trop de C-X-s par exemple).
je suis nul en Lisp,
je suis nul en Lisp,
je suis nul en Lisp,
On Feb 22, 2:22 pm, Laurent Deniau wrote:
C'est une autre
philosophie : pour quelque chose comme « macroize », en
emacs, tu l'écris en elisp, avec vim, tu en écris un script de
shell, ou un programme C++. (C'est peut-être une autre raison
pourquoi je préfère vim : je suis nul en Lisp, tandis que
j'arrive à me débrouiller en C++ et le shell de Bourne -- awk,
sed, et leurs amis.)
le copier-coller en rectangle
et la repetition de sequence de touche (macro).
Je connais emacs et vim ... mais plus pratiqué depuis ... houuuuuu la l a !
Ca existe donc encore ? mais ça bouge ? c'est vraiment vivant ?
On Feb 22, 2:22 pm, Laurent Deniau <laurent.den...@cern.ch> wrote:
C'est une autre
philosophie : pour quelque chose comme « macroize », en
emacs, tu l'écris en elisp, avec vim, tu en écris un script de
shell, ou un programme C++. (C'est peut-être une autre raison
pourquoi je préfère vim : je suis nul en Lisp, tandis que
j'arrive à me débrouiller en C++ et le shell de Bourne -- awk,
sed, et leurs amis.)
le copier-coller en rectangle
et la repetition de sequence de touche (macro).
Je connais emacs et vim ... mais plus pratiqué depuis ... houuuuuu la l a !
Ca existe donc encore ? mais ça bouge ? c'est vraiment vivant ?
On Feb 22, 2:22 pm, Laurent Deniau wrote:
C'est une autre
philosophie : pour quelque chose comme « macroize », en
emacs, tu l'écris en elisp, avec vim, tu en écris un script de
shell, ou un programme C++. (C'est peut-être une autre raison
pourquoi je préfère vim : je suis nul en Lisp, tandis que
j'arrive à me débrouiller en C++ et le shell de Bourne -- awk,
sed, et leurs amis.)
le copier-coller en rectangle
et la repetition de sequence de touche (macro).
Je connais emacs et vim ... mais plus pratiqué depuis ... houuuuuu la l a !
Ca existe donc encore ? mais ça bouge ? c'est vraiment vivant ?
Emacs, je ne sais pas, mais vim à fond. On a eu plein de nouveautés
sympas
dans vim7, du coup des plugins qui exploitent ces nouveautés
fleurissent.
Accessoirement, Bram a donné une conférence sur 7 bonnes habitudes de
l'édition de texte:
<http://anildigital.blogspot.com/2007/02/video-of-bram-presentation-
google_22.html>
Emacs, je ne sais pas, mais vim à fond. On a eu plein de nouveautés
sympas
dans vim7, du coup des plugins qui exploitent ces nouveautés
fleurissent.
Accessoirement, Bram a donné une conférence sur 7 bonnes habitudes de
l'édition de texte:
<http://anildigital.blogspot.com/2007/02/video-of-bram-presentation-
google_22.html>
Emacs, je ne sais pas, mais vim à fond. On a eu plein de nouveautés
sympas
dans vim7, du coup des plugins qui exploitent ces nouveautés
fleurissent.
Accessoirement, Bram a donné une conférence sur 7 bonnes habitudes de
l'édition de texte:
<http://anildigital.blogspot.com/2007/02/video-of-bram-presentation-
google_22.html>
Je viens de regarder la partie conférence de la vidéo (pas les
questions/réponses), et je dois avouer que j'ai été un peu surpris. Je
pensais que vim était bourré de fonctionnalités avancées.
La quasi totalité des choses présentées, je les utilise réguliè rement
depuis 97 avec MsDev. Certes, certaines ne marchaient pas à 100%, mais
d'après les commentaires, dans vim non plus. Avec la version actuelle de
MsDev, ça commence à marcher sans trop de failles pour le C++.
Quelques exemples pour être concret :
- Pour chercher la définition d'une variable ou d'un type, une touche
suffit, même en cas d'homonymie. Dans la présentation, j'ai vu un sim ple
grep.
- La complétion de code basée sur le contexte marche pas trop mal, je ne
connais pas la qualité de celle de vim. Est-ce que par exemple si on
tape toto-> avec toto un boost::shared_ptr<T> il nous présente les
fonctions membre de T par exemple ? Une fois la fonction tapée,
affiche-t'il les différents paramètres, en permettant de basculer d'u ne
surchage à l'autre pendant qu'on les tappe ?
Et si en plus on parle d'un langage où il y a eu un gros investissement,
comme le C#, le niveau des fonctionnalités avancées me semble un nive au
d'abstraction au dessus de ce qui a été présenté. Par exemple, re nommer
une variable ne se fait pas par recherche textuelle, est est donc
immédiat et sans erreur (pour peu que le code soit compilable, sinon,
unrisque d'erreur subsiste, même si ça ne m'est pas arrivé en plus d'un
an). Le cutting-edge de cet éditeur, ce sont les fonctionnalités de
refactoring (j'adore le extract method, par exemple), pas la complétion
de code.
Il est évident que vim garde des avantages certains en terme de
portabilité, que toutes les commandes sont probablement plus aisément
accessibles en mode clavier pur, peut être en terme de programmabilit é,
je n'ai pas trop regardé ce que valait MsDev. Par contre, suite à cet te
présentation, en terme de fonctionnalités, j'ai des doutes.
--
Loïc qui ne veut pas entrer dans un troll, mais espère être resté sur
des faits.
Je viens de regarder la partie conférence de la vidéo (pas les
questions/réponses), et je dois avouer que j'ai été un peu surpris. Je
pensais que vim était bourré de fonctionnalités avancées.
La quasi totalité des choses présentées, je les utilise réguliè rement
depuis 97 avec MsDev. Certes, certaines ne marchaient pas à 100%, mais
d'après les commentaires, dans vim non plus. Avec la version actuelle de
MsDev, ça commence à marcher sans trop de failles pour le C++.
Quelques exemples pour être concret :
- Pour chercher la définition d'une variable ou d'un type, une touche
suffit, même en cas d'homonymie. Dans la présentation, j'ai vu un sim ple
grep.
- La complétion de code basée sur le contexte marche pas trop mal, je ne
connais pas la qualité de celle de vim. Est-ce que par exemple si on
tape toto-> avec toto un boost::shared_ptr<T> il nous présente les
fonctions membre de T par exemple ? Une fois la fonction tapée,
affiche-t'il les différents paramètres, en permettant de basculer d'u ne
surchage à l'autre pendant qu'on les tappe ?
Et si en plus on parle d'un langage où il y a eu un gros investissement,
comme le C#, le niveau des fonctionnalités avancées me semble un nive au
d'abstraction au dessus de ce qui a été présenté. Par exemple, re nommer
une variable ne se fait pas par recherche textuelle, est est donc
immédiat et sans erreur (pour peu que le code soit compilable, sinon,
unrisque d'erreur subsiste, même si ça ne m'est pas arrivé en plus d'un
an). Le cutting-edge de cet éditeur, ce sont les fonctionnalités de
refactoring (j'adore le extract method, par exemple), pas la complétion
de code.
Il est évident que vim garde des avantages certains en terme de
portabilité, que toutes les commandes sont probablement plus aisément
accessibles en mode clavier pur, peut être en terme de programmabilit é,
je n'ai pas trop regardé ce que valait MsDev. Par contre, suite à cet te
présentation, en terme de fonctionnalités, j'ai des doutes.
--
Loïc qui ne veut pas entrer dans un troll, mais espère être resté sur
des faits.
Je viens de regarder la partie conférence de la vidéo (pas les
questions/réponses), et je dois avouer que j'ai été un peu surpris. Je
pensais que vim était bourré de fonctionnalités avancées.
La quasi totalité des choses présentées, je les utilise réguliè rement
depuis 97 avec MsDev. Certes, certaines ne marchaient pas à 100%, mais
d'après les commentaires, dans vim non plus. Avec la version actuelle de
MsDev, ça commence à marcher sans trop de failles pour le C++.
Quelques exemples pour être concret :
- Pour chercher la définition d'une variable ou d'un type, une touche
suffit, même en cas d'homonymie. Dans la présentation, j'ai vu un sim ple
grep.
- La complétion de code basée sur le contexte marche pas trop mal, je ne
connais pas la qualité de celle de vim. Est-ce que par exemple si on
tape toto-> avec toto un boost::shared_ptr<T> il nous présente les
fonctions membre de T par exemple ? Une fois la fonction tapée,
affiche-t'il les différents paramètres, en permettant de basculer d'u ne
surchage à l'autre pendant qu'on les tappe ?
Et si en plus on parle d'un langage où il y a eu un gros investissement,
comme le C#, le niveau des fonctionnalités avancées me semble un nive au
d'abstraction au dessus de ce qui a été présenté. Par exemple, re nommer
une variable ne se fait pas par recherche textuelle, est est donc
immédiat et sans erreur (pour peu que le code soit compilable, sinon,
unrisque d'erreur subsiste, même si ça ne m'est pas arrivé en plus d'un
an). Le cutting-edge de cet éditeur, ce sont les fonctionnalités de
refactoring (j'adore le extract method, par exemple), pas la complétion
de code.
Il est évident que vim garde des avantages certains en terme de
portabilité, que toutes les commandes sont probablement plus aisément
accessibles en mode clavier pur, peut être en terme de programmabilit é,
je n'ai pas trop regardé ce que valait MsDev. Par contre, suite à cet te
présentation, en terme de fonctionnalités, j'ai des doutes.
--
Loïc qui ne veut pas entrer dans un troll, mais espère être resté sur
des faits.
Bonjour,
Je dois écrire un peu de C++, 500 lignes max.
Sous windows. Pas de graphismes, fenêtres, etc.
Entre notepad.exe (50ko) et visualC++2005 ~100Mo,
L'idéal serait un petit IDE tout mini avec juste ce qu'il faut,
... et qui soit quand même un peu plus qu'un éditeur.
Je ne sais pas si ce genre de perle existe encore,
sinon, merci de vos conseils avisés.
Salut,
Bonjour,
Je dois écrire un peu de C++, 500 lignes max.
Sous windows. Pas de graphismes, fenêtres, etc.
Entre notepad.exe (50ko) et visualC++2005 ~100Mo,
L'idéal serait un petit IDE tout mini avec juste ce qu'il faut,
... et qui soit quand même un peu plus qu'un éditeur.
Je ne sais pas si ce genre de perle existe encore,
sinon, merci de vos conseils avisés.
Salut,
Bonjour,
Je dois écrire un peu de C++, 500 lignes max.
Sous windows. Pas de graphismes, fenêtres, etc.
Entre notepad.exe (50ko) et visualC++2005 ~100Mo,
L'idéal serait un petit IDE tout mini avec juste ce qu'il faut,
... et qui soit quand même un peu plus qu'un éditeur.
Je ne sais pas si ce genre de perle existe encore,
sinon, merci de vos conseils avisés.
Salut,
Salut,
Peut etre vous a-t-on deja renseigne, mais perso, je vous conseil
"NotePad++". C'est un IDE ultra compacte qui permet de programmer aussi
bien du HTML que du C ou C++... entre autre.
a bientot.
Salut,
Peut etre vous a-t-on deja renseigne, mais perso, je vous conseil
"NotePad++". C'est un IDE ultra compacte qui permet de programmer aussi
bien du HTML que du C ou C++... entre autre.
a bientot.
Salut,
Peut etre vous a-t-on deja renseigne, mais perso, je vous conseil
"NotePad++". C'est un IDE ultra compacte qui permet de programmer aussi
bien du HTML que du C ou C++... entre autre.
a bientot.
