J'utilise two-mode-mode pour faire un mode hybride latex/asymptote:
quand le curseur se trouve entre les balises \begin{asy} et \end{asy}
tout le buffer bascule en asy-mode et hors des balises il est en mode
LaTeX-mode.
Ça fonctionne très bien sauf que...
En mode asy-mode tout texte entre apostrophes ou guillemets (") est
coloré en rouge (c'est une chaîne quoi).
Si j'édite ce bête code:
8<------8<------8<------8<------8<------8<------8<------8<------8<------
\documentclass{article}
\begin{document}
s'il Il n'y a pas de solution c'est qu'il n'y a pas de problème.
\begin{asy}
draw(unitcircle);
\end{asy}
\end{document}
8<------8<------8<------8<------8<------8<------8<------8<------8<------
comme le nombre d'apostrophes avant l'environnement asy est impair,
tout l'environnement asy devient rouge.
Auriez une idée pour contourner ce problème ?
J'étudie TOUTE proposition, de la plus farfelue à la plus sérieuse.
--
Merci de votre attention,
Philippe Ivaldi.
http://piprim.tuxfamily.org/
Mais qui a dit qu'Emacs n'était pas fait pour les multi-modes ? :-)
Ma pomme. Faut quand même ruser pas mal --
Peut-être que cette fonctionnalité intéresserait les auteurs de two-mode-mode...
Oui, c'est vrai, tu pourrais leur envoyer un mail pour leur indiquer, ce serait quand meme mieux que cette partie du code se trouve chez eux (attention toutefois, quand on advise trop, on peut se prendre les pieds dans le tapis -- dans le code que j'ai propose, le nom des variables est codé en *dur*, parce que je ne suis pas sûr de comment les coder en souple :-! J'ai bien tout lu mon manuel http://www.delorie.com/gnu/docs/elisp-manual-21/elisp_212.html j'ai pas tout compris -- enfin, peut etre que si, mais peut etre que non -- Bref, faudrait ecrire le code approprié et le vérifier -- )
Je ne sais pas comment te remercier !
C'est du code libre que j'utiliserais probablement un jour, autant que je mette la main à la patte pendant que tu es encore actif sur ce code ; du coup, tu controles directement la coherence globale :-) Je peste tellement contre l'absence de bons logiciels qui permettent de faire facilement des dessins en tex -- Asymptote me plait bien. Lui manque plus qu'une interface à la xfig, la 3d à la gnuplot et un chouia de documentation :-p
Bon, on croise les doigts pour que les bugs partent en vacances -- Amities, Olivier
Ph. Ivaldi wrote:
[...]
Mais qui a dit qu'Emacs n'était pas fait pour les multi-modes ? :-)
Ma pomme. Faut quand même ruser pas mal --
Peut-être que cette fonctionnalité intéresserait les auteurs de
two-mode-mode...
Oui, c'est vrai, tu pourrais leur envoyer un mail pour leur indiquer,
ce serait quand meme mieux que cette partie du code se trouve chez eux
(attention toutefois, quand on advise trop, on peut se prendre les pieds
dans le tapis -- dans le code que j'ai propose, le nom des variables
est codé en *dur*, parce que je ne suis pas sûr de comment les coder
en souple :-! J'ai bien tout lu mon manuel
http://www.delorie.com/gnu/docs/elisp-manual-21/elisp_212.html
j'ai pas tout compris -- enfin, peut etre que si, mais peut etre
que non -- Bref, faudrait ecrire le code approprié et le vérifier -- )
Je ne sais pas comment te remercier !
C'est du code libre que j'utiliserais probablement un jour, autant
que je mette la main à la patte pendant que tu es encore actif sur
ce code ; du coup, tu controles directement la coherence globale
:-)
Je peste tellement contre l'absence de bons logiciels qui permettent
de faire facilement des dessins en tex --
Asymptote me plait bien.
Lui manque plus qu'une interface à la xfig, la 3d à la gnuplot
et un chouia de documentation :-p
Bon, on croise les doigts pour que les bugs partent en vacances --
Amities, Olivier
Mais qui a dit qu'Emacs n'était pas fait pour les multi-modes ? :-)
Ma pomme. Faut quand même ruser pas mal --
Peut-être que cette fonctionnalité intéresserait les auteurs de two-mode-mode...
Oui, c'est vrai, tu pourrais leur envoyer un mail pour leur indiquer, ce serait quand meme mieux que cette partie du code se trouve chez eux (attention toutefois, quand on advise trop, on peut se prendre les pieds dans le tapis -- dans le code que j'ai propose, le nom des variables est codé en *dur*, parce que je ne suis pas sûr de comment les coder en souple :-! J'ai bien tout lu mon manuel http://www.delorie.com/gnu/docs/elisp-manual-21/elisp_212.html j'ai pas tout compris -- enfin, peut etre que si, mais peut etre que non -- Bref, faudrait ecrire le code approprié et le vérifier -- )
Je ne sais pas comment te remercier !
C'est du code libre que j'utiliserais probablement un jour, autant que je mette la main à la patte pendant que tu es encore actif sur ce code ; du coup, tu controles directement la coherence globale :-) Je peste tellement contre l'absence de bons logiciels qui permettent de faire facilement des dessins en tex -- Asymptote me plait bien. Lui manque plus qu'une interface à la xfig, la 3d à la gnuplot et un chouia de documentation :-p
Bon, on croise les doigts pour que les bugs partent en vacances -- Amities, Olivier
Ph. Ivaldi
Le 09 juillet 2007, Olivier écrivit :
Peut-être que cette fonctionnalité intéresserait les auteurs de two-mode-mode...
Oui, c'est vrai, tu pourrais leur envoyer un mail pour leur indiquer, ce serait quand meme mieux que cette partie du code se trouve chez eux (attention toutefois, quand on advise trop, on peut se prendre les pieds dans le tapis -- dans le code que j'ai propose, le nom des variables est codé en *dur*, parce que je ne suis pas sûr de comment les coder en souple :-! J'ai bien tout lu mon manuel http://www.delorie.com/gnu/docs/elisp-manual-21/elisp_212.html j'ai pas tout compris -- enfin, peut etre que si, mais peut etre que non -- Bref, faudrait ecrire le code approprié et le vérifier -- )
Je n'ai plus trop le temps de coder souple pour asy-mode... Je viens tout juste d'envoyer la dernière mouture de asy-mode.el avec un support parfait de la coloration syntaxique en mode multiple via une fonction qui "parse" la région à colorer. Du coup il y a séparation totale entre la coloration LaTeX et asy; la bascule de X à Y ne change plus ce qui a déjà été colorier dans X. J'ai fait un petit film (j'aime bien les petits film...) pour expliquer la nouveauté sur Mathematex: ftp://download.tuxfamily.org/piprim/emacs/lasy-mode.mpeg (5Mo)
En revanche, je n'ai pas compris la partie de code suivante: (condition-case nil ad-do-it (error nil))
dans le (defadvice font-lock-fontify-syntactically-region...
Si je la remplace par un simple ad-do-it ça fonctionne aussi bien. Dans le doute je l'ai laissée...
Je ne sais pas comment te remercier !
C'est du code libre que j'utiliserais probablement un jour, autant que je mette la main à la patte pendant que tu es encore actif sur ce code ; du coup, tu controles directement la coherence globale :-)
Il reste encore un problème pour que ce soit vraiment parfait... L'indentation du code interfère d'un mode sur l'autre; dans la majorité des cas cela ne pose heureusement pas de problème... Je n'ai plus le temps de travailler sur asy-mode mais à l'occasion je lancerai un nouveau fil à ce sujet.
Je peste tellement contre l'absence de bons logiciels qui permettent de faire facilement des dessins en tex -- Asymptote me plait bien. Lui manque plus qu'une interface à la xfig, la 3d à la gnuplot et un chouia de documentation :-p
Elle existe, c'est xasy. Je ne l'ai jamais testé mais je sais qu'un étudiant à John Bowman travaille dessus pendant tout l'été; depuis deux semaines il y a des mises à jour quotidiennes de cette interface dans la version SVN.
Encore merci, -- Philippe Ivaldi. http://piprim.tuxfamily.org/
Le 09 juillet 2007, Olivier écrivit :
Peut-être que cette fonctionnalité intéresserait les auteurs de
two-mode-mode...
Oui, c'est vrai, tu pourrais leur envoyer un mail pour leur indiquer,
ce serait quand meme mieux que cette partie du code se trouve chez eux
(attention toutefois, quand on advise trop, on peut se prendre les
pieds dans le tapis -- dans le code que j'ai propose, le nom des
variables est codé en *dur*, parce que je ne suis pas sûr de comment
les coder en souple :-! J'ai bien tout lu mon manuel
http://www.delorie.com/gnu/docs/elisp-manual-21/elisp_212.html j'ai
pas tout compris -- enfin, peut etre que si, mais peut etre que non --
Bref, faudrait ecrire le code approprié et le vérifier -- )
Je n'ai plus trop le temps de coder souple pour asy-mode...
Je viens tout juste d'envoyer la dernière mouture de asy-mode.el avec un
support parfait de la coloration syntaxique en mode multiple via une
fonction qui "parse" la région à colorer.
Du coup il y a séparation totale entre la coloration LaTeX et asy; la
bascule de X à Y ne change plus ce qui a déjà été colorier dans X.
J'ai fait un petit film (j'aime bien les petits film...) pour expliquer
la nouveauté sur Mathematex:
ftp://download.tuxfamily.org/piprim/emacs/lasy-mode.mpeg (5Mo)
En revanche, je n'ai pas compris la partie de code suivante:
(condition-case nil
ad-do-it
(error nil))
dans le (defadvice font-lock-fontify-syntactically-region...
Si je la remplace par un simple ad-do-it ça fonctionne aussi bien.
Dans le doute je l'ai laissée...
Je ne sais pas comment te remercier !
C'est du code libre que j'utiliserais probablement un jour, autant
que je mette la main à la patte pendant que tu es encore actif sur
ce code ; du coup, tu controles directement la coherence globale
:-)
Il reste encore un problème pour que ce soit vraiment parfait...
L'indentation du code interfère d'un mode sur l'autre; dans la majorité
des cas cela ne pose heureusement pas de problème...
Je n'ai plus le temps de travailler sur asy-mode mais à l'occasion je
lancerai un nouveau fil à ce sujet.
Je peste tellement contre l'absence de bons logiciels qui permettent
de faire facilement des dessins en tex --
Asymptote me plait bien.
Lui manque plus qu'une interface à la xfig, la 3d à la gnuplot
et un chouia de documentation :-p
Elle existe, c'est xasy.
Je ne l'ai jamais testé mais je sais qu'un étudiant à John Bowman
travaille dessus pendant tout l'été; depuis deux semaines il y a des
mises à jour quotidiennes de cette interface dans la version SVN.
Encore merci,
--
Philippe Ivaldi.
http://piprim.tuxfamily.org/
Peut-être que cette fonctionnalité intéresserait les auteurs de two-mode-mode...
Oui, c'est vrai, tu pourrais leur envoyer un mail pour leur indiquer, ce serait quand meme mieux que cette partie du code se trouve chez eux (attention toutefois, quand on advise trop, on peut se prendre les pieds dans le tapis -- dans le code que j'ai propose, le nom des variables est codé en *dur*, parce que je ne suis pas sûr de comment les coder en souple :-! J'ai bien tout lu mon manuel http://www.delorie.com/gnu/docs/elisp-manual-21/elisp_212.html j'ai pas tout compris -- enfin, peut etre que si, mais peut etre que non -- Bref, faudrait ecrire le code approprié et le vérifier -- )
Je n'ai plus trop le temps de coder souple pour asy-mode... Je viens tout juste d'envoyer la dernière mouture de asy-mode.el avec un support parfait de la coloration syntaxique en mode multiple via une fonction qui "parse" la région à colorer. Du coup il y a séparation totale entre la coloration LaTeX et asy; la bascule de X à Y ne change plus ce qui a déjà été colorier dans X. J'ai fait un petit film (j'aime bien les petits film...) pour expliquer la nouveauté sur Mathematex: ftp://download.tuxfamily.org/piprim/emacs/lasy-mode.mpeg (5Mo)
En revanche, je n'ai pas compris la partie de code suivante: (condition-case nil ad-do-it (error nil))
dans le (defadvice font-lock-fontify-syntactically-region...
Si je la remplace par un simple ad-do-it ça fonctionne aussi bien. Dans le doute je l'ai laissée...
Je ne sais pas comment te remercier !
C'est du code libre que j'utiliserais probablement un jour, autant que je mette la main à la patte pendant que tu es encore actif sur ce code ; du coup, tu controles directement la coherence globale :-)
Il reste encore un problème pour que ce soit vraiment parfait... L'indentation du code interfère d'un mode sur l'autre; dans la majorité des cas cela ne pose heureusement pas de problème... Je n'ai plus le temps de travailler sur asy-mode mais à l'occasion je lancerai un nouveau fil à ce sujet.
Je peste tellement contre l'absence de bons logiciels qui permettent de faire facilement des dessins en tex -- Asymptote me plait bien. Lui manque plus qu'une interface à la xfig, la 3d à la gnuplot et un chouia de documentation :-p
Elle existe, c'est xasy. Je ne l'ai jamais testé mais je sais qu'un étudiant à John Bowman travaille dessus pendant tout l'été; depuis deux semaines il y a des mises à jour quotidiennes de cette interface dans la version SVN.
Encore merci, -- Philippe Ivaldi. http://piprim.tuxfamily.org/
En revanche, je n'ai pas compris la partie de code suivante: (condition-case nil ad-do-it (error nil))
dans le (defadvice font-lock-fontify-syntactically-region...
Le problème vient de font-lock. Les bornes start et end allouées à font-lock-fontify-syntactically-region et consorts ne sont pas vraiment respectées : typiquement ces fontions fontifient à partir d'une ligne avant le start et à partir du début de ligne et jusqu'à la fin de ligne d'après le end. Mais le narrow-to-region interdit toute modification hors du cadre prescrit. Du coup, ces fonctions envoient (parfois) des erreurs. Le condition-case attrape ces erreurs et ne les relaie pas : il les noie tout simplement :-) C'est le nil après le error.
Evidemment, cela peut rendre difficile un débugage ultérieur, les messages d'erreurs étaient justement là pour aider :-( Bon, bon, voilà. Si le narrow-to-region limitait aussi les previous-line, forward-line, begining-of-line et end-of-line, on n'aurait pas besoin de cela, mais en fait la region limitée par ce narrowing n'est pas vraiment un autre buffer. Donc une autre solution couteuse serait de copier l'environnement asy dans un autre buffer, un vrai, de colorier ce buffer et de le recopier avec les text-properties dans le buffer initial :-( Mais tu imagines déjà les galères de la double gestion --
Si je la remplace par un simple ad-do-it ça fonctionne aussi bien. Dans le doute je l'ai laissée...
Oui, ça dépend de ce que trouve font-lock, il faut le laisser.
[...]
Elle existe, c'est xasy. Je ne l'ai jamais testé mais je sais qu'un étudiant à John Bowman travaille dessus pendant tout l'été; depuis deux semaines il y a des mises à jour quotidiennes de cette interface dans la version SVN.
En revanche, je n'ai pas compris la partie de code suivante:
(condition-case nil
ad-do-it
(error nil))
dans le (defadvice font-lock-fontify-syntactically-region...
Le problème vient de font-lock.
Les bornes start et end allouées à
font-lock-fontify-syntactically-region et consorts ne sont pas
vraiment respectées : typiquement ces fontions fontifient à partir
d'une ligne avant le start et à partir du début de ligne et jusqu'à
la fin de ligne d'après le end.
Mais le narrow-to-region interdit toute modification hors du cadre
prescrit. Du coup, ces fonctions envoient (parfois) des erreurs.
Le condition-case attrape ces erreurs et ne les relaie pas :
il les noie tout simplement :-) C'est le nil après le error.
Evidemment, cela peut rendre difficile un débugage ultérieur,
les messages d'erreurs étaient justement là pour aider :-(
Bon, bon, voilà.
Si le narrow-to-region limitait aussi les previous-line,
forward-line, begining-of-line et end-of-line, on n'aurait pas
besoin de cela, mais en fait la region limitée par ce narrowing
n'est pas vraiment un autre buffer. Donc une autre solution couteuse
serait de copier l'environnement asy dans un autre buffer, un vrai,
de colorier ce buffer et de le recopier avec les text-properties
dans le buffer initial :-( Mais tu imagines déjà les galères de la
double gestion --
Si je la remplace par un simple ad-do-it ça fonctionne aussi bien.
Dans le doute je l'ai laissée...
Oui, ça dépend de ce que trouve font-lock, il faut le laisser.
[...]
Elle existe, c'est xasy.
Je ne l'ai jamais testé mais je sais qu'un étudiant à John Bowman
travaille dessus pendant tout l'été; depuis deux semaines il y a des
mises à jour quotidiennes de cette interface dans la version SVN.
En revanche, je n'ai pas compris la partie de code suivante: (condition-case nil ad-do-it (error nil))
dans le (defadvice font-lock-fontify-syntactically-region...
Le problème vient de font-lock. Les bornes start et end allouées à font-lock-fontify-syntactically-region et consorts ne sont pas vraiment respectées : typiquement ces fontions fontifient à partir d'une ligne avant le start et à partir du début de ligne et jusqu'à la fin de ligne d'après le end. Mais le narrow-to-region interdit toute modification hors du cadre prescrit. Du coup, ces fonctions envoient (parfois) des erreurs. Le condition-case attrape ces erreurs et ne les relaie pas : il les noie tout simplement :-) C'est le nil après le error.
Evidemment, cela peut rendre difficile un débugage ultérieur, les messages d'erreurs étaient justement là pour aider :-( Bon, bon, voilà. Si le narrow-to-region limitait aussi les previous-line, forward-line, begining-of-line et end-of-line, on n'aurait pas besoin de cela, mais en fait la region limitée par ce narrowing n'est pas vraiment un autre buffer. Donc une autre solution couteuse serait de copier l'environnement asy dans un autre buffer, un vrai, de colorier ce buffer et de le recopier avec les text-properties dans le buffer initial :-( Mais tu imagines déjà les galères de la double gestion --
Si je la remplace par un simple ad-do-it ça fonctionne aussi bien. Dans le doute je l'ai laissée...
Oui, ça dépend de ce que trouve font-lock, il faut le laisser.
[...]
Elle existe, c'est xasy. Je ne l'ai jamais testé mais je sais qu'un étudiant à John Bowman travaille dessus pendant tout l'été; depuis deux semaines il y a des mises à jour quotidiennes de cette interface dans la version SVN.
Excellent ! Je vais tester ça ! Amities, Olivier
Ph. Ivaldi
Le 11 juillet 2007, Olivier écrivit :
Le problème vient de font-lock. Les bornes start et end allouées à font-lock-fontify-syntactically-region et consorts ne sont pas vraiment respectées : typiquement ces fontions fontifient à partir d'une ligne avant le start et à partir du début de ligne et jusqu'à la fin de ligne d'après le end.
Je comprends... les fonctions contenues dans la liste `font-lock-extend-region-functions' sont là pour étendre la région.
Mais le narrow-to-region interdit toute modification hors du cadre [...]
Merci pour cette explication limpide.
Elle existe, c'est xasy. [...]
Excellent ! Je vais tester ça !
J'ai regardé la documentation d'Asymptote à ce propos:
,---- | The rudimentary GUI xasy included with the package allows one to move | script-generated objects around. To make Asymptote accessible to the | average user, this GUI is currently being developed into a | full-fledged interface that can generate objects directly. `----
J'ai fait un petit test... c'est encore "very rudimentary"... -- Amicalement, Philippe Ivaldi. http://piprim.tuxfamily.org/
Le 11 juillet 2007, Olivier écrivit :
Le problème vient de font-lock.
Les bornes start et end allouées à
font-lock-fontify-syntactically-region et consorts ne sont pas
vraiment respectées : typiquement ces fontions fontifient à partir
d'une ligne avant le start et à partir du début de ligne et jusqu'à
la fin de ligne d'après le end.
Je comprends... les fonctions contenues dans la liste
`font-lock-extend-region-functions' sont là pour étendre la région.
Mais le narrow-to-region interdit toute modification hors du cadre
[...]
Merci pour cette explication limpide.
Elle existe, c'est xasy.
[...]
Excellent ! Je vais tester ça !
J'ai regardé la documentation d'Asymptote à ce propos:
,----
| The rudimentary GUI xasy included with the package allows one to move
| script-generated objects around. To make Asymptote accessible to the
| average user, this GUI is currently being developed into a
| full-fledged interface that can generate objects directly.
`----
J'ai fait un petit test... c'est encore "very rudimentary"...
--
Amicalement,
Philippe Ivaldi.
http://piprim.tuxfamily.org/
Le problème vient de font-lock. Les bornes start et end allouées à font-lock-fontify-syntactically-region et consorts ne sont pas vraiment respectées : typiquement ces fontions fontifient à partir d'une ligne avant le start et à partir du début de ligne et jusqu'à la fin de ligne d'après le end.
Je comprends... les fonctions contenues dans la liste `font-lock-extend-region-functions' sont là pour étendre la région.
Mais le narrow-to-region interdit toute modification hors du cadre [...]
Merci pour cette explication limpide.
Elle existe, c'est xasy. [...]
Excellent ! Je vais tester ça !
J'ai regardé la documentation d'Asymptote à ce propos:
,---- | The rudimentary GUI xasy included with the package allows one to move | script-generated objects around. To make Asymptote accessible to the | average user, this GUI is currently being developed into a | full-fledged interface that can generate objects directly. `----
J'ai fait un petit test... c'est encore "very rudimentary"... -- Amicalement, Philippe Ivaldi. http://piprim.tuxfamily.org/
