Pour un programme en particulier, j'aimerais que tab-width valle 2 (!!).
Comme ce programme se trouvera toujours sous un répertoire
« mosesdecoder-qqch », j'ai fait ceci :
Au passage, ça me mets un mode C++ meme pour les headers, c'est bien.
Par contre, ça ne marche pas complètement : l'effet le plus visible,
c'est qu'il n'y a pas de coloration syntaxique à l'ouverture d'un
fichier, et meme après un font-lock-mode, c'est très pâlot (je vois en
passant au c++-mode que ce dernier est plus coloré).
Pourquoi mon c++-moses-mode ne fonctionne qu'à moitié, et comment
aboutir au résultat voulu (de cette manière ou d'une autre) ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
lhabert
Daniel Déchelotte :
(define-derived-mode c++-moses-mode c++-mode "C++ pour Moses" (set-variable 'tab-width 2) )
[snip]
c'est qu'il n'y a pas de coloration syntaxique à l'ouverture d'un fichier, et meme après un font-lock-mode, c'est très pâlot (je vois en passant au c++-mode que ce dernier est plus coloré).
Argh! Apparament, le fontlock n'est pas défini dans c++-mode, mais exporté dans fontlock.el : il y a une aliste de fontlock-defaults pour certains modes, et fontlock recherche le nom du mode majeur dans cette liste pour y trouver ses infos. Et ton major-mode doit être c++-moses-mode. Essaye de mettre un « (setq major-mode 'c++-mode) » dans le corps de c++-moses-mode.
Daniel Déchelotte :
(define-derived-mode c++-moses-mode c++-mode "C++ pour Moses"
(set-variable 'tab-width 2)
)
[snip]
c'est qu'il n'y a pas de coloration syntaxique à l'ouverture d'un
fichier, et meme après un font-lock-mode, c'est très pâlot (je vois en
passant au c++-mode que ce dernier est plus coloré).
Argh! Apparament, le fontlock n'est pas défini dans c++-mode, mais exporté
dans fontlock.el : il y a une aliste de fontlock-defaults pour certains
modes, et fontlock recherche le nom du mode majeur dans cette liste pour y
trouver ses infos. Et ton major-mode doit être c++-moses-mode. Essaye de
mettre un « (setq major-mode 'c++-mode) » dans le corps de c++-moses-mode.
(define-derived-mode c++-moses-mode c++-mode "C++ pour Moses" (set-variable 'tab-width 2) )
[snip]
c'est qu'il n'y a pas de coloration syntaxique à l'ouverture d'un fichier, et meme après un font-lock-mode, c'est très pâlot (je vois en passant au c++-mode que ce dernier est plus coloré).
Argh! Apparament, le fontlock n'est pas défini dans c++-mode, mais exporté dans fontlock.el : il y a une aliste de fontlock-defaults pour certains modes, et fontlock recherche le nom du mode majeur dans cette liste pour y trouver ses infos. Et ton major-mode doit être c++-moses-mode. Essaye de mettre un « (setq major-mode 'c++-mode) » dans le corps de c++-moses-mode.
Olivier
Luc Habert wrote: [...]
Essaye de mettre un « (setq major-mode 'c++-mode) » dans le corps de c++-moses-mode.
Ça n'a pas fonctionné, désolé :-/ (tel quel ou en remplaçant par c++-moses-mode).
Merci à vous deux. -- Daniel
Daniel Déchelotte
Olivier a écrit :
(define-derived-mode c++-moses-mode c++-mode "C++ pour Moses" (setq font-lock-defaults (cdr (assoc 'c++-mode font-lock-defaults-alist))) (set-variable 'tab-width 2) ) ne fonctionne pas ?
Ah ! Ça oui ! Je n'avais pas compris qu'il fallait le mettre dans le bloc (define-derived-mode ...), je l'avais mis après. D'solé. Je pensais que tu me proposais de faire : (add-to-list 'font-lock-defaults-alist (cons 'c++-moses-mode (cdr (assoc 'c++-mode font-lock-defaults-alist)))) (inspiré de façon éhontée de ton code, c'est vrai)
J'avais oublie une parenthese fermante.
Ça, j'avais été en mesure de le corriger. :-D
-- Daniel Déchelotte http://yo.dan.free.fr/
Olivier a écrit :
(define-derived-mode c++-moses-mode c++-mode "C++ pour Moses"
(setq font-lock-defaults
(cdr (assoc 'c++-mode font-lock-defaults-alist)))
(set-variable 'tab-width 2)
)
ne fonctionne pas ?
Ah ! Ça oui ! Je n'avais pas compris qu'il fallait le mettre dans le
bloc (define-derived-mode ...), je l'avais mis après. D'solé.
Je pensais que tu me proposais de faire :
(add-to-list 'font-lock-defaults-alist
(cons 'c++-moses-mode
(cdr (assoc 'c++-mode font-lock-defaults-alist))))
(inspiré de façon éhontée de ton code, c'est vrai)
(define-derived-mode c++-moses-mode c++-mode "C++ pour Moses" (setq font-lock-defaults (cdr (assoc 'c++-mode font-lock-defaults-alist))) (set-variable 'tab-width 2) ) ne fonctionne pas ?
Ah ! Ça oui ! Je n'avais pas compris qu'il fallait le mettre dans le bloc (define-derived-mode ...), je l'avais mis après. D'solé. Je pensais que tu me proposais de faire : (add-to-list 'font-lock-defaults-alist (cons 'c++-moses-mode (cdr (assoc 'c++-mode font-lock-defaults-alist)))) (inspiré de façon éhontée de ton code, c'est vrai)
J'avais oublie une parenthese fermante.
Ça, j'avais été en mesure de le corriger. :-D
-- Daniel Déchelotte http://yo.dan.free.fr/
Daniel Déchelotte
Olivier a écrit :
Daniel Déchelotte wrote: [...] > Je pensais que tu me proposais de faire : > (add-to-list 'font-lock-defaults-alist > (cons 'c++-moses-mode > (cdr (assoc 'c++-mode > font-lock-defaults-alist))))
Oh, ben cela, c'est pas mal je trouve.
Je n'ai pas du etre clair : ça marche aussi.
C'est mettre « (setq font-lock-defaults (cdr (assoc 'c++-mode font-lock-defaults-alist)) » *après* le bloc (define-derived-mode ...), au lieu de le mettre *à l'intérieur*, qui ne fonctionnait pas, et c'est bien normal.
Voilà voilà... :)
-- Daniel
Olivier a écrit :
Daniel Déchelotte wrote:
[...]
> Je pensais que tu me proposais de faire :
> (add-to-list 'font-lock-defaults-alist
> (cons 'c++-moses-mode
> (cdr (assoc 'c++-mode
> font-lock-defaults-alist))))
Oh, ben cela, c'est pas mal je trouve.
Je n'ai pas du etre clair : ça marche aussi.
C'est mettre « (setq font-lock-defaults (cdr (assoc 'c++-mode
font-lock-defaults-alist)) » *après* le bloc (define-derived-mode ...),
au lieu de le mettre *à l'intérieur*, qui ne fonctionnait pas, et c'est
bien normal.
Daniel Déchelotte wrote: [...] > Je pensais que tu me proposais de faire : > (add-to-list 'font-lock-defaults-alist > (cons 'c++-moses-mode > (cdr (assoc 'c++-mode > font-lock-defaults-alist))))
Oh, ben cela, c'est pas mal je trouve.
Je n'ai pas du etre clair : ça marche aussi.
C'est mettre « (setq font-lock-defaults (cdr (assoc 'c++-mode font-lock-defaults-alist)) » *après* le bloc (define-derived-mode ...), au lieu de le mettre *à l'intérieur*, qui ne fonctionnait pas, et c'est bien normal.
Voilà voilà... :)
-- Daniel
lhabert
Olivier :
Sous ma douche ce matin, je me suis dit que la solution avec font-lock-defaults-alist risquait en fait de ne pas fonctionner dans un cas très spécial : quand on passe un buffer déjà déclaré dans un autre mode dans celui-ci. Je ne crois pas que font-lock fasse la revérification
Quand on change de mode, ça effectue un kill-local-variables (c'est le nouveau mode qui doit commencer par ça), qui a pour effet entre autres de désactiver les modes mineurs, dont fontlock. Une fois le nouveau mode lancé, le fontlock est relancé (via le hook du mode, ou les hacks de global-font-lock-mode). Donc je ne vois pas comment il peut y avoir un problème.
Olivier :
Sous ma douche ce matin, je me suis dit que la
solution avec font-lock-defaults-alist risquait
en fait de ne pas fonctionner dans un cas très
spécial : quand on passe un buffer déjà déclaré
dans un autre mode dans celui-ci. Je ne crois
pas que font-lock fasse la revérification
Quand on change de mode, ça effectue un kill-local-variables (c'est le
nouveau mode qui doit commencer par ça), qui a pour effet entre autres de
désactiver les modes mineurs, dont fontlock. Une fois le nouveau mode lancé,
le fontlock est relancé (via le hook du mode, ou les hacks de
global-font-lock-mode). Donc je ne vois pas comment il peut y avoir un
problème.
Sous ma douche ce matin, je me suis dit que la solution avec font-lock-defaults-alist risquait en fait de ne pas fonctionner dans un cas très spécial : quand on passe un buffer déjà déclaré dans un autre mode dans celui-ci. Je ne crois pas que font-lock fasse la revérification
Quand on change de mode, ça effectue un kill-local-variables (c'est le nouveau mode qui doit commencer par ça), qui a pour effet entre autres de désactiver les modes mineurs, dont fontlock. Une fois le nouveau mode lancé, le fontlock est relancé (via le hook du mode, ou les hacks de global-font-lock-mode). Donc je ne vois pas comment il peut y avoir un problème.
Olivier
Luc Habert wrote: [...]
Quand on change de mode, ça effectue un kill-local-variables
Ah oui, je l'avais oublié celui-là ! Merci. A.O.
Luc Habert wrote:
[...]
Quand on change de mode, ça effectue un kill-local-variables
Quand on change de mode, ça effectue un kill-local-variables
Ah oui, je l'avais oublié celui-là ! Merci. A.O.
Paul Gaborit
À (at) Tue, 13 Mar 2007 15:46:15 +0100, Daniel Déchelotte écrivait (wro te):
Bonjour,
Pour un programme en particulier, j'aimerais que tab-width valle 2 (!!). Comme ce programme se trouvera toujours sous un répertoire « mosesdecoder-qqch », j'ai fait ceci :
Au passage, ça me mets un mode C++ meme pour les headers, c'est bien. Par contre, ça ne marche pas complètement : l'effet le plus visible, c'est qu'il n'y a pas de coloration syntaxique à l'ouverture d'un fichier, et meme après un font-lock-mode, c'est très pâlot (je vois en passant au c++-mode que ce dernier est plus coloré).
Pourquoi mon c++-moses-mode ne fonctionne qu'à moitié, et comment aboutir au résultat voulu (de cette manière ou d'une autre) ?
Pourquoi utiliser tout cela. La modification de la variable localement au buffer ne suffirait-elle pas ? Ça se fait automatiquement en plaçant les bons commentaires en fin de fichier. On peut améliorer les choses plus globalement en créant son propre style C/C++.
Si chaque projet qui a des règles de présentation du code spécifiques devait créer son propre mode C++ en ne s'en sortirait plus...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 13 Mar 2007 15:46:15 +0100,
Daniel Déchelotte <maitre_yodan@fr.club-internet.invalid> écrivait (wro te):
Bonjour,
Pour un programme en particulier, j'aimerais que tab-width valle 2 (!!).
Comme ce programme se trouvera toujours sous un répertoire
« mosesdecoder-qqch », j'ai fait ceci :
Au passage, ça me mets un mode C++ meme pour les headers, c'est bien.
Par contre, ça ne marche pas complètement : l'effet le plus visible,
c'est qu'il n'y a pas de coloration syntaxique à l'ouverture d'un
fichier, et meme après un font-lock-mode, c'est très pâlot (je vois en
passant au c++-mode que ce dernier est plus coloré).
Pourquoi mon c++-moses-mode ne fonctionne qu'à moitié, et comment
aboutir au résultat voulu (de cette manière ou d'une autre) ?
Pourquoi utiliser tout cela. La modification de la variable localement
au buffer ne suffirait-elle pas ? Ça se fait automatiquement en
plaçant les bons commentaires en fin de fichier. On peut améliorer les
choses plus globalement en créant son propre style C/C++.
Si chaque projet qui a des règles de présentation du code spécifiques
devait créer son propre mode C++ en ne s'en sortirait plus...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 13 Mar 2007 15:46:15 +0100, Daniel Déchelotte écrivait (wro te):
Bonjour,
Pour un programme en particulier, j'aimerais que tab-width valle 2 (!!). Comme ce programme se trouvera toujours sous un répertoire « mosesdecoder-qqch », j'ai fait ceci :
Au passage, ça me mets un mode C++ meme pour les headers, c'est bien. Par contre, ça ne marche pas complètement : l'effet le plus visible, c'est qu'il n'y a pas de coloration syntaxique à l'ouverture d'un fichier, et meme après un font-lock-mode, c'est très pâlot (je vois en passant au c++-mode que ce dernier est plus coloré).
Pourquoi mon c++-moses-mode ne fonctionne qu'à moitié, et comment aboutir au résultat voulu (de cette manière ou d'une autre) ?
Pourquoi utiliser tout cela. La modification de la variable localement au buffer ne suffirait-elle pas ? Ça se fait automatiquement en plaçant les bons commentaires en fin de fichier. On peut améliorer les choses plus globalement en créant son propre style C/C++.
Si chaque projet qui a des règles de présentation du code spécifiques devait créer son propre mode C++ en ne s'en sortirait plus...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Olivier
Paul Gaborit wrote: [..]
Pourquoi utiliser tout cela. La modification de la variable localement au buffer ne suffirait-elle pas ? Ça se fait automatiquement en plaçant les bons commentaires en fin de fichier. On peut améliorer les choses plus globalement en créant son propre style C/C++.
Si chaque projet qui a des règles de présentation du code spécifiques devait créer son propre mode C++ en ne s'en sortirait plus...
C'est une bonne option si le code n'est pas distribué sur plein de fichiers -- Evidemment, tout depend de ce que l'on entend par plein :-p -- Mais en echange ta solution est plus facilement portable -- A.O.
Paul Gaborit wrote:
[..]
Pourquoi utiliser tout cela. La modification de la variable localement
au buffer ne suffirait-elle pas ? Ça se fait automatiquement en
plaçant les bons commentaires en fin de fichier. On peut améliorer les
choses plus globalement en créant son propre style C/C++.
Si chaque projet qui a des règles de présentation du code spécifiques
devait créer son propre mode C++ en ne s'en sortirait plus...
C'est une bonne option si le code n'est pas distribué sur plein
de fichiers -- Evidemment, tout depend de ce que l'on entend par
plein :-p -- Mais en echange ta solution est plus facilement portable --
A.O.
Pourquoi utiliser tout cela. La modification de la variable localement au buffer ne suffirait-elle pas ? Ça se fait automatiquement en plaçant les bons commentaires en fin de fichier. On peut améliorer les choses plus globalement en créant son propre style C/C++.
Si chaque projet qui a des règles de présentation du code spécifiques devait créer son propre mode C++ en ne s'en sortirait plus...
C'est une bonne option si le code n'est pas distribué sur plein de fichiers -- Evidemment, tout depend de ce que l'on entend par plein :-p -- Mais en echange ta solution est plus facilement portable -- A.O.
