Tiens, puisqu'il semble y avoir des personnes compétentes par ici, est-ce que
quelqu'un saurait répondre à cette question que j'ai posée il y a peu sur
superuser.com sans avoir de réponse jusqu'ici:
http://superuser.com/questions/583552/prevent-emacs-shell-mode-to-apply-string-face-to-output-lines-containing-a-colon
--
Gilles Pion
et donc en adaptant ça à tes besoins, cela devrait fonctionner... Je pense que tu peux soit modifier l'une de ces expressions régulières, ou en ajouter une qui évitera string-face dans les cas que tu souhaites.
-- DW
* Gilles Pion <nosuchuser@nosuchdomain.com> in fr.comp.applications.emacs:
Tiens, puisqu'il semble y avoir des personnes compétentes par ici,
est-ce que quelqu'un saurait répondre à cette question que j'ai posée
il y a peu sur superuser.com sans avoir de réponse jusqu'ici:
http://superuser.com/questions/583552/prevent-emacs-shell-mode-to-apply-string-face-to-output-lines-containing-a-colon
Ben des fois, juste lancer un grep sur une sous-partie du code lisp
d'Emacs, ça peut aider... Pas besoin de magie noire :)
En cherchant font-lock-string-face dans shell.el, je trouve ceci :
et donc en adaptant ça à tes besoins, cela devrait fonctionner... Je
pense que tu peux soit modifier l'une de ces expressions régulières, ou
en ajouter une qui évitera string-face dans les cas que tu souhaites.
et donc en adaptant ça à tes besoins, cela devrait fonctionner... Je pense que tu peux soit modifier l'une de ces expressions régulières, ou en ajouter une qui évitera string-face dans les cas que tu souhaites.
et donc en adaptant ça à tes besoins, cela devrait fonctionner... Je pense que tu peux soit modifier l'une de ces expressions régulières, ou en ajouter une qui évitera string-face dans les cas que tu souhaites.
Le pire c'est que j'avais trouvé aussi ce bout de code, mais après avoir redéfini cette variable sans le deuxième élément j'avais toujours la colorisation.
Je viens de m'apercevoir que la modif ne s'applique qu'aux buffers shells ouverts *apres* avoir modifié la variable.
-- Gilles Pion
Ref: <5170d7e0$0$2401$426a34cc@news.free.fr> de Damien Wyart
En cherchant font-lock-string-face dans shell.el, je trouve ceci :
et donc en adaptant ça à tes besoins, cela devrait fonctionner... Je
pense que tu peux soit modifier l'une de ces expressions régulières, ou
en ajouter une qui évitera string-face dans les cas que tu souhaites.
Le pire c'est que j'avais trouvé aussi ce bout de code, mais après avoir
redéfini cette variable sans le deuxième élément j'avais toujours la
colorisation.
Je viens de m'apercevoir que la modif ne s'applique qu'aux buffers shells
ouverts *apres* avoir modifié la variable.
et donc en adaptant ça à tes besoins, cela devrait fonctionner... Je pense que tu peux soit modifier l'une de ces expressions régulières, ou en ajouter une qui évitera string-face dans les cas que tu souhaites.
Le pire c'est que j'avais trouvé aussi ce bout de code, mais après avoir redéfini cette variable sans le deuxième élément j'avais toujours la colorisation.
Je viens de m'apercevoir que la modif ne s'applique qu'aux buffers shells ouverts *apres* avoir modifié la variable.
-- Gilles Pion
Gilles Pion
Ref: de Jérémie Courrèges-Anglas
cf. shell-font-lock-keywords dans shell.el.
;;; dans shell.el, ne pas décorer les lignes du type "^foo: bar" (setq local/unwanted-shell-font-lock-keywords-entry '("^[^ tn]+:.*" . font-lock-string-face)) (eval-after-load "shell" '(setq shell-font-lock-keywords (delete local/unwanted-shell-font-lock-keywords-entry shell-font-lock-keywords)))
Ok ça marche après avoir utilisé un autre nom que "local/unwanted-shell-font-lock-keywords-entry" (quelle est cette sorte de elisp qui accepte un "/" dans les symboles ?)
-- Gilles Pion
Ref: <87k3nz3vm1.fsf@moo.wxcvbn.org> de Jérémie Courrèges-Anglas
cf. shell-font-lock-keywords dans shell.el.
;;; dans shell.el, ne pas décorer les lignes du type "^foo: bar"
(setq local/unwanted-shell-font-lock-keywords-entry
'("^[^ tn]+:.*" . font-lock-string-face))
(eval-after-load "shell"
'(setq shell-font-lock-keywords
(delete local/unwanted-shell-font-lock-keywords-entry
shell-font-lock-keywords)))
Ok ça marche après avoir utilisé un autre nom que
"local/unwanted-shell-font-lock-keywords-entry" (quelle est cette sorte de elisp
qui accepte un "/" dans les symboles ?)
;;; dans shell.el, ne pas décorer les lignes du type "^foo: bar" (setq local/unwanted-shell-font-lock-keywords-entry '("^[^ tn]+:.*" . font-lock-string-face)) (eval-after-load "shell" '(setq shell-font-lock-keywords (delete local/unwanted-shell-font-lock-keywords-entry shell-font-lock-keywords)))
Ok ça marche après avoir utilisé un autre nom que "local/unwanted-shell-font-lock-keywords-entry" (quelle est cette sorte de elisp qui accepte un "/" dans les symboles ?)
Ok ça marche après avoir utilisé un autre nom que "local/unwanted-shell-font-lock-keywords-entry" (quelle est cette sorte de elisp qui accepte un "/" dans les symboles ?)
Oh bah Emacs Lisp ; j'utilise un préfixe jca/ pour pas mal de trucs dans ma conf, cf. (info "(elisp) Symbol Type") pour les caractères acceptés dans un nom de symbole.
Tiens, pour ma part j'utilise "my-" en préfixe pour *exactement* le même usage!
Mais et en effet ça marche, je devais avoir un autre typo dans mon source (pourtant me semblait bien avoir juste fait copier/coller), j'ai cru que ça venait de là et j'ai corrigé le nom de variable.
Reste qu'il me serait intéressant de comprendre la raison d'avoir fait ces choix par défaut pour la colorisation du stdout dans les buffers shell?
Pour cette regexp particulière par exemple, ça fontifie comme "string" les lignes commençant par une suite de caractères "non-espace" suivis d'un ":".
-- Gilles Pion
Ref: <87fvym41lu.fsf@moo.wxcvbn.org> de Jérémie Courrèges-Anglas
Ok ça marche après avoir utilisé un autre nom que
"local/unwanted-shell-font-lock-keywords-entry" (quelle est cette sorte de elisp
qui accepte un "/" dans les symboles ?)
Oh bah Emacs Lisp ; j'utilise un préfixe jca/ pour pas mal de trucs dans
ma conf, cf. (info "(elisp) Symbol Type") pour les caractères acceptés
dans un nom de symbole.
Tiens, pour ma part j'utilise "my-" en préfixe pour *exactement* le même usage!
Mais et en effet ça marche, je devais avoir un autre typo dans mon source
(pourtant me semblait bien avoir juste fait copier/coller), j'ai cru que ça
venait de là et j'ai corrigé le nom de variable.
Reste qu'il me serait intéressant de comprendre la raison d'avoir fait ces choix
par défaut pour la colorisation du stdout dans les buffers shell?
Pour cette regexp particulière par exemple, ça fontifie comme "string" les
lignes commençant par une suite de caractères "non-espace" suivis d'un ":".
Ok ça marche après avoir utilisé un autre nom que "local/unwanted-shell-font-lock-keywords-entry" (quelle est cette sorte de elisp qui accepte un "/" dans les symboles ?)
Oh bah Emacs Lisp ; j'utilise un préfixe jca/ pour pas mal de trucs dans ma conf, cf. (info "(elisp) Symbol Type") pour les caractères acceptés dans un nom de symbole.
Tiens, pour ma part j'utilise "my-" en préfixe pour *exactement* le même usage!
Mais et en effet ça marche, je devais avoir un autre typo dans mon source (pourtant me semblait bien avoir juste fait copier/coller), j'ai cru que ça venait de là et j'ai corrigé le nom de variable.
Reste qu'il me serait intéressant de comprendre la raison d'avoir fait ces choix par défaut pour la colorisation du stdout dans les buffers shell?
Pour cette regexp particulière par exemple, ça fontifie comme "string" les lignes commençant par une suite de caractères "non-espace" suivis d'un ":".
Pour cette regexp particulière par exemple, ça fontifie comme " string" les lignes commençant par une suite de caractères "non-espace" suiv is d'un ":".
Je suppose que c'est pour matcher les warnings des compilateurs et autres grep -l, une version canada dry de compilation-mode, en somme.
Pour cette regexp particulière par exemple, ça fontifie comme " string" les
lignes commençant par une suite de caractères "non-espace" suiv is d'un ":".
Je suppose que c'est pour matcher les warnings des compilateurs et autres
grep -l, une version canada dry de compilation-mode, en somme.
Pour cette regexp particulière par exemple, ça fontifie comme " string" les lignes commençant par une suite de caractères "non-espace" suiv is d'un ":".
Je suppose que c'est pour matcher les warnings des compilateurs et autres grep -l, une version canada dry de compilation-mode, en somme.
Le samedi 20 avril 2013 09:18:56 UTC+2, Gilles Pion a écrit :
Reste qu'il me serait intéressant de comprendre la raison d'avoir fait ces choix par défaut pour la colorisation du stdout dans les buffers sh ell?
Pour cette regexp particulière par exemple, ça fontifie comme "string " les lignes commençant par une suite de caractères "non-espace" suivis d'u n ":".
Pour moi, ça ressemble furieusement à la sortie d'un "grep truc *" où les noms des fichiers matchant sont suivis de ':'
Le samedi 20 avril 2013 09:18:56 UTC+2, Gilles Pion a écrit :
Reste qu'il me serait intéressant de comprendre la raison d'avoir fait
ces choix par défaut pour la colorisation du stdout dans les buffers sh ell?
Pour cette regexp particulière par exemple, ça fontifie comme "string " les
lignes commençant par une suite de caractères "non-espace" suivis d'u n ":".
Pour moi, ça ressemble furieusement à la sortie d'un "grep truc *" où les noms des fichiers matchant sont suivis de ':'
Le samedi 20 avril 2013 09:18:56 UTC+2, Gilles Pion a écrit :
Reste qu'il me serait intéressant de comprendre la raison d'avoir fait ces choix par défaut pour la colorisation du stdout dans les buffers sh ell?
Pour cette regexp particulière par exemple, ça fontifie comme "string " les lignes commençant par une suite de caractères "non-espace" suivis d'u n ":".
Pour moi, ça ressemble furieusement à la sortie d'un "grep truc *" où les noms des fichiers matchant sont suivis de ':'
Gilles Pion
Ref: de
Pour cette regexp particulière par exemple, ça fontifie comme "string" les lignes commençant par une suite de caractères "non-espace" suivis d'un ":".
Pour moi, ça ressemble furieusement à la sortie d'un "grep truc *" où les noms des fichiers matchant sont suivis de ':'
En effet, mais cette regexp matche aussi bien d'autre choses et je pense que pour faire un grep dans emacs on va plutôt utiliser la function définie dans grep.el comme l'a évoqué entre les lignes jca. -- Gilles Pion
Ref: <17891abf-3558-43d7-ae44-f121a1d0edda@googlegroups.com> de
duthen.cnv@gmail.com
Pour cette regexp particulière par exemple, ça fontifie comme "string" les
lignes commençant par une suite de caractères "non-espace" suivis d'un ":".
Pour moi, ça ressemble furieusement à la sortie d'un "grep truc *" où les noms des fichiers matchant sont suivis de ':'
En effet, mais cette regexp matche aussi bien d'autre choses et je pense que
pour faire un grep dans emacs on va plutôt utiliser la function définie dans
grep.el comme l'a évoqué entre les lignes jca.
--
Gilles Pion
Pour cette regexp particulière par exemple, ça fontifie comme "string" les lignes commençant par une suite de caractères "non-espace" suivis d'un ":".
Pour moi, ça ressemble furieusement à la sortie d'un "grep truc *" où les noms des fichiers matchant sont suivis de ':'
En effet, mais cette regexp matche aussi bien d'autre choses et je pense que pour faire un grep dans emacs on va plutôt utiliser la function définie dans grep.el comme l'a évoqué entre les lignes jca. -- Gilles Pion
