J'aimerai bien avoir un Emacs en console (donc -nw) mais qui conserve
quand même toutes les touches qui sont activables sous X (et notamment
la combinaison Ctrl-flèche pour ne pas la citer).
J'ai renoncé à comprendre comment modifier terminfo (et puis, je vois
mal comment modifier cela partout... sauf à créer _enfin_ un termcap
moderne qui émule autre chose qu'une antiquité) mais je creuse la
piste avec X...
En effet, je me connecte à 99,9% des fois avec ssh sous X vers une
machine avec le port forwarding sur X11... En *console*, mon shell
interprète sans soucis la combinaison de touche avec ctrl donc
l'environnement le permet (ENV=xterm en l'occurrence).
Mais c'est en lançant emacs -nw que les choses se gâtent... et je ne
peux pas toujours - à vrai dire presque jamais, à cause du débit -
ouvrir une fenêtre X pour Emacs.
Donc, comment dire à « emacs -nw » de se comporter comme emacs tout
court sous X ?
Ah oui, c'est « term-setup-hook » que Patrice devait vouloir utiliser, mes yeux avaient corrigé tous seuls...
Patrice Karatchentzeff
Pascal Bourguignon writes:
[... merci pour les explications ...]
Ça fait beaucoup de travail pour un bénéfice pas vraiment évident: tous les six mois, sans que je ne demande rien, et continuant à payer toujours le même abonnement, mon fournisseur ADSL me double la vitesse de ma connexion à Internet. Alors ssh -X emacs marche trés bien (c'est encore un peu lent à démarrer, mais une fois lancé, c'est tout à fait utilisable, en tout cas, ça semble rapide qu'en local sur ma vieille NeXTstation).
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai jamais au début) possesseur d'une ligne ADSL 512 et le déport de l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que limite...
Maintenant, si une combinaison de touche donnée avec l'émulateur de terminal utilisé produit une séquence de codes distincte, il est trivial de configurer emacs pour en tenir compte:
oui mais non, cf. mon message plus haut.
Je ne suis pas persuadé que réécrire un nouveau protocole basé sur un clavier 105 touches ne serait pas une perte de temps...
Avant que la planète entière soit en ADSL 20 Mbits, il y aura de l'eau qui aura coulé sous les ponts...
Ça fait beaucoup de travail pour un bénéfice pas vraiment évident:
tous les six mois, sans que je ne demande rien, et continuant à payer
toujours le même abonnement, mon fournisseur ADSL me double la vitesse
de ma connexion à Internet. Alors ssh -X emacs marche trés bien
(c'est encore un peu lent à démarrer, mais une fois lancé, c'est tout
à fait utilisable, en tout cas, ça semble rapide qu'en local sur ma
vieille NeXTstation).
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai
jamais au début) possesseur d'une ligne ADSL 512 et le déport de
l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que
limite...
Maintenant, si une combinaison de touche donnée avec l'émulateur de
terminal utilisé produit une séquence de codes distincte, il est
trivial de configurer emacs pour en tenir compte:
oui mais non, cf. mon message plus haut.
Je ne suis pas persuadé que réécrire un nouveau protocole basé sur un
clavier 105 touches ne serait pas une perte de temps...
Avant que la planète entière soit en ADSL 20 Mbits, il y aura de l'eau
qui aura coulé sous les ponts...
Ça fait beaucoup de travail pour un bénéfice pas vraiment évident: tous les six mois, sans que je ne demande rien, et continuant à payer toujours le même abonnement, mon fournisseur ADSL me double la vitesse de ma connexion à Internet. Alors ssh -X emacs marche trés bien (c'est encore un peu lent à démarrer, mais une fois lancé, c'est tout à fait utilisable, en tout cas, ça semble rapide qu'en local sur ma vieille NeXTstation).
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai jamais au début) possesseur d'une ligne ADSL 512 et le déport de l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que limite...
Maintenant, si une combinaison de touche donnée avec l'émulateur de terminal utilisé produit une séquence de codes distincte, il est trivial de configurer emacs pour en tenir compte:
oui mais non, cf. mon message plus haut.
Je ne suis pas persuadé que réécrire un nouveau protocole basé sur un clavier 105 touches ne serait pas une perte de temps...
Avant que la planète entière soit en ADSL 20 Mbits, il y aura de l'eau qui aura coulé sous les ponts...
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai jamais au début) possesseur d'une ligne ADSL 512 et le déport de l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que limite...
Ceci dit, ça, c'est plus un problème de X11 qu'un problème de bande passante. Parce que pour afficher un Emacs sans même la barre d'outil et les menus, avec un protocole un peu plus économe en bande passante, ça ne devrait pas poser de problème (Avec NX par exemple, j'ai déjà testé une session KDE relativement fluide, avec un thème assez évolué sur une connection ADSL, qui à l'époque devait être dans les 2Mb).
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai
jamais au début) possesseur d'une ligne ADSL 512 et le déport de
l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que
limite...
Ceci dit, ça, c'est plus un problème de X11 qu'un problème de bande
passante. Parce que pour afficher un Emacs sans même la barre d'outil
et les menus, avec un protocole un peu plus économe en bande passante,
ça ne devrait pas poser de problème (Avec NX par exemple, j'ai déjà
testé une session KDE relativement fluide, avec un thème assez évolué
sur une connection ADSL, qui à l'époque devait être dans les 2Mb).
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai jamais au début) possesseur d'une ligne ADSL 512 et le déport de l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que limite...
Ceci dit, ça, c'est plus un problème de X11 qu'un problème de bande passante. Parce que pour afficher un Emacs sans même la barre d'outil et les menus, avec un protocole un peu plus économe en bande passante, ça ne devrait pas poser de problème (Avec NX par exemple, j'ai déjà testé une session KDE relativement fluide, avec un thème assez évolué sur une connection ADSL, qui à l'époque devait être dans les 2Mb).
-- Matthieu
Pascal Bourguignon
Matthieu Moy writes:
Patrice Karatchentzeff writes:
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai jamais au début) possesseur d'une ligne ADSL 512 et le déport de l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que limite...
Ceci dit, ça, c'est plus un problème de X11 qu'un problème de bande passante. Parce que pour afficher un Emacs sans même la barre d'outil et les menus, avec un protocole un peu plus économe en bande passante, ça ne devrait pas poser de problème (Avec NX par exemple, j'ai déjà testé une session KDE relativement fluide, avec un thème assez évolué sur une connection ADSL, qui à l'époque devait être dans les 2Mb).
Bin évidement, faut pas compiler son emacs avec une tonne de boutons et d'icones... Autrement dit, compiler avec:
./configure --without-sound --with-x-toolkit=no --without-toolkit-scroll-bars --with-x --prefix=/usr/local make bootstrap && make && make install
NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may technically be entitled to claim that this product is ten-dimensional. However, the consumer is reminded that this confers no legal rights above and beyond those applicable to three-dimensional objects, since the seven new dimensions are "rolled up" into such a small "area" that they cannot be detected.
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai
jamais au début) possesseur d'une ligne ADSL 512 et le déport de
l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que
limite...
Ceci dit, ça, c'est plus un problème de X11 qu'un problème de bande
passante. Parce que pour afficher un Emacs sans même la barre d'outil
et les menus, avec un protocole un peu plus économe en bande passante,
ça ne devrait pas poser de problème (Avec NX par exemple, j'ai déjà
testé une session KDE relativement fluide, avec un thème assez évolué
sur une connection ADSL, qui à l'époque devait être dans les 2Mb).
Bin évidement, faut pas compiler son emacs avec une tonne de boutons
et d'icones... Autrement dit, compiler avec:
./configure --without-sound --with-x-toolkit=no
--without-toolkit-scroll-bars --with-x
--prefix=/usr/local
make bootstrap && make && make install
NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may
technically be entitled to claim that this product is
ten-dimensional. However, the consumer is reminded that this
confers no legal rights above and beyond those applicable to
three-dimensional objects, since the seven new dimensions are
"rolled up" into such a small "area" that they cannot be
detected.
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai jamais au début) possesseur d'une ligne ADSL 512 et le déport de l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que limite...
Ceci dit, ça, c'est plus un problème de X11 qu'un problème de bande passante. Parce que pour afficher un Emacs sans même la barre d'outil et les menus, avec un protocole un peu plus économe en bande passante, ça ne devrait pas poser de problème (Avec NX par exemple, j'ai déjà testé une session KDE relativement fluide, avec un thème assez évolué sur une connection ADSL, qui à l'époque devait être dans les 2Mb).
Bin évidement, faut pas compiler son emacs avec une tonne de boutons et d'icones... Autrement dit, compiler avec:
./configure --without-sound --with-x-toolkit=no --without-toolkit-scroll-bars --with-x --prefix=/usr/local make bootstrap && make && make install
NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may technically be entitled to claim that this product is ten-dimensional. However, the consumer is reminded that this confers no legal rights above and beyond those applicable to three-dimensional objects, since the seven new dimensions are "rolled up" into such a small "area" that they cannot be detected.
Erwan David
Matthieu Moy écrivait :
Patrice Karatchentzeff writes:
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai jamais au début) possesseur d'une ligne ADSL 512 et le déport de l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que limite...
Ceci dit, ça, c'est plus un problème de X11 qu'un problème de bande passante. Parce que pour afficher un Emacs sans même la barre d'outil et les menus, avec un protocole un peu plus économe en bande passante, ça ne devrait pas poser de problème (Avec NX par exemple, j'ai déjà testé une session KDE relativement fluide, avec un thème assez évolué sur une connection ADSL, qui à l'époque devait être dans les 2Mb).
Ça dépend. Si c'est un xemacs pangoisé ça devient l'enfer, parceque l'anti-aliasing des fontes est fait par le client et qu'on transfère donc des bitmaps aulieu de transférer des codes de caractères...
Vivement un système d'anti-aliasing dans le serveur (en extension donc).
-- Si vous embauchez, voici mon CV http://www.rail.eu.org/cv/cv.pdf
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai
jamais au début) possesseur d'une ligne ADSL 512 et le déport de
l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que
limite...
Ceci dit, ça, c'est plus un problème de X11 qu'un problème de bande
passante. Parce que pour afficher un Emacs sans même la barre d'outil
et les menus, avec un protocole un peu plus économe en bande passante,
ça ne devrait pas poser de problème (Avec NX par exemple, j'ai déjà
testé une session KDE relativement fluide, avec un thème assez évolué
sur une connection ADSL, qui à l'époque devait être dans les 2Mb).
Ça dépend. Si c'est un xemacs pangoisé ça devient l'enfer, parceque
l'anti-aliasing des fontes est fait par le client et qu'on transfère
donc des bitmaps aulieu de transférer des codes de caractères...
Vivement un système d'anti-aliasing dans le serveur (en extension donc).
--
Si vous embauchez, voici mon CV
http://www.rail.eu.org/cv/cv.pdf
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai jamais au début) possesseur d'une ligne ADSL 512 et le déport de l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que limite...
Ceci dit, ça, c'est plus un problème de X11 qu'un problème de bande passante. Parce que pour afficher un Emacs sans même la barre d'outil et les menus, avec un protocole un peu plus économe en bande passante, ça ne devrait pas poser de problème (Avec NX par exemple, j'ai déjà testé une session KDE relativement fluide, avec un thème assez évolué sur une connection ADSL, qui à l'époque devait être dans les 2Mb).
Ça dépend. Si c'est un xemacs pangoisé ça devient l'enfer, parceque l'anti-aliasing des fontes est fait par le client et qu'on transfère donc des bitmaps aulieu de transférer des codes de caractères...
Vivement un système d'anti-aliasing dans le serveur (en extension donc).
-- Si vous embauchez, voici mon CV http://www.rail.eu.org/cv/cv.pdf
Patrice Karatchentzeff
Pascal Bourguignon writes:
[...]
Bin évidement, faut pas compiler son emacs avec une tonne de boutons et d'icones... Autrement dit, compiler avec:
./configure --without-sound --with-x-toolkit=no --without-toolkit-scroll-bars --with-x --prefix=/usr/local make bootstrap && make && make install
À (at) Tue, 16 May 2006 15:32:31 +0200, Patrice Karatchentzeff écrivait (wrote):
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai jamais au début) possesseur d'une ligne ADSL 512 et le déport de l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que limite...
Pourquoi ne pas essayer des solutions comme EFS ou Tramp ? Emacs est en local et édite les fichiers distants. C'est rapide, fiable, sécurisé (pour Tramp) et on bénéficie de tous les avantages d'un Emacs sous X-Window sans utiliser le déport d'affichage.
Évidement, ça ne marche pas sur un minitel...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 16 May 2006 15:32:31 +0200,
Patrice Karatchentzeff <p.karatchentzeff@free.fr> écrivait (wrote):
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai
jamais au début) possesseur d'une ligne ADSL 512 et le déport de
l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que
limite...
Pourquoi ne pas essayer des solutions comme EFS ou Tramp ? Emacs est
en local et édite les fichiers distants. C'est rapide, fiable,
sécurisé (pour Tramp) et on bénéficie de tous les avantages d'un Emacs
sous X-Window sans utiliser le déport d'affichage.
Évidement, ça ne marche pas sur un minitel...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 16 May 2006 15:32:31 +0200, Patrice Karatchentzeff écrivait (wrote):
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai jamais au début) possesseur d'une ligne ADSL 512 et le déport de l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que limite...
Pourquoi ne pas essayer des solutions comme EFS ou Tramp ? Emacs est en local et édite les fichiers distants. C'est rapide, fiable, sécurisé (pour Tramp) et on bénéficie de tous les avantages d'un Emacs sous X-Window sans utiliser le déport d'affichage.
Évidement, ça ne marche pas sur un minitel...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Pascal Bourguignon
Paul Gaborit writes:
À (at) Tue, 16 May 2006 15:32:31 +0200, Patrice Karatchentzeff écrivait (wrote):
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai jamais au début) possesseur d'une ligne ADSL 512 et le déport de l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que limite...
Pourquoi ne pas essayer des solutions comme EFS ou Tramp ? Emacs est en local et édite les fichiers distants. C'est rapide, fiable, sécurisé (pour Tramp) et on bénéficie de tous les avantages d'un Emacs sous X-Window sans utiliser le déport d'affichage.
Bonne question. Je me suis mis à utiliser récement tramp, mais je le trouve lent. Faisons un petit test:
17:14:20 Je lance emacs via ssh -X à 2000 km d'ici (pings de moins de 100 ms en général, pings de 150 à 200 ms en ce moment). 17:18:48 Près à éditer. -------- 4:28
instantané C-x C-f /tmp/ la completion (TAB) se fait assez instantannément.
18:25:45 C-x C-f /tmp/d.c 18:26:02 -------- 0:17 Pour ouvrir un nouveau fichier.
instantané C-x C-f /tmp/e.c Pour ouvrir un second nouveau fichier!!!
L'édition est instantanée, comme en local, avec font-locking et tout...
17:29:10 C-x C-s 17:29:11 -------- 0:01 pour enregister un fichier de trois lignes.
---------------------------------------- Avec tramp:
17:18:00 Je lance un emacs en local. 17:18:19 Prèt à éditer. -------- 0:19
17:21:14 C-x C-f /ssh::/tmp/ 17:22:52 Find file: -------- 1:38 pour charger tramp... la completion (TAB) se fait assez rapidement.
17:23:30 C-x C-f /ssh::/tmp/a.c ; un nouveau fichieer 17:23:51 Prèt à éditer. -------- 0:21 pour ouvrir un nouveau fichier!
17:23:40 C-x C-f /ssh::/tmp/b.c ; un nouveau fichieer 17:23:52 Prèt à éditer. -------- 0:12 pour ouvrir un second nouveau fichier!
L'édition est instantanée, avec font-locking et tout...
17:28:35 C-x C-s 17:28:39 -------- 0:04 pour enregister un fichier de trois lignes. ----------------------------------------
Conclusion, c'est bien comme je disais, pour lancer une application X via le réseau, c'est lent, mais une fois lancée, c'est quasiment aussi rapide qu'en local, et ceci en passant par ssh.
Tramp, qui passe par ssh aussi est plus lent (sauf au démarrage), ce qui est normal, car il doit transférer des scripts et il initie plusieurs sessions ssh.
Par contre, un avantage de tramp, c'est en cas de réseau non fiable, comme on a les données dans un buffer local, on peut enregister le fichier en local et continuer à l'éditer en cas de coupure ou de surcharge temporaire du réseau. Donc, pour éditer un fichier au Japon ou en Amérique du Sud, je ne dis pas, tramp sera meilleur, mais pour éditer un fichier en Europe ou aux USA, X/ssh est mieux.
Évidement, ça ne marche pas sur un minitel...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may technically be entitled to claim that this product is ten-dimensional. However, the consumer is reminded that this confers no legal rights above and beyond those applicable to three-dimensional objects, since the seven new dimensions are "rolled up" into such a small "area" that they cannot be detected.
Paul Gaborit <Paul.Gaborit@invalid.invalid> writes:
À (at) Tue, 16 May 2006 15:32:31 +0200,
Patrice Karatchentzeff <p.karatchentzeff@free.fr> écrivait (wrote):
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai
jamais au début) possesseur d'une ligne ADSL 512 et le déport de
l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que
limite...
Pourquoi ne pas essayer des solutions comme EFS ou Tramp ? Emacs est
en local et édite les fichiers distants. C'est rapide, fiable,
sécurisé (pour Tramp) et on bénéficie de tous les avantages d'un Emacs
sous X-Window sans utiliser le déport d'affichage.
Bonne question.
Je me suis mis à utiliser récement tramp, mais je le trouve lent.
Faisons un petit test:
17:14:20 Je lance emacs via ssh -X à 2000 km d'ici (pings de moins de
100 ms en général, pings de 150 à 200 ms en ce moment).
17:18:48 Près à éditer.
--------
4:28
instantané C-x C-f /tmp/
la completion (TAB) se fait assez instantannément.
18:25:45 C-x C-f /tmp/d.c
18:26:02
--------
0:17 Pour ouvrir un nouveau fichier.
instantané C-x C-f /tmp/e.c
Pour ouvrir un second nouveau fichier!!!
L'édition est instantanée, comme en local, avec font-locking et tout...
17:29:10 C-x C-s
17:29:11
--------
0:01 pour enregister un fichier de trois lignes.
----------------------------------------
Avec tramp:
17:18:00 Je lance un emacs en local.
17:18:19 Prèt à éditer.
--------
0:19
17:21:14 C-x C-f /ssh:user@remote:/tmp/
17:22:52 Find file:
--------
1:38 pour charger tramp...
la completion (TAB) se fait assez rapidement.
17:23:30 C-x C-f /ssh:user@remote:/tmp/a.c ; un nouveau fichieer
17:23:51 Prèt à éditer.
--------
0:21 pour ouvrir un nouveau fichier!
17:23:40 C-x C-f /ssh:user@remote:/tmp/b.c ; un nouveau fichieer
17:23:52 Prèt à éditer.
--------
0:12 pour ouvrir un second nouveau fichier!
L'édition est instantanée, avec font-locking et tout...
17:28:35 C-x C-s
17:28:39
--------
0:04 pour enregister un fichier de trois lignes.
----------------------------------------
Conclusion, c'est bien comme je disais, pour lancer une application X
via le réseau, c'est lent, mais une fois lancée, c'est quasiment aussi
rapide qu'en local, et ceci en passant par ssh.
Tramp, qui passe par ssh aussi est plus lent (sauf au démarrage), ce
qui est normal, car il doit transférer des scripts et il initie
plusieurs sessions ssh.
Par contre, un avantage de tramp, c'est en cas de réseau non fiable,
comme on a les données dans un buffer local, on peut enregister le
fichier en local et continuer à l'éditer en cas de coupure ou de
surcharge temporaire du réseau. Donc, pour éditer un fichier au Japon
ou en Amérique du Sud, je ne dis pas, tramp sera meilleur, mais pour
éditer un fichier en Europe ou aux USA, X/ssh est mieux.
Évidement, ça ne marche pas sur un minitel...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may
technically be entitled to claim that this product is
ten-dimensional. However, the consumer is reminded that this
confers no legal rights above and beyond those applicable to
three-dimensional objects, since the seven new dimensions are
"rolled up" into such a small "area" that they cannot be
detected.
À (at) Tue, 16 May 2006 15:32:31 +0200, Patrice Karatchentzeff écrivait (wrote):
Parle pour toi ; je suis l'heureux (car je pensais que j'en n'aurai jamais au début) possesseur d'une ligne ADSL 512 et le déport de l'affichage est totalement utopique... Même à 2 Mbts, c'est plus que limite...
Pourquoi ne pas essayer des solutions comme EFS ou Tramp ? Emacs est en local et édite les fichiers distants. C'est rapide, fiable, sécurisé (pour Tramp) et on bénéficie de tous les avantages d'un Emacs sous X-Window sans utiliser le déport d'affichage.
Bonne question. Je me suis mis à utiliser récement tramp, mais je le trouve lent. Faisons un petit test:
17:14:20 Je lance emacs via ssh -X à 2000 km d'ici (pings de moins de 100 ms en général, pings de 150 à 200 ms en ce moment). 17:18:48 Près à éditer. -------- 4:28
instantané C-x C-f /tmp/ la completion (TAB) se fait assez instantannément.
18:25:45 C-x C-f /tmp/d.c 18:26:02 -------- 0:17 Pour ouvrir un nouveau fichier.
instantané C-x C-f /tmp/e.c Pour ouvrir un second nouveau fichier!!!
L'édition est instantanée, comme en local, avec font-locking et tout...
17:29:10 C-x C-s 17:29:11 -------- 0:01 pour enregister un fichier de trois lignes.
---------------------------------------- Avec tramp:
17:18:00 Je lance un emacs en local. 17:18:19 Prèt à éditer. -------- 0:19
17:21:14 C-x C-f /ssh::/tmp/ 17:22:52 Find file: -------- 1:38 pour charger tramp... la completion (TAB) se fait assez rapidement.
17:23:30 C-x C-f /ssh::/tmp/a.c ; un nouveau fichieer 17:23:51 Prèt à éditer. -------- 0:21 pour ouvrir un nouveau fichier!
17:23:40 C-x C-f /ssh::/tmp/b.c ; un nouveau fichieer 17:23:52 Prèt à éditer. -------- 0:12 pour ouvrir un second nouveau fichier!
L'édition est instantanée, avec font-locking et tout...
17:28:35 C-x C-s 17:28:39 -------- 0:04 pour enregister un fichier de trois lignes. ----------------------------------------
Conclusion, c'est bien comme je disais, pour lancer une application X via le réseau, c'est lent, mais une fois lancée, c'est quasiment aussi rapide qu'en local, et ceci en passant par ssh.
Tramp, qui passe par ssh aussi est plus lent (sauf au démarrage), ce qui est normal, car il doit transférer des scripts et il initie plusieurs sessions ssh.
Par contre, un avantage de tramp, c'est en cas de réseau non fiable, comme on a les données dans un buffer local, on peut enregister le fichier en local et continuer à l'éditer en cas de coupure ou de surcharge temporaire du réseau. Donc, pour éditer un fichier au Japon ou en Amérique du Sud, je ne dis pas, tramp sera meilleur, mais pour éditer un fichier en Europe ou aux USA, X/ssh est mieux.
Évidement, ça ne marche pas sur un minitel...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may technically be entitled to claim that this product is ten-dimensional. However, the consumer is reminded that this confers no legal rights above and beyond those applicable to three-dimensional objects, since the seven new dimensions are "rolled up" into such a small "area" that they cannot be detected.
Pascal Bourguignon
Pascal Bourguignon writes:
[...] Donc, pour éditer un fichier au Japon ou en Amérique du Sud, je ne dis pas, tramp sera meilleur, mais pour éditer un fichier en Europe ou aux USA, X/ssh est mieux.
Ah, et pour éditer un fichier sur la Lune, utiliser juste un terminal avec ed, et pour un fichier sur Mars, le faire uniquement avec des scripts sed en traitement par lot, en attendant les télécoms hyperspatiales :-)
IMPORTANT NOTICE TO PURCHASERS: The entire physical universe, including this product, may one day collapse back into an infinitesimally small space. Should another universe subsequently re-emerge, the existence of this product in that universe cannot be guaranteed.
[...] Donc, pour éditer un fichier au Japon
ou en Amérique du Sud, je ne dis pas, tramp sera meilleur, mais pour
éditer un fichier en Europe ou aux USA, X/ssh est mieux.
Ah, et pour éditer un fichier sur la Lune, utiliser juste un terminal
avec ed, et pour un fichier sur Mars, le faire uniquement avec des
scripts sed en traitement par lot, en attendant les télécoms
hyperspatiales :-)
IMPORTANT NOTICE TO PURCHASERS: The entire physical universe,
including this product, may one day collapse back into an
infinitesimally small space. Should another universe subsequently
re-emerge, the existence of this product in that universe cannot be
guaranteed.
[...] Donc, pour éditer un fichier au Japon ou en Amérique du Sud, je ne dis pas, tramp sera meilleur, mais pour éditer un fichier en Europe ou aux USA, X/ssh est mieux.
Ah, et pour éditer un fichier sur la Lune, utiliser juste un terminal avec ed, et pour un fichier sur Mars, le faire uniquement avec des scripts sed en traitement par lot, en attendant les télécoms hyperspatiales :-)
IMPORTANT NOTICE TO PURCHASERS: The entire physical universe, including this product, may one day collapse back into an infinitesimally small space. Should another universe subsequently re-emerge, the existence of this product in that universe cannot be guaranteed.
Romain Francoise
Pascal Bourguignon writes:
Tramp, qui passe par ssh aussi est plus lent (sauf au démarrage), ce qui est normal, car il doit transférer des scripts et il initie plusieurs sessions ssh.
L'inconvénient de Tramp c'est aussi que M-x grep, compile, etc ne fonctionnent pas super bien (ou pas pareil), c'est assez dérangeant quand on a l'habitude de les utiliser intensivement.
Sinon la version 2.1.x de Tramp est nettement plus rapide que la 2.0.x (incluse dans Emacs CVS) mais elle a tendance à se viander dans des environnements hétérogènes (e.g. shell local zsh et shell distant bash, etc.)
-- Romain Francoise | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter
Tramp, qui passe par ssh aussi est plus lent (sauf au démarrage), ce
qui est normal, car il doit transférer des scripts et il initie
plusieurs sessions ssh.
L'inconvénient de Tramp c'est aussi que M-x grep, compile, etc ne
fonctionnent pas super bien (ou pas pareil), c'est assez dérangeant
quand on a l'habitude de les utiliser intensivement.
Sinon la version 2.1.x de Tramp est nettement plus rapide que la 2.0.x
(incluse dans Emacs CVS) mais elle a tendance à se viander dans des
environnements hétérogènes (e.g. shell local zsh et shell distant bash,
etc.)
--
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
| ever free! --Bryan W. Procter
Tramp, qui passe par ssh aussi est plus lent (sauf au démarrage), ce qui est normal, car il doit transférer des scripts et il initie plusieurs sessions ssh.
L'inconvénient de Tramp c'est aussi que M-x grep, compile, etc ne fonctionnent pas super bien (ou pas pareil), c'est assez dérangeant quand on a l'habitude de les utiliser intensivement.
Sinon la version 2.1.x de Tramp est nettement plus rapide que la 2.0.x (incluse dans Emacs CVS) mais elle a tendance à se viander dans des environnements hétérogènes (e.g. shell local zsh et shell distant bash, etc.)
-- Romain Francoise | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter
