Bloquer le curseur sur le prompt dans le shell 'comint'
19 réponses
Nicolas Pernetty
Bonjour,
Je souhaiterais pouvoir envoyer automatiquement le curseur derrière le
prompt lorsque je passe dans un buffer comint (je ne sais pas si c'est
le bon terme, mais bon ce sont les buffers spéciaux, type shell,
python-shell ou matlab-shell) et surtout qu'il y reste et que l'on ne
puisse pas se balader à loisirs dans la fenêtre et pouvoir écrire du
texte n'importe où.
En bref, j'aimerais que le buffer se comporte comme un xterm normal :
On peut selectionner du texte partout à la souris mais le curseur reste
bloqué au niveau du shell.
Est-ce que cela est possible avec Xemacs 21.4.17 ? Si oui comment
faire ?
Le 3 novembre 2005 à 21:11, Nicolas Pernetty vraute :
Est-ce que cela est possible avec Xemacs 21.4.17 ? Si oui comment faire ?
Je ne sais pas mais je vais essayer de chercher : ça m'intéresse aussi et c'est vrai que dans l'eshelle c'est casse-pieds :)
-- Sébastien Kirche
Leopold BAILLY
Nicolas Pernetty writes:
Bonjour,
Je souhaiterais pouvoir envoyer automatiquement le curseur derrière le prompt lorsque je passe dans un buffer comint (je ne sais pas si c'est le bon terme, mais bon ce sont les buffers spéciaux, type shell, python-shell ou matlab-shell) et surtout qu'il y reste et que l'on ne puisse pas se balader à loisirs dans la fenêtre et pouvoir écrire du texte n'importe où.
En bref, j'aimerais que le buffer se comporte comme un xterm normal : On peut selectionner du texte partout à la souris mais le curseur reste bloqué au niveau du shell.
Je ne vois pas trop l'intérêt, M-> te ramène instantanément sur le prompt.
Désolé de répondre à côté, mais Emacs est un avant tout un éd iteur de texte ; l'intérêt d'ouvrir un shell dans emacs est de justement pouvoir se ballader dans tout le buffer.
Si tu veux un vrai xterm, il y a ... xterm.
-- Léo.
Nicolas Pernetty <nicopernetty@nowhere.fr> writes:
Bonjour,
Je souhaiterais pouvoir envoyer automatiquement le curseur derrière le
prompt lorsque je passe dans un buffer comint (je ne sais pas si c'est
le bon terme, mais bon ce sont les buffers spéciaux, type shell,
python-shell ou matlab-shell) et surtout qu'il y reste et que l'on ne
puisse pas se balader à loisirs dans la fenêtre et pouvoir écrire du
texte n'importe où.
En bref, j'aimerais que le buffer se comporte comme un xterm normal :
On peut selectionner du texte partout à la souris mais le curseur reste
bloqué au niveau du shell.
Je ne vois pas trop l'intérêt, M-> te ramène instantanément sur le prompt.
Désolé de répondre à côté, mais Emacs est un avant tout un éd iteur de
texte ; l'intérêt d'ouvrir un shell dans emacs est de justement pouvoir se
ballader dans tout le buffer.
Je souhaiterais pouvoir envoyer automatiquement le curseur derrière le prompt lorsque je passe dans un buffer comint (je ne sais pas si c'est le bon terme, mais bon ce sont les buffers spéciaux, type shell, python-shell ou matlab-shell) et surtout qu'il y reste et que l'on ne puisse pas se balader à loisirs dans la fenêtre et pouvoir écrire du texte n'importe où.
En bref, j'aimerais que le buffer se comporte comme un xterm normal : On peut selectionner du texte partout à la souris mais le curseur reste bloqué au niveau du shell.
Je ne vois pas trop l'intérêt, M-> te ramène instantanément sur le prompt.
Désolé de répondre à côté, mais Emacs est un avant tout un éd iteur de texte ; l'intérêt d'ouvrir un shell dans emacs est de justement pouvoir se ballader dans tout le buffer.
Si tu veux un vrai xterm, il y a ... xterm.
-- Léo.
Nicolas Pernetty
On Thu, 03 Nov 2005 21:37:59 +0100, Leopold BAILLY wrote :
> > Je souhaiterais pouvoir envoyer automatiquement le curseur derrière > le prompt lorsque je passe dans un buffer comint (je ne sais pas si > c'est le bon terme, mais bon ce sont les buffers spéciaux, type > shell, python-shell ou matlab-shell) et surtout qu'il y reste et > que l'on ne puisse pas se balader à loisirs dans la fenêtre et > pouvoir écrire du texte n'importe où. > > En bref, j'aimerais que le buffer se comporte comme un xterm > normal : On peut selectionner du texte partout à la souris mais le > curseur reste bloqué au niveau du shell.
Je ne vois pas trop l'intérêt, M-> te ramène instantanément sur le prompt.
Désolé de répondre à côté, mais Emacs est un avant tout un éditeur de texte ; l'intérêt d'ouvrir un shell dans emacs est de justement pouvoir se ballader dans tout le buffer.
Si tu veux un vrai xterm, il y a ... xterm.
L'intérêt de (X)emacs, c'est de pouvoir avoir une intégration entre l'édition de texte/code et l'interpréteur (shell) derrière. Si tu ne codes pas dans un langage interprété comme Python ou Matlab, c'est sûr que l'intérêt est moins immédiat par rapport à ouvrir un xterm à côté.
Par contre je ne vois pas trop bien où est l'intérêt de pouvoir 'se balader' dans un buffer type shell ? Est-ce que c'est uniquement pour pouvoir sélectionner au clavier du texte ? Car l'utilisation de l'historique des commandes et de la souris pour sélectionner du texte couvre à mon avis déjà beaucoup de besoins...
On Thu, 03 Nov 2005 21:37:59 +0100, Leopold BAILLY
<leo.bailly@infonie.fr> wrote :
>
> Je souhaiterais pouvoir envoyer automatiquement le curseur derrière
> le prompt lorsque je passe dans un buffer comint (je ne sais pas si
> c'est le bon terme, mais bon ce sont les buffers spéciaux, type
> shell, python-shell ou matlab-shell) et surtout qu'il y reste et
> que l'on ne puisse pas se balader à loisirs dans la fenêtre et
> pouvoir écrire du texte n'importe où.
>
> En bref, j'aimerais que le buffer se comporte comme un xterm
> normal : On peut selectionner du texte partout à la souris mais le
> curseur reste bloqué au niveau du shell.
Je ne vois pas trop l'intérêt, M-> te ramène instantanément sur le
prompt.
Désolé de répondre à côté, mais Emacs est un avant tout un éditeur de
texte ; l'intérêt d'ouvrir un shell dans emacs est de justement
pouvoir se ballader dans tout le buffer.
Si tu veux un vrai xterm, il y a ... xterm.
L'intérêt de (X)emacs, c'est de pouvoir avoir une intégration entre
l'édition de texte/code et l'interpréteur (shell) derrière.
Si tu ne codes pas dans un langage interprété comme Python ou Matlab,
c'est sûr que l'intérêt est moins immédiat par rapport à ouvrir un
xterm à côté.
Par contre je ne vois pas trop bien où est l'intérêt de pouvoir 'se
balader' dans un buffer type shell ?
Est-ce que c'est uniquement pour pouvoir sélectionner au clavier du
texte ?
Car l'utilisation de l'historique des commandes et de la souris pour
sélectionner du texte couvre à mon avis déjà beaucoup de besoins...
On Thu, 03 Nov 2005 21:37:59 +0100, Leopold BAILLY wrote :
> > Je souhaiterais pouvoir envoyer automatiquement le curseur derrière > le prompt lorsque je passe dans un buffer comint (je ne sais pas si > c'est le bon terme, mais bon ce sont les buffers spéciaux, type > shell, python-shell ou matlab-shell) et surtout qu'il y reste et > que l'on ne puisse pas se balader à loisirs dans la fenêtre et > pouvoir écrire du texte n'importe où. > > En bref, j'aimerais que le buffer se comporte comme un xterm > normal : On peut selectionner du texte partout à la souris mais le > curseur reste bloqué au niveau du shell.
Je ne vois pas trop l'intérêt, M-> te ramène instantanément sur le prompt.
Désolé de répondre à côté, mais Emacs est un avant tout un éditeur de texte ; l'intérêt d'ouvrir un shell dans emacs est de justement pouvoir se ballader dans tout le buffer.
Si tu veux un vrai xterm, il y a ... xterm.
L'intérêt de (X)emacs, c'est de pouvoir avoir une intégration entre l'édition de texte/code et l'interpréteur (shell) derrière. Si tu ne codes pas dans un langage interprété comme Python ou Matlab, c'est sûr que l'intérêt est moins immédiat par rapport à ouvrir un xterm à côté.
Par contre je ne vois pas trop bien où est l'intérêt de pouvoir 'se balader' dans un buffer type shell ? Est-ce que c'est uniquement pour pouvoir sélectionner au clavier du texte ? Car l'utilisation de l'historique des commandes et de la souris pour sélectionner du texte couvre à mon avis déjà beaucoup de besoins...
Nicolas Pernetty
On Thu, 03 Nov 2005 21:33:23 +0100, Sébastien Kirche wrote :
Le 3 novembre 2005 à 21:11, Nicolas Pernetty vraute :
> Est-ce que cela est possible avec Xemacs 21.4.17 ? Si oui comment > faire ?
Je ne sais pas mais je vais essayer de chercher : ça m'intéresse aussi et c'est vrai que dans l'eshelle c'est casse-pieds :)
Merci ! Je continue à chercher de mon côté mais j'ai un peu de mal à trouver la bonne requête dans Google...
Bizarrement au boulot avec Matlab et matlab-mode.el, ça marche comme je voudrais : dès que l'on sélectionne le buffer on se retrouve derrière le prompt et impossible d'en sortir. Par contre avec le shell python et le shell unix standard, ça ne marche pas comme ça...
Si je trouve, je poste la solution ici !
On Thu, 03 Nov 2005 21:33:23 +0100, Sébastien Kirche
<sebastien.kirche.no@spam.free.fr.invalid> wrote :
Le 3 novembre 2005 à 21:11, Nicolas Pernetty vraute :
> Est-ce que cela est possible avec Xemacs 21.4.17 ? Si oui comment
> faire ?
Je ne sais pas mais je vais essayer de chercher : ça m'intéresse aussi
et c'est vrai que dans l'eshelle c'est casse-pieds :)
Merci ! Je continue à chercher de mon côté mais j'ai un peu de mal à
trouver la bonne requête dans Google...
Bizarrement au boulot avec Matlab et matlab-mode.el, ça marche comme je
voudrais : dès que l'on sélectionne le buffer on se retrouve derrière
le prompt et impossible d'en sortir.
Par contre avec le shell python et le shell unix standard, ça ne marche
pas comme ça...
On Thu, 03 Nov 2005 21:33:23 +0100, Sébastien Kirche wrote :
Le 3 novembre 2005 à 21:11, Nicolas Pernetty vraute :
> Est-ce que cela est possible avec Xemacs 21.4.17 ? Si oui comment > faire ?
Je ne sais pas mais je vais essayer de chercher : ça m'intéresse aussi et c'est vrai que dans l'eshelle c'est casse-pieds :)
Merci ! Je continue à chercher de mon côté mais j'ai un peu de mal à trouver la bonne requête dans Google...
Bizarrement au boulot avec Matlab et matlab-mode.el, ça marche comme je voudrais : dès que l'on sélectionne le buffer on se retrouve derrière le prompt et impossible d'en sortir. Par contre avec le shell python et le shell unix standard, ça ne marche pas comme ça...
Si je trouve, je poste la solution ici !
Nicolas Pernetty
On Thu, 03 Nov 2005 21:33:23 +0100, Sébastien Kirche wrote :
Le 3 novembre 2005 à 21:11, Nicolas Pernetty vraute :
> Est-ce que cela est possible avec Xemacs 21.4.17 ? Si oui comment > faire ?
Je ne sais pas mais je vais essayer de chercher : ça m'intéresse aussi et c'est vrai que dans l'eshelle c'est casse-pieds :)
Au fait j'ai déjà essayé avec les commandes suivantes : 1) comint-scroll-to-bottom-on-input 2) comint-scroll-show-maximum-output 3) comint-preinput-scroll-to-bottom
Mais le 1) ne marche pas vraiment : ça marche au début lorsque l'on tape du texte au clavier (on est renvoyé au curseur dès la première frappe) mais dès que l'on essaye de copier-coller n'importe où, il colle le texte à l'endroit où on se trouve (au lieu de le coller après le prompt) et perd la boussole : on peut de nouveau taper du texte n'importe où !
Pour le 3) je ne suis arrivé à aucun résultat avec...
On Thu, 03 Nov 2005 21:33:23 +0100, Sébastien Kirche
<sebastien.kirche.no@spam.free.fr.invalid> wrote :
Le 3 novembre 2005 à 21:11, Nicolas Pernetty vraute :
> Est-ce que cela est possible avec Xemacs 21.4.17 ? Si oui comment
> faire ?
Je ne sais pas mais je vais essayer de chercher : ça m'intéresse aussi
et c'est vrai que dans l'eshelle c'est casse-pieds :)
Au fait j'ai déjà essayé avec les commandes suivantes :
1) comint-scroll-to-bottom-on-input
2) comint-scroll-show-maximum-output
3) comint-preinput-scroll-to-bottom
Mais le 1) ne marche pas vraiment : ça marche au début lorsque l'on
tape du texte au clavier (on est renvoyé au curseur dès la première
frappe) mais dès que l'on essaye de copier-coller n'importe où, il
colle le texte à l'endroit où on se trouve (au lieu de le coller après
le prompt) et perd la boussole : on peut de nouveau taper du texte
n'importe où !
Pour le 3) je ne suis arrivé à aucun résultat avec...
On Thu, 03 Nov 2005 21:33:23 +0100, Sébastien Kirche wrote :
Le 3 novembre 2005 à 21:11, Nicolas Pernetty vraute :
> Est-ce que cela est possible avec Xemacs 21.4.17 ? Si oui comment > faire ?
Je ne sais pas mais je vais essayer de chercher : ça m'intéresse aussi et c'est vrai que dans l'eshelle c'est casse-pieds :)
Au fait j'ai déjà essayé avec les commandes suivantes : 1) comint-scroll-to-bottom-on-input 2) comint-scroll-show-maximum-output 3) comint-preinput-scroll-to-bottom
Mais le 1) ne marche pas vraiment : ça marche au début lorsque l'on tape du texte au clavier (on est renvoyé au curseur dès la première frappe) mais dès que l'on essaye de copier-coller n'importe où, il colle le texte à l'endroit où on se trouve (au lieu de le coller après le prompt) et perd la boussole : on peut de nouveau taper du texte n'importe où !
Pour le 3) je ne suis arrivé à aucun résultat avec...
drkm
Nicolas Pernetty writes:
Par contre je ne vois pas trop bien où est l'intérêt de pouvoir 'se balader' dans un buffer type shell ?
ELISP> (defun contre-exemple () (message "Ceci est un contre exemple.")) contre-exemple ELISP> (contre-exemple) "Ceci est un contre exemple." ELISP> (stringp (contre-exemple)) t ELISP>
Par contre, je vois mal l'intérêt de cantonner l'utilisateur dans la ligne de prompt.
--drkm
Nicolas Pernetty writes:
Par contre je ne vois pas trop bien où est l'intérêt de pouvoir 'se
balader' dans un buffer type shell ?
ELISP> (defun contre-exemple ()
(message "Ceci est un contre exemple."))
contre-exemple
ELISP> (contre-exemple)
"Ceci est un contre exemple."
ELISP> (stringp (contre-exemple))
t
ELISP>
Par contre, je vois mal l'intérêt de cantonner l'utilisateur
dans la ligne de prompt.
Par contre je ne vois pas trop bien où est l'intérêt de pouvoir 'se balader' dans un buffer type shell ?
ELISP> (defun contre-exemple () (message "Ceci est un contre exemple.")) contre-exemple ELISP> (contre-exemple) "Ceci est un contre exemple." ELISP> (stringp (contre-exemple)) t ELISP>
Par contre, je vois mal l'intérêt de cantonner l'utilisateur dans la ligne de prompt.
--drkm
Leopold BAILLY
Nicolas Pernetty writes:
On Thu, 03 Nov 2005 21:37:59 +0100, Leopold BAILLY wrote :
Désolé de répondre à côté, mais Emacs est un avant tout un éditeur de texte ; l'intérêt d'ouvrir un shell dans emacs est de justement pouvoir se ballader dans tout le buffer.
Si tu veux un vrai xterm, il y a ... xterm.
L'intérêt de (X)emacs, c'est de pouvoir avoir une intégration entre l'édition de texte/code et l'interpréteur (shell) derrière. Si tu ne codes pas dans un langage interprété comme Python ou Matlab, c'est sûr que l'intérêt est moins immédiat par rapport à ouvrir un xterm à côté.
Oui, je comprends. Tu veux dire que quand ton shell t'indique une erreur, tu peux accéder directement à la ligne où ça plante.
Par contre je ne vois pas trop bien où est l'intérêt de pouvoir 'se balader' dans un buffer type shell ? Est-ce que c'est uniquement pour pouvoir sélectionner au clavier du texte ?
Ou faire des recherches dans une sortie verbeuse, ou pouvoir lire la sortie pendant que ça continue de défiler en bas.
Car l'utilisation de l'historique des commandes et de la souris pour sélectionner du texte couvre à mon avis déjà beaucoup de besoins. ..
Le copier-coller, c'est une des premières choses que j'ai arrêté de f aire à la souris dans emacs : pas assez précis (ou alors c'est moi qui ai des probl èmes psychomoteurs). Puis avec l'habitude, aller chercher la souris sur la gauch e du clavier est devenu un geste pénible.
Et puis, quelques fois, on n'a pas de souris.
-- Léo.
Nicolas Pernetty <nicopernetty@nowhere.fr> writes:
On Thu, 03 Nov 2005 21:37:59 +0100, Leopold BAILLY
<leo.bailly@infonie.fr> wrote :
Désolé de répondre à côté, mais Emacs est un avant tout un éditeur de
texte ; l'intérêt d'ouvrir un shell dans emacs est de justement
pouvoir se ballader dans tout le buffer.
Si tu veux un vrai xterm, il y a ... xterm.
L'intérêt de (X)emacs, c'est de pouvoir avoir une intégration entre
l'édition de texte/code et l'interpréteur (shell) derrière.
Si tu ne codes pas dans un langage interprété comme Python ou Matlab,
c'est sûr que l'intérêt est moins immédiat par rapport à ouvrir un
xterm à côté.
Oui, je comprends. Tu veux dire que quand ton shell t'indique une erreur, tu
peux accéder directement à la ligne où ça plante.
Par contre je ne vois pas trop bien où est l'intérêt de pouvoir 'se
balader' dans un buffer type shell ?
Est-ce que c'est uniquement pour pouvoir sélectionner au clavier du
texte ?
Ou faire des recherches dans une sortie verbeuse, ou pouvoir lire la sortie
pendant que ça continue de défiler en bas.
Car l'utilisation de l'historique des commandes et de la souris pour
sélectionner du texte couvre à mon avis déjà beaucoup de besoins. ..
Le copier-coller, c'est une des premières choses que j'ai arrêté de f aire à la
souris dans emacs : pas assez précis (ou alors c'est moi qui ai des probl èmes
psychomoteurs). Puis avec l'habitude, aller chercher la souris sur la gauch e du
clavier est devenu un geste pénible.
On Thu, 03 Nov 2005 21:37:59 +0100, Leopold BAILLY wrote :
Désolé de répondre à côté, mais Emacs est un avant tout un éditeur de texte ; l'intérêt d'ouvrir un shell dans emacs est de justement pouvoir se ballader dans tout le buffer.
Si tu veux un vrai xterm, il y a ... xterm.
L'intérêt de (X)emacs, c'est de pouvoir avoir une intégration entre l'édition de texte/code et l'interpréteur (shell) derrière. Si tu ne codes pas dans un langage interprété comme Python ou Matlab, c'est sûr que l'intérêt est moins immédiat par rapport à ouvrir un xterm à côté.
Oui, je comprends. Tu veux dire que quand ton shell t'indique une erreur, tu peux accéder directement à la ligne où ça plante.
Par contre je ne vois pas trop bien où est l'intérêt de pouvoir 'se balader' dans un buffer type shell ? Est-ce que c'est uniquement pour pouvoir sélectionner au clavier du texte ?
Ou faire des recherches dans une sortie verbeuse, ou pouvoir lire la sortie pendant que ça continue de défiler en bas.
Car l'utilisation de l'historique des commandes et de la souris pour sélectionner du texte couvre à mon avis déjà beaucoup de besoins. ..
Le copier-coller, c'est une des premières choses que j'ai arrêté de f aire à la souris dans emacs : pas assez précis (ou alors c'est moi qui ai des probl èmes psychomoteurs). Puis avec l'habitude, aller chercher la souris sur la gauch e du clavier est devenu un geste pénible.
Et puis, quelques fois, on n'a pas de souris.
-- Léo.
Nicolas Pernetty
On Thu, 03 Nov 2005 22:44:46 +0100, Leopold BAILLY wrote :
> >> Désolé de répondre à côté, mais Emacs est un avant tout un éditeur >> de texte ; l'intérêt d'ouvrir un shell dans emacs est de justement >> pouvoir se ballader dans tout le buffer. >> >> Si tu veux un vrai xterm, il y a ... xterm. >> > > L'intérêt de (X)emacs, c'est de pouvoir avoir une intégration entre > l'édition de texte/code et l'interpréteur (shell) derrière. > Si tu ne codes pas dans un langage interprété comme Python ou > Matlab, c'est sûr que l'intérêt est moins immédiat par rapport à > ouvrir un xterm à côté.
Oui, je comprends. Tu veux dire que quand ton shell t'indique une erreur, tu peux accéder directement à la ligne où ça plante.
Oui entre autre. Ou par exemple pouvoir exécuter une région ou tout le buffer dans le shell. Ou encore exécuter un programme pas à pas via le débogueur...
> Par contre je ne vois pas trop bien où est l'intérêt de pouvoir 'se > balader' dans un buffer type shell ? > Est-ce que c'est uniquement pour pouvoir sélectionner au clavier du > texte ?
Ou faire des recherches dans une sortie verbeuse, ou pouvoir lire la sortie pendant que ça continue de défiler en bas.
Ah oui... c'est vrai que cela peut être très pratique ! Comme je ne peux pas le faire avec un xterm standard, je n'y avais pas du tout pensé...
> Car l'utilisation de l'historique des commandes et de la souris pour > sélectionner du texte couvre à mon avis déjà beaucoup de besoins...
Le copier-coller, c'est une des premières choses que j'ai arrêté de faire à la souris dans emacs : pas assez précis (ou alors c'est moi qui ai des problèmes psychomoteurs). Puis avec l'habitude, aller chercher la souris sur la gauche du clavier est devenu un geste pénible.
Et puis, quelques fois, on n'a pas de souris.
Sans doute qu'avec de l'expérience c'est effectivement plus rapide au clavier avec emacs. En tous cas avec d'autres éditeurs de texte 'standard' du genre notepad ou nedit, c'est quand même plus facile à la souris je trouve.
L'idée derrière ce besoin est d'offrir un environnement facile à utiliser pour un débutant (d'où l'idée de restreindre les manipulations possibles dans un shell). Après si la personne veut désactiver le bridage, pas de soucis...
On Thu, 03 Nov 2005 22:44:46 +0100, Leopold BAILLY
<leo.bailly@infonie.fr> wrote :
>
>> Désolé de répondre à côté, mais Emacs est un avant tout un éditeur
>> de texte ; l'intérêt d'ouvrir un shell dans emacs est de justement
>> pouvoir se ballader dans tout le buffer.
>>
>> Si tu veux un vrai xterm, il y a ... xterm.
>>
>
> L'intérêt de (X)emacs, c'est de pouvoir avoir une intégration entre
> l'édition de texte/code et l'interpréteur (shell) derrière.
> Si tu ne codes pas dans un langage interprété comme Python ou
> Matlab, c'est sûr que l'intérêt est moins immédiat par rapport à
> ouvrir un xterm à côté.
Oui, je comprends. Tu veux dire que quand ton shell t'indique une
erreur, tu peux accéder directement à la ligne où ça plante.
Oui entre autre. Ou par exemple pouvoir exécuter une région ou tout le
buffer dans le shell. Ou encore exécuter un programme pas à pas via le
débogueur...
> Par contre je ne vois pas trop bien où est l'intérêt de pouvoir 'se
> balader' dans un buffer type shell ?
> Est-ce que c'est uniquement pour pouvoir sélectionner au clavier du
> texte ?
Ou faire des recherches dans une sortie verbeuse, ou pouvoir lire la
sortie pendant que ça continue de défiler en bas.
Ah oui... c'est vrai que cela peut être très pratique !
Comme je ne peux pas le faire avec un xterm standard, je n'y avais pas
du tout pensé...
> Car l'utilisation de l'historique des commandes et de la souris pour
> sélectionner du texte couvre à mon avis déjà beaucoup de besoins...
Le copier-coller, c'est une des premières choses que j'ai arrêté de
faire à la souris dans emacs : pas assez précis (ou alors c'est moi
qui ai des problèmes psychomoteurs). Puis avec l'habitude, aller
chercher la souris sur la gauche du clavier est devenu un geste
pénible.
Et puis, quelques fois, on n'a pas de souris.
Sans doute qu'avec de l'expérience c'est effectivement plus rapide au
clavier avec emacs. En tous cas avec d'autres éditeurs de texte
'standard' du genre notepad ou nedit, c'est quand même plus facile à la
souris je trouve.
L'idée derrière ce besoin est d'offrir un environnement facile à
utiliser pour un débutant (d'où l'idée de restreindre les manipulations
possibles dans un shell).
Après si la personne veut désactiver le bridage, pas de soucis...
On Thu, 03 Nov 2005 22:44:46 +0100, Leopold BAILLY wrote :
> >> Désolé de répondre à côté, mais Emacs est un avant tout un éditeur >> de texte ; l'intérêt d'ouvrir un shell dans emacs est de justement >> pouvoir se ballader dans tout le buffer. >> >> Si tu veux un vrai xterm, il y a ... xterm. >> > > L'intérêt de (X)emacs, c'est de pouvoir avoir une intégration entre > l'édition de texte/code et l'interpréteur (shell) derrière. > Si tu ne codes pas dans un langage interprété comme Python ou > Matlab, c'est sûr que l'intérêt est moins immédiat par rapport à > ouvrir un xterm à côté.
Oui, je comprends. Tu veux dire que quand ton shell t'indique une erreur, tu peux accéder directement à la ligne où ça plante.
Oui entre autre. Ou par exemple pouvoir exécuter une région ou tout le buffer dans le shell. Ou encore exécuter un programme pas à pas via le débogueur...
> Par contre je ne vois pas trop bien où est l'intérêt de pouvoir 'se > balader' dans un buffer type shell ? > Est-ce que c'est uniquement pour pouvoir sélectionner au clavier du > texte ?
Ou faire des recherches dans une sortie verbeuse, ou pouvoir lire la sortie pendant que ça continue de défiler en bas.
Ah oui... c'est vrai que cela peut être très pratique ! Comme je ne peux pas le faire avec un xterm standard, je n'y avais pas du tout pensé...
> Car l'utilisation de l'historique des commandes et de la souris pour > sélectionner du texte couvre à mon avis déjà beaucoup de besoins...
Le copier-coller, c'est une des premières choses que j'ai arrêté de faire à la souris dans emacs : pas assez précis (ou alors c'est moi qui ai des problèmes psychomoteurs). Puis avec l'habitude, aller chercher la souris sur la gauche du clavier est devenu un geste pénible.
Et puis, quelques fois, on n'a pas de souris.
Sans doute qu'avec de l'expérience c'est effectivement plus rapide au clavier avec emacs. En tous cas avec d'autres éditeurs de texte 'standard' du genre notepad ou nedit, c'est quand même plus facile à la souris je trouve.
L'idée derrière ce besoin est d'offrir un environnement facile à utiliser pour un débutant (d'où l'idée de restreindre les manipulations possibles dans un shell). Après si la personne veut désactiver le bridage, pas de soucis...
Nicolas Pernetty
On Thu, 03 Nov 2005 22:40:37 +0100, drkm wrote :
Nicolas Pernetty writes:
> Par contre je ne vois pas trop bien où est l'intérêt de pouvoir 'se > balader' dans un buffer type shell ?
ELISP> (defun contre-exemple () (message "Ceci est un contre exemple.")) contre-exemple ELISP> (contre-exemple) "Ceci est un contre exemple." ELISP> (stringp (contre-exemple)) t ELISP>
Par contre, je vois mal l'intérêt de cantonner l'utilisateur dans la ligne de prompt.
--drkm
J'ai bien passé 5 bonnes minutes à examiner le code sans comprendre l'argument... Peux-tu détailler svp ?
Sinon je cherche à brider un peu l'utilisateur dans un shell pour restreindre un peu les possibilités qu'il a au prime abord. C'est vite déconcertant d'avoir un semblant de xterm dans lequel on peut écrire partout et polluer de ce fait l'écran de sortie des résultats (cela m'arrive régulièrement au détour d'un copier-coller un peu hâtif...).
Et du coup je pourrais en profiter pour remapper les touches flèches haut et bas pour accéder à l'historique (qui sont pour l'instant reliées à Ctrl-haut et Ctrl-bas), je trouve personnellement que c'est plus intuitif.
C'est plus facile à un power-user de désactiver ce bridage qu'à un simple utilisateur de le mettre (la preuve : je galère pour trouver une solution).
On Thu, 03 Nov 2005 22:40:37 +0100, drkm <usenet.fcaemacs@fgeorges.org>
wrote :
Nicolas Pernetty writes:
> Par contre je ne vois pas trop bien où est l'intérêt de pouvoir 'se
> balader' dans un buffer type shell ?
ELISP> (defun contre-exemple ()
(message "Ceci est un contre exemple."))
contre-exemple
ELISP> (contre-exemple)
"Ceci est un contre exemple."
ELISP> (stringp (contre-exemple))
t
ELISP>
Par contre, je vois mal l'intérêt de cantonner l'utilisateur
dans la ligne de prompt.
--drkm
J'ai bien passé 5 bonnes minutes à examiner le code sans comprendre
l'argument...
Peux-tu détailler svp ?
Sinon je cherche à brider un peu l'utilisateur dans un shell pour
restreindre un peu les possibilités qu'il a au prime abord.
C'est vite déconcertant d'avoir un semblant de xterm dans lequel on
peut écrire partout et polluer de ce fait l'écran de sortie des
résultats (cela m'arrive régulièrement au détour d'un copier-coller un
peu hâtif...).
Et du coup je pourrais en profiter pour remapper les touches flèches
haut et bas pour accéder à l'historique (qui sont pour l'instant
reliées à Ctrl-haut et Ctrl-bas), je trouve personnellement que c'est
plus intuitif.
C'est plus facile à un power-user de désactiver ce bridage qu'à un
simple utilisateur de le mettre (la preuve : je galère pour trouver une
solution).
> Par contre je ne vois pas trop bien où est l'intérêt de pouvoir 'se > balader' dans un buffer type shell ?
ELISP> (defun contre-exemple () (message "Ceci est un contre exemple.")) contre-exemple ELISP> (contre-exemple) "Ceci est un contre exemple." ELISP> (stringp (contre-exemple)) t ELISP>
Par contre, je vois mal l'intérêt de cantonner l'utilisateur dans la ligne de prompt.
--drkm
J'ai bien passé 5 bonnes minutes à examiner le code sans comprendre l'argument... Peux-tu détailler svp ?
Sinon je cherche à brider un peu l'utilisateur dans un shell pour restreindre un peu les possibilités qu'il a au prime abord. C'est vite déconcertant d'avoir un semblant de xterm dans lequel on peut écrire partout et polluer de ce fait l'écran de sortie des résultats (cela m'arrive régulièrement au détour d'un copier-coller un peu hâtif...).
Et du coup je pourrais en profiter pour remapper les touches flèches haut et bas pour accéder à l'historique (qui sont pour l'instant reliées à Ctrl-haut et Ctrl-bas), je trouve personnellement que c'est plus intuitif.
C'est plus facile à un power-user de désactiver ce bridage qu'à un simple utilisateur de le mettre (la preuve : je galère pour trouver une solution).
Matthieu Moy
Nicolas Pernetty writes:
Sinon je cherche à brider un peu l'utilisateur dans un shell pour restreindre un peu les possibilités qu'il a au prime abord. C'est vite déconcertant d'avoir un semblant de xterm dans lequel on peut écrire partout et polluer de ce fait l'écran de sortie des résultats (cela m'arrive régulièrement au détour d'un copier-coller un peu hâtif...).
Ce que tu cherches s'appelle M-x ansi-term RET.
-- Matthieu
Nicolas Pernetty <nicopernetty@nowhere.fr> writes:
Sinon je cherche à brider un peu l'utilisateur dans un shell pour
restreindre un peu les possibilités qu'il a au prime abord.
C'est vite déconcertant d'avoir un semblant de xterm dans lequel on
peut écrire partout et polluer de ce fait l'écran de sortie des
résultats (cela m'arrive régulièrement au détour d'un copier-coller un
peu hâtif...).
Sinon je cherche à brider un peu l'utilisateur dans un shell pour restreindre un peu les possibilités qu'il a au prime abord. C'est vite déconcertant d'avoir un semblant de xterm dans lequel on peut écrire partout et polluer de ce fait l'écran de sortie des résultats (cela m'arrive régulièrement au détour d'un copier-coller un peu hâtif...).
