Tu peux faire du copier coller de fichiers avec Emacs. Enfin pour moi c'est typiquement le genre d'endroits ou la souris ne sert a rien.
ouais et faut que je me fade l'integralite du path du fichier a la main, donc en gros faut que je sache tres exactement ou se trouve le fichier, merci j'ai deja donne.
A comparer avec le temps de : 1/lacher le clavier, positionner la main sur la souris 2/placer le curseur au bon endroit et double cliquer 3/replacer la main dans la bonne position: entre 2 et 3 secondes.
Bon deja ton calcul, il est un peu sorti du chapeau, sans compter que quand je code je me concentre plus sur le sens du code que sur le nombre de touches frappees a la secondes.
Alors oui, c'est sur que si tu connais ton code par coeur a la ligne pres, ca va plus vite. Maintenant, je vais pas m'amuser a apprendre par coeur mes quelques megas de source pour pouvoir gagner une demi heure par jour.
Et encore, je pense pouvoir viser plus vite que tu ne tapes tes 5 caracteres, parce que ma souris, elle avance en diagonale, ce qui est pas le cas de ton caret (enfin ca depend de ce qui est vise, si c'est MaClasseAvecUnNomLong ou int i=0 ca va pas etre la meme chose).
L'autre alternative, c'est d'utiliser des raccourcis clavier qui ne necessite pas les deux mains, et accessible avec seulement la main gauche (et un informaticien gaucher est capable d'apprendre a utiliser une souris de la main droite).
C'est sur que ton ctrl x k il te force a enlever la main de la souris et voire qu'un truc aussi con qu'un coller necessite de faire le grand ecart entre controle et y ca me fait me poser des questions sur la pertinence des raccourcis. Donc c'est bien mignon de calculer la vitesse de frappe, mais ya peut etre d'autre choses a penser avant que le nombre de raccourcis que tu peux taper a la miliseconde.
Ces operations me semblent s'apparenter aux operations de redimensionnement des fenetres que les gens font tout le temps et donc sont une perte de temps. On peut bien sur splitter sa vue dans emacs; ca doit etre meme indique dans le tutorial.
T'es en train de me dire que t'as jamais besoin d'agrandir un buffer tout en gardant les autres un peu visible?
Tu fais quoi tu travailles sur un fichier a la fois?
Ou alors tu t'es paye le 30 pouces HD d'apple?
On peut bien sur splitter sa vue dans emacs; ca doit etre meme indique dans le tutorial.
et bien penser au raccoucis qui va bien. alros c'est ctrl x 0 ou ctrl x 1? merde, m'a gourre, alors ctrl x k. Tu m'etonnes que t'as pas envie de te servir de la souris si tu passes ton temps a te fader des raccourcis necessitant 2 mains et 3 doigts par main.
magine d'etre en train d'utiliser ton IDE et de te dire "tiens il me manque une fonctionnalite". C'est quand meme pratique de pouvoir la rajouter sans devoir fermer tout ce que tu faisais.
D'un autre cote, quand il me manque une feature, c'est pas un truc qui va se coder en 30 secondes, donc ca implique effectivement de fermer son IDE, de reflechir a ce que je dois faire, comment le faire, et ensuite le faire. Je sais pas comment tu bosses mais niveau methodologie bosser sur 2 trucs differents en mem temps, j'ai un doute. Maintenant si tout le monde fait ca, je ne m'etonne plus de la qualite d'emacs en tant qu'ide.
Je t'imagine bien "a tiens, il me manque le refactoring, je vais me coder ca sur le coin de la table pendant que les autres sont au cafe".
Nan, mais serieux, tu vis sur quelle planete?
C'etait pour te donner une idee de la puissance d'extensibilite de Lisp versus la puissance d'extensibilite des langages a objet.
Etendre le langage, je m'en cogne. Quand j'ai besoin d'objet, je prend un langage objet, quand j'ai besoin de fonctionnel j'utilise un langage fonctionnel.
En fait plutot que de choisir le meta language le plus extensible, je choisis le langage concret le plus adapte.
De plus le temps de developpement est aussi plus petit.
Donc arrete de penser que Lisp est un langage prehistorique a oublier en meme temps qu'Algol; c'est un langage prehistorique, mais dont un certain nombre de fonctionnalites sont toujours inegalees.
Je pense pas que lisp est prehistorique, mais qu'il a son domaine d'application, comme tout langage. Et que ce domaine n'est surement pas le developpement de features d'ide. Si c'etait le cas, tous les ide proposeraient des extensions en lisp.
Que je puisse etendre le langage en soi, c'est joli et techniquement impressionant, c'est surement tres utile et meme salutaire dans certains cas, mais dans 99% des cas, si je dois reimplementer from scratch un paradygme objet, c'est que le choix du langage initial etait particulierement mal choisi.
Le cote dessin de l'arbre peut sembler attractif mais est-ce vraiment utile?
je vais te donner un web.xml d'une web app a editer (du gros xml bien verbeux), tu vas voir s'il est pas utile le cote dessin de l'arbre, pour mettre en page correctement ton fichier, histoire de pas passer plus de temps a fouiner dans le fichier qu' a l'editer. Surtout que l'absence d'ascenceur horizontal d'emacs rend particulieremnt imbitable la lecture de fichier avec des lignes de plus de 80 caracteres.
Moi un message s'affiche dans le minibuffer, et me pose des questions auxquelles je repond en pressant sur y ou n. Bien plus pratique que de deplacer la souris sur le petit bouton "ok". Mais Emacs fait ca par defaut maintenant je crois.
ouais, et ca t'oblige a garder ton oeil en permanence sur ton mini buffer.
La pop up, elle fait pop, tu peux minimiser ton ide si t'etais sur un tache un peu longue et faire autre chose, si ton machin s'arrete en cours de route, l'icone de l'appli clignote dans la barre des taches et hop, t'es prevenu, t'as pas besoin de rester a surveiller ton truc pour rien.
Si la pop up te saoule (ie si c'est une pop ininteressante) tu lui envoye un esc dans la face et elle disparait, t'es pas oblige de viser le petit bouton. et si t'as le choix entre oui et non, tu peux faire un tab entre les boutons et entree/espace. Faut aussi apprendre a utiliser les ihm graphique.
D'apres cette etude et d'autres que j'ai pu lire, le nombre de lignes d'un gros programme Lisp est en general compris entre 1/4 et 1/20 de lignes d'un gros programme Java,
Ouais, le probleme c'est qu'implementer et valider ton serveur d'appli ou la lib dont t'as besoin, ca va te prendre 50 fois le temps que t'aurais mit a ecrire ton truc en java/c/c++/n'importe quel autre langage productif correctement fourni en middleware. Mais bon la on est clairement plus du tout dans le sujet (a savoir les ide, pas savoir si en machin on code mieux qu'en truc).
Mais on est a un moment limite par les possibilites de ces logiciels;
ouais, ben en attendant, j'ai toujours pas de reponse pour certaines de mes features dont je me sert tous les jours.
Alors pouvoir editer en mode colonne au lieu du mode ligne, c'est baleze (et ouais, je connais bien emacs, je l'ai utilise pendant toute ma scolarite), mais c'est pas ca qui me fera bosser mieux et plus vite
[^] # Re: Ce que tu cherches ...
Posté par kraman . En réponse au journal Choisir un environnement de dev pour y écrire un plugin. Évalué à -1.
ouais et faut que je me fade l'integralite du path du fichier a la main, donc en gros faut que je sache tres exactement ou se trouve le fichier, merci j'ai deja donne.
A comparer avec le temps de : 1/lacher le clavier, positionner la main sur la souris 2/placer le curseur au bon endroit et double cliquer 3/replacer la main dans la bonne position: entre 2 et 3 secondes.
Bon deja ton calcul, il est un peu sorti du chapeau, sans compter que quand je code je me concentre plus sur le sens du code que sur le nombre de touches frappees a la secondes.
Alors oui, c'est sur que si tu connais ton code par coeur a la ligne pres, ca va plus vite. Maintenant, je vais pas m'amuser a apprendre par coeur mes quelques megas de source pour pouvoir gagner une demi heure par jour.
Et encore, je pense pouvoir viser plus vite que tu ne tapes tes 5 caracteres, parce que ma souris, elle avance en diagonale, ce qui est pas le cas de ton caret (enfin ca depend de ce qui est vise, si c'est MaClasseAvecUnNomLong ou int i=0 ca va pas etre la meme chose).
L'autre alternative, c'est d'utiliser des raccourcis clavier qui ne necessite pas les deux mains, et accessible avec seulement la main gauche (et un informaticien gaucher est capable d'apprendre a utiliser une souris de la main droite).
C'est sur que ton ctrl x k il te force a enlever la main de la souris et voire qu'un truc aussi con qu'un coller necessite de faire le grand ecart entre controle et y ca me fait me poser des questions sur la pertinence des raccourcis. Donc c'est bien mignon de calculer la vitesse de frappe, mais ya peut etre d'autre choses a penser avant que le nombre de raccourcis que tu peux taper a la miliseconde.
Ces operations me semblent s'apparenter aux operations de redimensionnement des fenetres que les gens font tout le temps et donc sont une perte de temps. On peut bien sur splitter sa vue dans emacs; ca doit etre meme indique dans le tutorial.
T'es en train de me dire que t'as jamais besoin d'agrandir un buffer tout en gardant les autres un peu visible?
Tu fais quoi tu travailles sur un fichier a la fois?
Ou alors tu t'es paye le 30 pouces HD d'apple?
On peut bien sur splitter sa vue dans emacs; ca doit etre meme indique dans le tutorial.
et bien penser au raccoucis qui va bien. alros c'est ctrl x 0 ou ctrl x 1? merde, m'a gourre, alors ctrl x k. Tu m'etonnes que t'as pas envie de te servir de la souris si tu passes ton temps a te fader des raccourcis necessitant 2 mains et 3 doigts par main.
magine d'etre en train d'utiliser ton IDE et de te dire "tiens il me manque une fonctionnalite". C'est quand meme pratique de pouvoir la rajouter sans devoir fermer tout ce que tu faisais.
D'un autre cote, quand il me manque une feature, c'est pas un truc qui va se coder en 30 secondes, donc ca implique effectivement de fermer son IDE, de reflechir a ce que je dois faire, comment le faire, et ensuite le faire. Je sais pas comment tu bosses mais niveau methodologie bosser sur 2 trucs differents en mem temps, j'ai un doute. Maintenant si tout le monde fait ca, je ne m'etonne plus de la qualite d'emacs en tant qu'ide.
Je t'imagine bien "a tiens, il me manque le refactoring, je vais me coder ca sur le coin de la table pendant que les autres sont au cafe".
Nan, mais serieux, tu vis sur quelle planete?
C'etait pour te donner une idee de la puissance d'extensibilite de Lisp versus la puissance d'extensibilite des langages a objet.
Etendre le langage, je m'en cogne. Quand j'ai besoin d'objet, je prend un langage objet, quand j'ai besoin de fonctionnel j'utilise un langage fonctionnel.
En fait plutot que de choisir le meta language le plus extensible, je choisis le langage concret le plus adapte.
De plus le temps de developpement est aussi plus petit.
Donc arrete de penser que Lisp est un langage prehistorique a oublier en meme temps qu'Algol; c'est un langage prehistorique, mais dont un certain nombre de fonctionnalites sont toujours inegalees.
Je pense pas que lisp est prehistorique, mais qu'il a son domaine d'application, comme tout langage. Et que ce domaine n'est surement pas le developpement de features d'ide. Si c'etait le cas, tous les ide proposeraient des extensions en lisp.
Que je puisse etendre le langage en soi, c'est joli et techniquement impressionant, c'est surement tres utile et meme salutaire dans certains cas, mais dans 99% des cas, si je dois reimplementer from scratch un paradygme objet, c'est que le choix du langage initial etait particulierement mal choisi.
Le cote dessin de l'arbre peut sembler attractif mais est-ce vraiment utile?
je vais te donner un web.xml d'une web app a editer (du gros xml bien verbeux), tu vas voir s'il est pas utile le cote dessin de l'arbre, pour mettre en page correctement ton fichier, histoire de pas passer plus de temps a fouiner dans le fichier qu' a l'editer. Surtout que l'absence d'ascenceur horizontal d'emacs rend particulieremnt imbitable la lecture de fichier avec des lignes de plus de 80 caracteres.
Moi un message s'affiche dans le minibuffer, et me pose des questions auxquelles je repond en pressant sur y ou n. Bien plus pratique que de deplacer la souris sur le petit bouton "ok". Mais Emacs fait ca par defaut maintenant je crois.
ouais, et ca t'oblige a garder ton oeil en permanence sur ton mini buffer.
La pop up, elle fait pop, tu peux minimiser ton ide si t'etais sur un tache un peu longue et faire autre chose, si ton machin s'arrete en cours de route, l'icone de l'appli clignote dans la barre des taches et hop, t'es prevenu, t'as pas besoin de rester a surveiller ton truc pour rien.
Si la pop up te saoule (ie si c'est une pop ininteressante) tu lui envoye un esc dans la face et elle disparait, t'es pas oblige de viser le petit bouton. et si t'as le choix entre oui et non, tu peux faire un tab entre les boutons et entree/espace. Faut aussi apprendre a utiliser les ihm graphique.
D'apres cette etude et d'autres que j'ai pu lire, le nombre de lignes d'un gros programme Lisp est en general compris entre 1/4 et 1/20 de lignes d'un gros programme Java,
Ouais, le probleme c'est qu'implementer et valider ton serveur d'appli ou la lib dont t'as besoin, ca va te prendre 50 fois le temps que t'aurais mit a ecrire ton truc en java/c/c++/n'importe quel autre langage productif correctement fourni en middleware. Mais bon la on est clairement plus du tout dans le sujet (a savoir les ide, pas savoir si en machin on code mieux qu'en truc).
Mais on est a un moment limite par les possibilites de ces logiciels;
ouais, ben en attendant, j'ai toujours pas de reponse pour certaines de mes features dont je me sert tous les jours.
Alors pouvoir editer en mode colonne au lieu du mode ligne, c'est baleze (et ouais, je connais bien emacs, je l'ai utilise pendant toute ma scolarite), mais c'est pas ca qui me fera bosser mieux et plus vite