J'aimerais pouvoir lancer Emacs avec un Mutt (ou tout autre
processus) dedans en mode terminal. En gros, un peu l'équivalent
d'un "xterm -e mutt args...", mais avec un Emacs à la place d'un
Xterm (c'est pour les liens mailto...). Comment faire?
fonctionne, mais je voudrais que quand Mutt quitte, la fenêtre soit
fermée.
D'autre part, pour la composition du message, Mutt lance un
éditeur externe (configuré par l'utilisateur). Je suppose qu'un
"emacs -nw" fait l'affaire (voire un "gnuclient -nw", mais j'avais
eu des problèmes avec les couleurs dans le passé, si bien que je
n'utilise plus gnuclient).
Heu, j'ai l'impression d'avoir manque un truc gros comme la lune, mais je ne vois pas. Sans doute que l'abus de deadlines a proximite elevee nuit a la qualite des cellules ...
--drkm
Matthieu Moy wrote:
"Florent Georges" writes:
> Je ne connais pas CLA.
[...]
Non, rien :-)
Heu, j'ai l'impression d'avoir manque un truc gros comme la lune,
mais je ne vois pas. Sans doute que l'abus de deadlines a proximite
elevee nuit a la qualite des cellules ...
Heu, j'ai l'impression d'avoir manque un truc gros comme la lune, mais je ne vois pas. Sans doute que l'abus de deadlines a proximite elevee nuit a la qualite des cellules ...
--drkm
Vincent Lefevre
Dans l'article , Matthieu Moy écrit:
Pour ton problème, un gnuclient -batch -eval '(find-file ...)' devrait pouvoir le faire.
Il y a un autre problème avec ça: gnuclient rend la main immédiatement. Il faudrait qu'il rende la main seulement une fois que le buffer est tué. Y a-t-il un moyen?
Sinon il faut que je me débrouille avec des signaux (quand le buffer est tué, Emacs enverrait un signal au script qui a lancé gnuclient).
Dans l'article <vpqfymr4a6i.fsf@ecrins.imag.fr>,
Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> écrit:
Pour ton problème, un gnuclient -batch -eval '(find-file ...)' devrait
pouvoir le faire.
Il y a un autre problème avec ça: gnuclient rend la main immédiatement.
Il faudrait qu'il rende la main seulement une fois que le buffer est
tué. Y a-t-il un moyen?
Sinon il faut que je me débrouille avec des signaux (quand le buffer
est tué, Emacs enverrait un signal au script qui a lancé gnuclient).
Pour ton problème, un gnuclient -batch -eval '(find-file ...)' devrait pouvoir le faire.
Il y a un autre problème avec ça: gnuclient rend la main immédiatement. Il faudrait qu'il rende la main seulement une fois que le buffer est tué. Y a-t-il un moyen?
Sinon il faut que je me débrouille avec des signaux (quand le buffer est tué, Emacs enverrait un signal au script qui a lancé gnuclient).
Écrire un fichier cla.el qui fasse qu'Emacs ne traite pas les arguments à partir d'un "+", comme avec:
emacs -l cla.el + a b
Ah, ok. Tu es dans le contexte du traitement des aguments. Tu peux utiliser 'command-line-args-left' a la place de 'command-line-args' dans ce cas, pour connaitre les arguments qui restent sur la ligne de commande au moment de l'appel (ici, au moment du chargement de cla.el). Cette liste devrait a ce moment contenir ("+" "a" "b").
--drkm
Vincent Lefevre wrote:
Écrire un fichier cla.el qui fasse qu'Emacs ne traite pas les
arguments à partir d'un "+", comme avec:
emacs -l cla.el + a b
Ah, ok. Tu es dans le contexte du traitement des aguments. Tu peux
utiliser 'command-line-args-left' a la place de 'command-line-args'
dans ce cas, pour connaitre les arguments qui restent sur la ligne de
commande au moment de l'appel (ici, au moment du chargement de cla.el).
Cette liste devrait a ce moment contenir ("+" "a" "b").
Écrire un fichier cla.el qui fasse qu'Emacs ne traite pas les arguments à partir d'un "+", comme avec:
emacs -l cla.el + a b
Ah, ok. Tu es dans le contexte du traitement des aguments. Tu peux utiliser 'command-line-args-left' a la place de 'command-line-args' dans ce cas, pour connaitre les arguments qui restent sur la ligne de commande au moment de l'appel (ici, au moment du chargement de cla.el). Cette liste devrait a ce moment contenir ("+" "a" "b").
--drkm
Vincent Lefevre
Dans l'article , Florent Georges écrit:
Ah, ok. Tu es dans le contexte du traitement des aguments. Tu peux utiliser 'command-line-args-left' a la place de 'command-line-args' dans ce cas, pour connaitre les arguments qui restent sur la ligne de commande au moment de l'appel (ici, au moment du chargement de cla.el). Cette liste devrait a ce moment contenir ("+" "a" "b").
Dans l'article <1139589440.777454.80400@g43g2000cwa.googlegroups.com>,
Florent Georges <fgeorges.spam@gmail.com> écrit:
Ah, ok. Tu es dans le contexte du traitement des aguments. Tu peux
utiliser 'command-line-args-left' a la place de 'command-line-args'
dans ce cas, pour connaitre les arguments qui restent sur la ligne de
commande au moment de l'appel (ici, au moment du chargement de cla.el).
Cette liste devrait a ce moment contenir ("+" "a" "b").
Ah, ok. Tu es dans le contexte du traitement des aguments. Tu peux utiliser 'command-line-args-left' a la place de 'command-line-args' dans ce cas, pour connaitre les arguments qui restent sur la ligne de commande au moment de l'appel (ici, au moment du chargement de cla.el). Cette liste devrait a ce moment contenir ("+" "a" "b").
Heu, j'ai l'impression d'avoir manque un truc gros comme la lune, mais je ne vois pas. Sans doute que l'abus de deadlines a proximite elevee nuit a la qualite des cellules ...
Tu dis ne pas connaitre CLA, ce qui est normal vu que c'est un script maison de une ligne, qui est cite un peu plus haut dans le message.
Heu, j'ai l'impression d'avoir manque un truc gros comme la lune,
mais je ne vois pas. Sans doute que l'abus de deadlines a proximite
elevee nuit a la qualite des cellules ...
Tu dis ne pas connaitre CLA, ce qui est normal vu que c'est un script
maison de une ligne, qui est cite un peu plus haut dans le message.
Heu, j'ai l'impression d'avoir manque un truc gros comme la lune, mais je ne vois pas. Sans doute que l'abus de deadlines a proximite elevee nuit a la qualite des cellules ...
Tu dis ne pas connaitre CLA, ce qui est normal vu que c'est un script maison de une ligne, qui est cite un peu plus haut dans le message.
-- Matthieu
Florent Georges
Matthieu Moy wrote:
Tu dis ne pas connaitre CLA, ce qui est normal vu que c'est un script maison de une ligne, qui est cite un peu plus haut dans le message.
'y a des jours comme ca :-p
--drkm
Matthieu Moy wrote:
Tu dis ne pas connaitre CLA, ce qui est normal vu que c'est un script
maison de une ligne, qui est cite un peu plus haut dans le message.
Tu dis ne pas connaitre CLA, ce qui est normal vu que c'est un script maison de une ligne, qui est cite un peu plus haut dans le message.
'y a des jours comme ca :-p
--drkm
Erwan David
Vincent Lefevre <vincent+ écrivait :
Dans l'article , Matthieu Moy écrit:
Pour ton problème, un gnuclient -batch -eval '(find-file ...)' devrait pouvoir le faire.
Il y a un autre problème avec ça: gnuclient rend la main immédiatement. Il faudrait qu'il rende la main seulement une fois que le buffer est tué. Y a-t-il un moyen?
Oui. C'est le comportement normal...
extrait du man : -q
This option informs gnuclient to exit once connection has been made with the XEmacs process. Normally gnuclient waits until all of the files on the command line have been finished with (their buffers killed) by the XEmacs process, and all the forms have been evaluated. Note that this is different from XEmacs itself, where this option means to inhibit loading of the user init file.
-- Si vous embauchez, voici mon CV http://www.rail.eu.org/cv/cv.pdf
Vincent Lefevre <vincent+news@vinc17.org> écrivait :
Dans l'article <vpqfymr4a6i.fsf@ecrins.imag.fr>,
Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> écrit:
Pour ton problème, un gnuclient -batch -eval '(find-file ...)' devrait
pouvoir le faire.
Il y a un autre problème avec ça: gnuclient rend la main immédiatement.
Il faudrait qu'il rende la main seulement une fois que le buffer est
tué. Y a-t-il un moyen?
Oui. C'est le comportement normal...
extrait du man :
-q
This option informs gnuclient to exit once connection has been
made with the XEmacs process. Normally gnuclient waits until
all of the files on the command line have been finished with
(their buffers killed) by the XEmacs process, and all the forms
have been evaluated. Note that this is different from XEmacs
itself, where this option means to inhibit loading of the user
init file.
--
Si vous embauchez, voici mon CV
http://www.rail.eu.org/cv/cv.pdf
Pour ton problème, un gnuclient -batch -eval '(find-file ...)' devrait pouvoir le faire.
Il y a un autre problème avec ça: gnuclient rend la main immédiatement. Il faudrait qu'il rende la main seulement une fois que le buffer est tué. Y a-t-il un moyen?
Oui. C'est le comportement normal...
extrait du man : -q
This option informs gnuclient to exit once connection has been made with the XEmacs process. Normally gnuclient waits until all of the files on the command line have been finished with (their buffers killed) by the XEmacs process, and all the forms have been evaluated. Note that this is different from XEmacs itself, where this option means to inhibit loading of the user init file.
-- Si vous embauchez, voici mon CV http://www.rail.eu.org/cv/cv.pdf
Vincent Lefevre
Dans l'article , Erwan David écrit:
Vincent Lefevre <vincent+ écrivait :
> Dans l'article , > Matthieu Moy écrit: > >> Pour ton problème, un gnuclient -batch -eval '(find-file ...)' devrait >> pouvoir le faire. > > Il y a un autre problème avec ça: gnuclient rend la main immédiatement. > Il faudrait qu'il rende la main seulement une fois que le buffer est > tué. Y a-t-il un moyen?
Oui. C'est le comportement normal...
Non...
extrait du man : -q
This option informs gnuclient to exit once connection has been made with the XEmacs process. Normally gnuclient waits until all of the files on the command line have been finished with
^^^^^^^^^^^^^^^^^^^ Le fichier n'est pas précisé dans la ligne de commande (sous-entendu en argument), mais dans du code LISP.
(their buffers killed) by the XEmacs process, and all the forms have been evaluated. Note that this is different from XEmacs itself, where this option means to inhibit loading of the user init file.
Dans l'article <m24q373u8j.fsf@ratagaz.depot.rail.eu.org>,
Erwan David <erwan@rail.eu.org> écrit:
Vincent Lefevre <vincent+news@vinc17.org> écrivait :
> Dans l'article <vpqfymr4a6i.fsf@ecrins.imag.fr>,
> Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> écrit:
>
>> Pour ton problème, un gnuclient -batch -eval '(find-file ...)' devrait
>> pouvoir le faire.
>
> Il y a un autre problème avec ça: gnuclient rend la main immédiatement.
> Il faudrait qu'il rende la main seulement une fois que le buffer est
> tué. Y a-t-il un moyen?
Oui. C'est le comportement normal...
Non...
extrait du man :
-q
This option informs gnuclient to exit once connection has been
made with the XEmacs process. Normally gnuclient waits until
all of the files on the command line have been finished with
^^^^^^^^^^^^^^^^^^^
Le fichier n'est pas précisé dans la ligne de commande (sous-entendu
en argument), mais dans du code LISP.
(their buffers killed) by the XEmacs process, and all the forms
have been evaluated. Note that this is different from XEmacs
itself, where this option means to inhibit loading of the user
init file.
> Dans l'article , > Matthieu Moy écrit: > >> Pour ton problème, un gnuclient -batch -eval '(find-file ...)' devrait >> pouvoir le faire. > > Il y a un autre problème avec ça: gnuclient rend la main immédiatement. > Il faudrait qu'il rende la main seulement une fois que le buffer est > tué. Y a-t-il un moyen?
Oui. C'est le comportement normal...
Non...
extrait du man : -q
This option informs gnuclient to exit once connection has been made with the XEmacs process. Normally gnuclient waits until all of the files on the command line have been finished with
^^^^^^^^^^^^^^^^^^^ Le fichier n'est pas précisé dans la ligne de commande (sous-entendu en argument), mais dans du code LISP.
(their buffers killed) by the XEmacs process, and all the forms have been evaluated. Note that this is different from XEmacs itself, where this option means to inhibit loading of the user init file.
