Commentaire réservé
lionmarron
où je ne suis pas encore couché tout au moins).
Pourquoi n'existe-t-il pas de commentaires réservés ? Il s'agirait de
commentaires qui ne sont pas écrit par le programmeur mais par le
compilateur.
Cela permettrait d'avoir un code source à la fois plus moins loquace
(sur le plan de ce qu'on écrit) et plus loquace (sur le plan de ce
qu'on lit). Ce qui devrait être plus rapide à corriger.
Par exemple au lieu d'écrire :
\section{a} bla bla
\section{b} bla bla
\subsection{n} bla bla
\subsection{m} bla bla
on écrirait :
\section{a} bla bla
\sectionnement{b} bla bla
\ssectionnement{n} bla bla
\sectionnement{m} bla bla
C'est moins loquace parce que \sectionnement et \ssectionnement
n'indiquent pas à quel niveau de l'arborescence on se trouve,
seulement si reste au même niveau ou si on descend dans cette
arborescence. Et après une première compilation, les commentaires
réservés indiqueraient le vrai niveau d'arborescence.
Ils pourraient indiquer également les numéros d'item par exemple.
Bon, si par hasard les commentaires réservés existent déjà, ou si
quelqu'un de plus qualifié avait déjà l'intention de suggérer cette
idée (liste non close), ne pas tenir compte de ce message.
A.H.
Jean-Côme Charpentier
> Une id�e comme je ne peux en avoir que le lundi matin (un lundi matin
> o� je ne suis pas encore couch� tout au moins).
>
> Pourquoi n'existe-t-il pas de commentaires r�serv�s ? Il s'agirait de
> commentaires qui ne sont pas �crit par le programmeur mais par le
> compilateur.
Aaaargggl ! C'est une id�e absolument horrible ! Je ne veux *surtout*
pas que le compilateur commence � tripoter mon code source. D'ailleurs,
strictement parlant, s'il le faisait, ce ne serait pas un compilateur.
Aucun compilateur ne touche le code source. Je ne vois que des
d�savantages � faire ainsi... cela veut aussi dire que je ne vois
strictement aucun avantage.
> Cela permettrait d'avoir un code source � la fois plus moins loquace
> (sur le plan de ce qu'on �crit) et plus loquace (sur le plan de ce
> qu'on lit). Ce qui devrait �tre plus rapide � corriger.
??? J'ai un (gros) doute sur cette affirmation.
> Par exemple au lieu d'�crire :
>
> \section{a} bla bla
> \section{b} bla bla
> \subsection{n} bla bla
> \subsection{m} bla bla
>
> on �crirait :
>
> \section{a} bla bla
> \sectionnement{b} bla bla
> \ssectionnement{n} bla bla
> \sectionnement{m} bla bla
>
> C'est moins loquace parce que \sectionnement et \ssectionnement
> n'indiquent pas � quel niveau de l'arborescence on se trouve,
> seulement si reste au m�me niveau ou si on descend dans cette
> arborescence.
Heuuu. Si j'ai bien suivi l'histoire, ce pr�tendu avantage (je ne vois
pas tellement l'avantage) ne serait valable qu'avant la premi�re
compilation. Une fois cette premi�re compilation effectu�e, on aurait le
source avec des \section et \subsection et les \sectionnement et
compagnie serait totalement perdus.
Apr�s tout, �a existe bien avec les tailles de fontes, pourquoi pas
avec les niveaux de sectionnement. Personnellement bof... mais bon,
c'est juste personnel.
> Et apr�s une premi�re compilation, les commentaires
> r�serv�s indiqueraient le vrai niveau d'arborescence.
>
> Ils pourraient indiquer �galement les num�ros d'item par exemple.
Et si on ajoute un item apr�s la cinqui�me compilation, que doit
afficher le source ?
> Bon, si par hasard les commentaires r�serv�s existent d�j�,
Si un tel outil propose se genre de chose, il ira directement dans la
poubelle et comme je fais des rm, il ne passera m�me pas dans la
poubelle :-)
> ou si
> quelqu'un de plus qualifi� avait d�j� l'intention de sugg�rer cette
> id�e (liste non close), ne pas tenir compte de ce message.
Je sugg�re plut�t :
* de configurer l'�diteur de texte pour qu'il fasse ce genre de
remplacement automatique (j'ai horreur de �a mais cela peut toujours
s�duire)
* de balancer des messages au niveau du rapport de compilation
* de se faire ses propres macros \sectionnement pour qu'elles aient le
comportement d�sir� sans avoir � changer de nom (je ne vois vraiment pas
l'int�r�t de se servir de telles macros si elles doivent dispara�tre �
la premi�re compilation)
Si l'id�e est de faire des commentaires (et pas des remplacements de
code) alors laisser tomber la derni�re id�e et se rabattre sur les deux
premi�res.
Voil�, c'est mon sentiment et je le partage avec une certaine
v�h�mence :-)
Jean-C�me Charpentier
--
Ben, il s'appelle *PS*tricks, quand m�me, pas
JE_MARCHE_AVEC_TOUTES_LES_CHAINES_DE_TRAITEMENTS_tricks. Il me semble
que c'est suffisamment clair !
-+- Denis L. in fr.comp.text.tex -+-
lionmarron
Come.Charpent...@wanadoo.fr> wrote:
> Heuuu. Si j'ai bien suivi l'histoire, ce prétendu avantage (je ne vois
> pas tellement l'avantage) ne serait valable qu'avant la première
> compilation.
Ce n'est pas ça non, mais de la part de notre ami Jean-Côme je savais
qu'on peut s'attendre à une bonne compréhension de TeX (ou autre),
mais plus rarement à la bonne compréhension d'un message.
> Une fois cette première compilation effectuée, on aurait le
> source avec des \section et \subsection et les \sectionnement et
> compagnie serait totalement perdus.
Toujours pas non, ce n'ai pas ce que j'ai écrit, mais il est vrai que
j'aurais pu être plus précis. Pour que les explications ne soient pas
trop abstraites, ou difficiles à formuler, cela oblige à faire des
choix qui ne sont pas dans le sujet (parce qu'ils seront arbitraires),
mais après tout c'est peut-être mieux.
Je reprends mon exemple en montrant avant et après compilation.
Avant compilation on aurait :
\section{a} bla bla
\sectionnement{b} bla bla
\ssectionnement{n} bla bla
\sectionnement{m} bla bla
Après compilation :
\section{a} bla bla
\sectionnement[section]{b} bla bla
\ssectionnement[subsection]{n} bla bla
\sectionnement[subsection]{m} bla bla
Les commentaires réservés ont été ajouté entre crochet, et entre la
commande et l'argument ; c'est un choix, mais il s'agit d'un exemple.
En revanche, prévoyant que maintenant je vais recevoir un message où
notre ami expliquera qu'à chaque compilation il y aura une couche
supplémentaire de commentaires réservés, je précise que les
commentaires de chaque compilation écraseraient ceux de la précédente.
> Et si on ajoute un item après la cinquième compilation, que doit
> afficher le source ?
Que la compilation soit la première ou la x-ième ne change donc rien
sur ce plan là.
Ces précisions étant faites, j'espère que mon maitre vénéré excusera
les audaces de la pensée téméraire de son admirateur (souvent rempli
d'une confusion surnaturelle et bien compréhensible, lorsqu'il
considère sa condition de simple mortel dans l'éblouissante lumière du
dieu Knuth).
A.H.
Jean-Côme Charpentier
> On 23 nov, 14:45, Jean-C�me Charpentier <Jean-
> Come.Charpent...@wanadoo.fr> wrote:
>
>> Heuuu. Si j'ai bien suivi l'histoire, ce pr�tendu avantage (je ne vois
>> pas tellement l'avantage) ne serait valable qu'avant la premi�re
>> compilation.
>
> Ce n'est pas �a non, mais de la part de notre ami Jean-C�me je savais
> qu'on peut s'attendre � une bonne compr�hension de TeX (ou autre),
> mais plus rarement � la bonne compr�hension d'un message.
Je suis dur de la comprennette ? C'est �a ? Ou bien j'ai encore mal
compris le message ?
> []
> Je reprends mon exemple en montrant avant et apr�s compilation.
>
> Avant compilation on aurait :
>
> \section{a} bla bla
> \sectionnement{b} bla bla
> \ssectionnement{n} bla bla
> \sectionnement{m} bla bla
>
> Apr�s compilation :
>
> \section{a} bla bla
> \sectionnement[section]{b} bla bla
> \ssectionnement[subsection]{n} bla bla
> \sectionnement[subsection]{m} bla bla
Ce n'est donc pas ce qui �tait montr� dans le message d'origine.
Je me r�p�te :
1. Je ne vois pas l'int�r�t mais c'est tout � fait personnel et
n'importe qui a le droit de ne pas �tre d'accord avec moi, je ne m'en
offusquerai pas.
2. Ce type de modification ne peut pas (ne doit pas) �tre effectu� par
le compilateur et l�, je serai un peu mois indulgent avec ceux qui
pensent le contraire mais je pr�cise tout de suite que je n'ai jamais
tu� personne.
3. Une des solutions que je pr�conisais, � savoir de d�l�guer ce type
de travail � l'�diteur tient toujours.
> Les commentaires r�serv�s ont �t� ajout� entre crochet, et entre la
> commande et l'argument ; c'est un choix, mais il s'agit d'un exemple.
Effectivement, tant qu'� faire, je pr�f�rerais une pr�sentation du type :
\section{a} bla bla
\sectionnement{b} bla bla %%% section
\ssectionnement{n} bla bla %%% subsection
\sectionnement{m} bla bla %%% subsection
Ce serait plus simple pour LaTeX et surtout, cela pourrait permettre
d'utiliser le param�tre optionnel des commandes de sectionnement. �
minima, il faudrait quand m�me que \sectionnement et compagnie ait la
m�me syntaxe d'appel que \section et compagnie.
> [...]
> Ces pr�cisions �tant faites, j'esp�re que mon maitre v�n�r� excusera
> les audaces de la pens�e t�m�raire de son admirateur (souvent rempli
> d'une confusion surnaturelle et bien compr�hensible, lorsqu'il
> consid�re sa condition de simple mortel dans l'�blouissante lumi�re du
> dieu Knuth).
Il vous excuse :-)
Jean-C�me Charpentier
--
J'ai tout int�r�t moi aussi � ce que mes messages soient utiles et
informatifs (sauf le vendredi).
-+- Joss in fr.comp.text.tex -+-
lionmarron
> Pourquoi n'existe-t-il pas de commentaires réservés ? Il s'agirait de
> commentaires qui ne sont pas écrit par le programmeur mais par le
> compilateur.
>
> Cela permettrait d'avoir un code source à la fois plus moins loquace
> (sur le plan de ce qu'on écrit) et plus loquace (sur le plan de ce
> qu'on lit). Ce qui devrait être plus rapide à corriger.
Bon, je reprends l'ensemble de mes explications en tenant compte cette
fois des remarques de Jean-Côme.
L'exemple choisi est qu'au lieu d'écrire :
\section{a} bla bla
\section{b} bla bla
\subsection{n} bla bla
\subsection{m} bla bla
on écrirait :
\section{a} bla bla
\sectionnement{b} bla bla
\ssectionnement{n} bla bla
\sectionnement{m} bla bla
C'est moins loquace parce que \sectionnement et \ssectionnement
n'indiquent pas à quel niveau de l'arborescence on se trouve,
seulement si reste au même niveau ou si on descend dans cette
arborescence. Et après une première compilation, les commentaires
réservés indiqueraient le vrai niveau d'arborescence.
Après compilation on pourrait avoir par exemple ceci :
\section{a} bla bla
\sectionnement/section/{b} bla bla
\ssectionnement/subsection/{n} bla bla
\sectionnement/subsection/{m} bla bla
Les commentaires réservés ont été ajouté entre deux < / > plutôt
qu'entre crochets, pour éviter la confusion avec un paramètre
optionnel. (Et plutôt qu'après un ou plusieurs < % >, ceux-ci étant
déjà utilisés pour les commentaires normaux.)
Il s'agit évidemment d'un exemple parmi d'autres choix syntaxiques
possible.
Bien sûr, les commentaires réservés de chaque compilation écraseraient
ceux de la compilation précédente.
Bon voilà.
Par ailleurs les solutions proposées par Jean-Côme me semblent
intéressantes mais je ne crois pas qu'elles soient réalisable avec mon
éditeur (WinEdt), et je ne suis pas sûr qu'elles reviennent vraiment
au même (j'ai l'impression que ça doit être plus compliqué). Bon cela
dit, j'y réfléchirai peut-être si un jour j'ai un autre éditeur.
A.H.
Paul Gaborit
� (at) Mon, 23 Nov 2009 21:37:51 -0800 (PST),
lionmarron <andre....@gmail.com> �crivait (wrote):
> on �crirait :
>
> \section{a} bla bla
> \sectionnement{b} bla bla
> \ssectionnement{n} bla bla
> \sectionnement{m} bla bla
>
> C'est moins loquace parce que \sectionnement et \ssectionnement
> n'indiquent pas � quel niveau de l'arborescence on se trouve,
> seulement si reste au m�me niveau ou si on descend dans cette
> arborescence. Et apr�s une premi�re compilation, les commentaires
> r�serv�s indiqueraient le vrai niveau d'arborescence.
Et comment fait-on pour remonter ? Il ne faut pas oublier qu'a priori,
on ne descend que d'un cran � chaque fois mais qu'on peut remonter de
plusieurs crans d'un coup...
Dans les bons �diteurs, il y a des raccourcis (ou des commandes) pour
d�caler d'un cran (vers le bas ou vers le haut) toutes les commandes
LaTeX de sectionnement d'une partie du texte.
J'avoue que, comme Jean-C�me, j'ai du mal � voir l'int�r�t de votre
proposition.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Pétiard François
>> commentaires qui ne sont pas �crit par le programmeur mais par le
>> compilateur.
>>
>> Cela permettrait d'avoir un code source � la fois plus moins loquace
>> (sur le plan de ce qu'on �crit) et plus loquace (sur le plan de ce
>> qu'on lit). Ce qui devrait �tre plus rapide � corriger.
>
<couic>
>
> Par ailleurs les solutions propos�es par Jean-C�me me semblent
> int�ressantes mais je ne crois pas qu'elles soient r�alisable avec mon
> �diteur (WinEdt), et je ne suis pas s�r qu'elles reviennent vraiment
> au m�me (j'ai l'impression que �a doit �tre plus compliqu�). Bon cela
> dit, j'y r�fl�chirai peut-�tre si un jour j'ai un autre �diteur.
>
Je ne comprends pas : avec WinEdt, en construisant l'arborescence du
document (Build Tree), on voit appara�tre toutes les commandes de
sectionnement dans une fen�tre...
Fran�ois
--
Ce qui laisse un peu de doute : autant on est s�r que Knuth est Dieu
autant pour Zapf, il faut attendre un proph�te... Seras-tu l'�lu,
Neo ? ;-)
lionmarron
> Et comment fait-on pour remonter ? Il ne faut pas oublier qu'a priori,
> on ne descend que d'un cran à chaque fois mais qu'on peut remonter de
> plusieurs crans d'un coup...
J'ai pris pour exemple une instruction qui descendait d'un cran, mais
ce n'est qu'un exemple.
Au lieu de \ssectionnement j'aurais d'ailleur mieux fait de prendre
\dsectionnement (d pour descendre) et il aurait été possible d'ajouter
\rsectionnement pour remonter d'un cran, \rrsectionnement pour
remonter de deux crans, etc.
> Dans les bons éditeurs, il y a des raccourcis (ou des commandes) pour
> décaler d'un cran (vers le bas ou vers le haut) toutes les commandes
> LaTeX de sectionnement d'une partie du texte.
Je l'ignorais parce que j'utilise WinEdt sans pouvoir comprendre son
mode d'emploi en anglais. Maintenant si on me dit que ça existe, à
force de chercher je finirai bien par trouver. Donc merci pour la
réponse.
A.H.
lionmarron
<petiard.point.francois@_at_free.point.fr> wrote:
> Je ne comprends pas : avec WinEdt, en construisant l'arborescence du
> document (Build Tree), on voit apparaître toutes les commandes de
> sectionnement dans une fenêtre...
>
Je n'ai pas encore trouvé, mais juste à l'instant je viens de faire
une formidable découverte (plus lourde de conséquences à mon avis) ;
dans le menu Accessories, en cliquant sur DVI Search, on est envoyé à
l'endroit du dvi qui correspond à celui où se trouve le curseur dans
le source.
Ce n'est pas forcément nouveau pour tout le monde d'accord.
Alain Ketterlin
> Pourquoi n'existe-t-il pas de commentaires réservés ? Il s'agirait de
> commentaires qui ne sont pas écrit par le programmeur mais par le
> compilateur.
Pour les raisons qu'explique Jean-Côme, il est très important que le
compilateur ne touche pas au fichier source (sinon, bye bye make, les
gestionnaires de version, etc., et sûrement bye bye la santé mentale du
rédacteur).
Après tout, il suffit de regarder le résultat pour avoir les numéros.
Ou, comme dit Paul, d'avoir un éditeur qui les indique.
> Par exemple au lieu d'écrire :
>
> \section{a} bla bla
> \section{b} bla bla
> \subsection{n} bla bla
> \subsection{m} bla bla
>
> on écrirait :
>
> \section{a} bla bla
> \sectionnement{b} bla bla
> \ssectionnement{n} bla bla
> \sectionnement{m} bla bla
Ca va pas marcher, mais on pourrait avoir :
\begin{sectionnement}{a}
\begin{sectionnement}{n}
...
\end{sectionnement}
\begin{sectionnement}{m}
...
\end{sectionnement}
\end{sectionnement}
Le débat a fait rage longtemps dans la communauté DocBook, pour
finalement déboucher sur l'inclusion des deux formes, l'une explicite
(sect1, sect2, etc.) l'autre implicite (section). La seconde forme est
surtout utile quand un document se retrouve inclus dans plusieurs
autres, éventuellement à différents niveaux.
Perso, dans LaTeX, je trouverais cela plus cohérent d'avoir des sections
sous forme d'environnement, mais évidemment, c'est plus lourd à saisir
quand on n'a pas un éditeur performant.
-- Alain.
lionmarron
> lionmarron <andre.het...@gmail.com> writes:
> > Pourquoi n'existe-t-il pas de commentaires réservés ? Il s'agirait de
> > commentaires qui ne sont pas écrit par le programmeur mais par le
> > compilateur.
>
> Pour les raisons qu'explique Jean-Côme, il est très important que le
> compilateur ne touche pas au fichier source (sinon, bye bye make, les
> gestionnaires de version, etc., et sûrement bye bye la santé mentale du
> rédacteur).
Ce que le compilateur ajouterait est court et constitue seulement du
commentaire (même si c'est une catégorie particulière de commentaire).
Dans ces conditions je ne vois pas pourquoi cela poserait un problème.
A propos des gestionnaires de version ou du reste je ne vois pas le
problème, si un langage a été conçu pour ça dès le départ. La seule
chose qui ne doit pas varier concerne la façon d'identifier les
commentaires, le reste peut évoluer pareil (enfin j'aurais cru).
Evidemment comme Latex est déjà conçu, et si toutefois on suppose que
l'idée présente un intérêt, c'est peut-être trop tard pour y penser.
C'est plutôt si on parle d'un langage non encore fixé que je ne vois
en quoi cela devrait poser un problème. (Je n'ai pas l'intention
d'essayer de le coder cela étant.)
A.H.
Alain Ketterlin
> Ce que le compilateur ajouterait est court et constitue seulement du
> commentaire (même si c'est une catégorie particulière de commentaire).
> Dans ces conditions je ne vois pas pourquoi cela poserait un problème.
Le problème n'est pas la "quantité", mais le fait que le source change,
que le fichier après compilation n'est pas le même que le fichier avant
compilation. C'est pour cela qu'à ma connaissance, cela n'existe pas.
> A propos des gestionnaires de version ou du reste je ne vois pas le
> problème, si un langage a été conçu pour ça dès le départ. La seule
> chose qui ne doit pas varier concerne la façon d'identifier les
> commentaires, le reste peut évoluer pareil (enfin j'aurais cru).
Le fichier source change. Point. Les gestionnaires de version, les
outils, etc. voient une nouvelle version du source. Sauf à les
développer spécifiquement pour le langage en question.
> Evidemment comme Latex est déjà conçu, et si toutefois on suppose que
> l'idée présente un intérêt, c'est peut-être trop tard pour y penser.
Sûrement, mais encore une fois, l'idée ne présente aucun intérêt, et des
tas d'inconvénients. Il vaut mieux faire confiance aux éditeurs pour
faire une partie du boulot du compilo pour te donner ces infos (en
croisant les doigts pour que tout soit cohérent).
Le mieux que tu puisses espérer est que le compilateur produise _un
autre fichier_ qui contiendrait les indications que tu veux (par exemple
un éditeur qui lirait le fichier .aux pour te mettre dans une bulle la
valeur d'un \ref{...}), quelque chose comme les tags de emacs/vi mais
spécifique au langage.
-- Alain.
Manuel Pégourié-Gonnard
> Le probl�me n'est pas la "quantit�", mais le fait que le source change,
> que le fichier apr�s compilation n'est pas le m�me que le fichier avant
> compilation. C'est pour cela qu'� ma connaissance, cela n'existe pas.
>
+1 Mon source, c'est moi qui l'�crit avec amour et un bon �diteur,
personne d'autre n'y touche sinon je grogne.
> Le fichier source change. Point. Les gestionnaires de version, les
> outils, etc. voient une nouvelle version du source. Sauf � les
> d�velopper sp�cifiquement pour le langage en question.
>
+1 Un source, c'est du texte et c'est tout. Je ne veux pas que mes
gestionnaires de version s'amusent � essayer de comprendre sa structure
et � faire les malins avec.
>> Evidemment comme Latex est d�j� con�u, et si toutefois on suppose que
>> l'id�e pr�sente un int�r�t, c'est peut-�tre trop tard pour y penser.
>
Oui. Il n'y a rien dans TeX qui permette de garantir que quelque chose
est un commentaire. Tout d�pend trop des circonstances.
> Le mieux que tu puisses esp�rer est que le compilateur produise _un
> autre fichier_ qui contiendrait les indications que tu veux (par exemple
> un �diteur qui lirait le fichier .aux pour te mettre dans une bulle la
> valeur d'un \ref{...}), quelque chose comme les tags de emacs/vi mais
> sp�cifique au langage.
>
D'ailleurs, je suis surpris qu'aucun Emacsien n'ai d�barqu� depuis le
d�but de la discussion en disant � de toutes fa�ons Emacs le fait �[1].
La derni�re fois qu'on a essay� de me convernir � Emacs (et comme
c'�tait David Kastrup, un mainteneur enthousiaste d'AucTeX, il avait
failli y arriver, au moins pour le TeX), il me semble qu'on m'avait jet�
au visage une fonctionnalit� de ce genre. Pas le truc de \ssectionement,
mais afficher les num�ros des sections et des r�f�rences dans le source
apr�s la premi�re compilation.
--
Manuel P�gouri�-Gonnard Institut de math�matiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Thomas vO
� (at) Tue, 24 Nov 2009 13:09:57 +0100 (CET),
Manuel P�gouri�-Gonnard <m...@elzevir.fr> nous disait (told us):
> D'ailleurs, je suis surpris qu'aucun Emacsien n'ai d�barqu� depuis
> le d�but de la discussion en disant � de toutes fa�ons Emacs le fait
> �[1]. La derni�re fois qu'on a essay� de me convernir � Emacs (et
> comme c'�tait David Kastrup, un mainteneur enthousiaste d'AucTeX, il
> avait failli y arriver, au moins pour le TeX) [...]
j'attrape ce bout de fil vendrediesque, juste pour dire que je m'y
suis mis... je n'utilise plus emacs que pour LaTeX (pour rebondir sur
une vieille discussion, emacs me sert pour les .tex ET les .sty ;) )
et gnus...
au passage, si quelqu'un conna�t le truc qu'il faut faire sous vim
pour avoir l'�quivalent de M-q sur emacs, �a m'int�resse !
--
Comparer WEB � un DTX, c'est un peu comme comparer un Riesling � du jus
de raisin, quand m�me. Notamment un DTX reste lin�aire.
Paul Gaborit
� (at) Tue, 24 Nov 2009 13:09:57 +0100 (CET),
> D'ailleurs, je suis surpris qu'aucun Emacsien n'ai d�barqu� depuis le
> d�but de la discussion en disant � de toutes fa�ons Emacs le fait �[1].
Je l'ai dit... mais de mani�re sournoise. J'attendais vendredi pour
�tre plus vindicatif ! ;-)
Paul Gaborit
� (at) Tue, 24 Nov 2009 14:10:06 +0100,
Thomas vO <vanoud...@rf.esuoluot-vinu.invalid> �crivait (wrote):
> j'attrape ce bout de fil vendrediesque, juste pour dire que je m'y
> suis mis... je n'utilise plus emacs que pour LaTeX (pour rebondir sur
> une vieille discussion, emacs me sert pour les .tex ET les .sty ;) )
> et gnus...
Tra�tre ! ;-)
Manuel Pégourié-Gonnard
> au passage, si quelqu'un conna�t le truc qu'il faut faire sous vim
> pour avoir l'�quivalent de M-q sur emacs, �a m'int�resse !
>
C'est quoi, M-q ?
Paul Gaborit
� (at) Tue, 24 Nov 2009 14:51:34 +0100 (CET),
Manuel P�gouri�-Gonnard <m...@elzevir.fr> �crivait (wrote):
> Thomas vO scripsit :
>
>> au passage, si quelqu'un conna�t le truc qu'il faut faire sous vim
>> pour avoir l'�quivalent de M-q sur emacs, �a m'int�resse !
>>
> C'est quoi, M-q ?
Sur emacs, par d�faut, cela active la commande 'fill-paragraph' qui
permet de formater un paragraphe de texte pour que ses lignes ne
d�passent pas la longueur maximale d'une ligne (72 caract�res par
d�faut).
Si on ne l'utilise pas, on peut obtenir un paragraphe comme celui qui tu lis en ce moment avec des lignes qui font des kilom�tres...
Thomas vO
� (at) Tue, 24 Nov 2009 14:51:34 +0100 (CET),
>> au passage, si quelqu'un conna�t le truc qu'il faut faire sous vim
>> pour avoir l'�quivalent de M-q sur emacs, �a m'int�resse !
>>
> C'est quoi, M-q ?
�a "reformate" un paragraphe de texte pour qu'aucun caract�re ne
d�passe les 80 (72 ? ) colonnes fatidiques...
en gros, �a fait du \raggedright� ;)
[1]: et hop ! (mais je me trompe peut-�tre, je confonds toujours le
ragged<left|right>...)
--
<mpg> D'ailleurs, puisqu'on est vendredi, un petit troll quand
m�me. D'apr�s une amie ubuntiste, texdoc ne ferait pas partie
de l'install TeXlive de base sous ubuntu et serait dans un
paquet avec "extra" dans le nom. De l� � en d�duire que les
Ubuntistes sont des gens pas s�rieux pour qui lire la doc est
en option... ;-p
<moky> La doc, c'est pour les syt�mes est mal pens�s. Quand le syst�me
est bien pens� (Ubuntu), on n'a pas besoin de doc.
-+- in fr.comp.text.tex -+-
lionmarron
<petiard.point.francois@_at_free.point.fr> wrote:
> Je ne comprends pas : avec WinEdt, en construisant l'arborescence du
> document (Build Tree), on voit apparaître toutes les commandes de
> sectionnement dans une fenêtre...
ça y est je l'ai trouvé. Je n'ai pas l'impression que cela permette de
modifier toutes les commandes de sectionnements en même temps, mais
tel quel c'est vraiment très bien quand même. Merci.
A.H.
lionmarron
> +1 Un source, c'est du texte et c'est tout. Je ne veux pas que mes
> gestionnaires de version s'amusent à essayer de comprendre sa structure
> et à faire les malins avec.
>
> >> Evidemment comme Latex est déjà conçu, et si toutefois on suppose que
> >> l'idée présente un intérêt, c'est peut-être trop tard pour y penser.
>
> Oui. Il n'y a rien dans TeX qui permette de garantir que quelque chose
> est un commentaire. Tout dépend trop des circonstances.
C'est seulement maintenant que je comprends. Mieux vaut tard que
jamais.
A.H.
Manuel Pégourié-Gonnard
> � (at) Tue, 24 Nov 2009 14:51:34 +0100 (CET),
> Manuel P�gouri�-Gonnard <m...@elzevir.fr> nous disait (told us):
>> Thomas vO scripsit :
>>> au passage, si quelqu'un conna�t le truc qu'il faut faire sous vim
>>> pour avoir l'�quivalent de M-q sur emacs, �a m'int�resse !
>>>
>> C'est quoi, M-q ?
>
> �a "reformate" un paragraphe de texte pour qu'aucun caract�re ne
> d�passe les 80 (72 ? ) colonnes fatidiques...
>
Ok, alors c'est gq (lire : gq<mouvement> ou gq<objet> ou <mode�visuel>gq
ou gqq pour une ligne, enfin comme d'hab, quoi). Vu que Q est un peu
inutile voire �nervant pour ceux qui n'aiment pas le mode ex, et qu'au
contraire gq est tr�s utile, il y a beaucoup de gens qui remappent Q sur
gq ou m�me gqap (reformater un paragraphe).
(Et le nombre de colonnes fatidiques est donn� par :set tw pendant qu'on
y est.)
Par contre, en LaTeX, tu risques d'�tre d��u, �a n'est pas assez
intelligent pour faire CeKilFo� avec les environnements, les commandes
\item, etc. C'est une de mes plus grosses frustrations quand j'�dite du
LaTeX. (Je sais que sur ce point pr�cis, Emacs-AucTeX s'en sort bien
mieux.)
Thomas vO
� (at) Tue, 24 Nov 2009 17:05:03 +0100 (CET),
Manuel P�gouri�-Gonnard <m...@elzevir.fr> nous disait (told us):
>> �a "reformate" un paragraphe de texte pour qu'aucun caract�re ne
>> d�passe les 80 (72 ? ) colonnes fatidiques...
>
> Ok, alors c'est gq (lire : gq<mouvement> ou gq<objet> ou
> <mode�visuel>gq ou gqq pour une ligne, enfin comme d'hab, quoi). Vu
> que Q est un peu inutile voire �nervant pour ceux qui n'aiment pas
> le mode ex, et qu'au contraire gq est tr�s utile, il y a beaucoup de
> gens qui remappent Q sur gq ou m�me gqap (reformater un paragraphe).
damned ! merci beaucoup ! le temps que j'ai pass� � chercher �a...
> Par contre, en LaTeX, tu risques d'�tre d��u, �a n'est pas assez
> intelligent pour faire CeKilFo� avec les environnements, les
> commandes \item, etc. C'est une de mes plus grosses frustrations
> quand j'�dite du LaTeX. (Je sais que sur ce point pr�cis,
> Emacs-AucTeX s'en sort bien mieux.)
je sais, mais en fait, j'utilise assez peu des fonctionnalit�s
d'AucTex ; on verra donc � l'usage...
--
Tu m'as mal lu. Je sais que c'est mal, certes, mais je le fait quand
m�me. En revanche, j'essaie de tenir compte des situations o� cela va
me p�ter � la figure.
-+- Jean-C�me in fr.comp.text.tex -+-
Jeremy JUST
lionmarron <andre....@gmail.com> a écrit :
> Ce que le compilateur ajouterait est court et constitue seulement du
> commentaire
Et si la compilation plante, que le compilo ajoute n'importe quoi ou
qu'il détruit une partie du fichier, il n'y a plus qu'à déboguer
manuellement, ou réécrire ce qui a disparu... Super, hein?
> Evidemment comme Latex est déjà conçu, et si toutefois on suppose que
> l'idée présente un intérêt, c'est peut-être trop tard pour y penser.
> C'est plutôt si on parle d'un langage non encore fixé que je ne vois
> en quoi cela devrait poser un problème.
As-tu des exemples de langages dans lesquels le compilateur modifie
les sources?
--
Jérémy
Paul Gaborit
� (at) Wed, 25 Nov 2009 13:19:38 +0100,
Jeremy JUST <jerem...@netcourrier.com> �crivait (wrote):
> As-tu des exemples de langages dans lesquels le compilateur modifie
> les sources?
Excel ?
Sinon, Perl gr�ce � son module Acme::Bleach. Mais c'est dr�le une
seule fois ! ;-)
Manuel Pégourié-Gonnard
> Sinon, Perl gr�ce � son module Acme::Bleach. Mais c'est dr�le une
> seule fois ! ;-)
>
Mais c'est tr�s dr�le la premi�re fois, merci de m'avoir fait d�couvrir
�a :-)
(Je suppose qu'emacs propose un mode d'�dition adapt�, au moins ?)
Paul Gaborit
� (at) Wed, 25 Nov 2009 21:20:26 +0100 (CET),
Manuel P�gouri�-Gonnard <m...@elzevir.fr> �crivait (wrote):
> Paul Gaborit scripsit :
>
>> Sinon, Perl gr�ce � son module Acme::Bleach. Mais c'est dr�le une
>> seule fois ! ;-)
>>
> Mais c'est tr�s dr�le la premi�re fois, merci de m'avoir fait d�couvrir
> �a :-)
>
> (Je suppose qu'emacs propose un mode d'�dition adapt�, au moins ?)
Pas � ma connaissance... et heureusement car sinon c'est moins dr�le.
lionmarron
> Et si la compilation plante, que le compilo ajoute n'importe quoi ou
> qu'il détruit une partie du fichier, il n'y a plus qu'à déboguer
> manuellement, ou réécrire ce qui a disparu... Super, hein?
On peut utiliser le même argument pour interdire l'assistance
électronique au freinage ou le GPS, ou d'une façon plus générale
l'ordinateur (peut-être parfois avec raison d'ailleurs).
> [...]
> As-tu des exemples de langages dans lesquels le compilateur modifie
> les sources?
Moi non, mais d'après les messages précédents on dirait que certains
éditeurs le font. (Cela dit ce n'est pas le genre d'éditeur que je
sache utiliser, alors il se peut que j'ai mal compris.)
A.H.
Jean-Côme Charpentier
> On 25 nov, 13:19, Jeremy JUST <jeremy_j...@netcourrier.com> wrote:
>
>> Et si la compilation plante, que le compilo ajoute n'importe quoi ou
>> manuellement, ou r��crire ce qui a disparu... Super, hein?
>
> On peut utiliser le m�me argument pour interdire l'assistance
> �lectronique au freinage ou le GPS, ou d'une fa�on plus g�n�rale
> l'ordinateur (peut-�tre parfois avec raison d'ailleurs).
J'ose esp�r� que si l'assistance �lectronique au freinage plante, je
suis toujours capable d'arr�ter la voiture et que si le GPS plante,
j'arfriverait peu ou prou � demander mon chemin, soit en m'adressant �
des panneaux, soit � une carte, soit � un autochtone. En g�n�ral, le
plantage sur un document source fait vraiment tout planter.
Cela dit, ce n'est pas l'argument le plus s�rieux (on peut toujours
faire une sauvegarde avant de compiler apr�s tout).
>> [...]
>
>> As-tu des exemples de langages dans lesquels le compilateur modifie
>> les sources?
>
> Moi non,
En cherchant bien, on doit trouver. Il faut et il suffit que le
compilateur ait le droit d'ex�cuter des macros qui permettent des
�critures sur disque... TeX a cette possibilit� donc j'ai trouv�. Un
exemple d�bile pour voir :
\documentclass{minimal}
\newwrite\file
\immediate\openout\file \jobname.tex
\begin{document}
Ceci est un document s\'erieux
\immediate\write\file{%
\string\documentclass{minimal}
\string\begin{document}
Mais le diable est pass\string\'e par l\string\`a.
\string\end{document}
}
\end{document}
Attention, sauvegardez bien cette version, elle s'auto-d�truira en
quelques millisecondes une fois la compilation lanc�e.
J'ai �t� sympa, le fichier produit est encore compilable ! Si vous
voulez vraiment faire ce que vous demandez dans le message initial, vous
avez la trame de base. Il ne reste plus qu'� faire la montagne de tests
et les �critures idoine pour arriver � ce que vous voulez : �a va �tre
m�ga-difficile mais je suis certain que c'est possible.
Dans la m�me veine, faites un tour sur les quines possibles avec TeX :
c'est toujours assez impressionnant (et totalement inutile). Par
exemple, le c�l�bre fichier xii.tex.
Avec un \immediate\write18 bien foutu, on peut m�me modifier le source
*en cours* de compilation ! R�sultats franchement non garantis :-)
> mais d'apr�s les messages pr�c�dents on dirait que certains
> �diteurs le font. (Cela dit ce n'est pas le genre d'�diteur que je
> sache utiliser, alors il se peut que j'ai mal compris.)
N'importe quel �diteur digne de ce nom doit pouvoir faire ce genre de
chose. Mais il ne faut pas confondre les changements automatiques
effectu�s par l'�diteur et ceux qui serait effectu�s par le compilateur.
Mon �diteur me fait des changements automatiques en veux-tu en voil� et
j'en suis tr�s content (par exemple, il indente correctement mon source
sans que je m'emmerde � taper des espaces ou des tabulations) mais,
heureusement pour TeX et les enfants de Knuth (que j'aurai maltrait�s)
le compilateur ne touche pas � mes sources... sauf si je le demande �
grand coups de contorsions syntaxiques.
Jean-C�me Charpentier
--
En gros, � mon avis, le document a �t� fait n'importe comment avec un
outil qui fait n'importe quoi ;)
-+- drax in fr.comp.text.tex -+-
lionmarron
Come.Charpent...@wanadoo.fr> wrote:
> >> As-tu des exemples de langages dans lesquels le compilateur modifie
> >> les sources?
>
> > Moi non,
>
> En cherchant bien, on doit trouver. Il faut et il suffit que le
> compilateur ait le droit d'exécuter des macros qui permettent des
> écritures sur disque... TeX a cette possibilité donc j'ai trouvé. Un
> exemple débile pour voir :
>
> \documentclass{minimal}
> \newwrite\file
> \immediate\openout\file \jobname.tex
> \begin{document}
> Ceci est un document s\'erieux
> \immediate\write\file{%
> \string\documentclass{minimal}
> \string\begin{document}
> Mais le diable est pass\string\'e par l\string\`a.
> \string\end{document}}
>
> \end{document}
>
> Attention, sauvegardez bien cette version, elle s'auto-détruira en
> quelques millisecondes une fois la compilation lancée.
> J'ai été sympa, le fichier produit est encore compilable ! Si vous
> voulez vraiment faire ce que vous demandez dans le message initial, vous
> avez la trame de base.
Je n'ai pas essayé cet exemple, mais, afin que je sois sûr d'avoir un
peu compris, il faut que le fichier s'appelle jobname.tex pour que ça
marche non ?
> Il ne reste plus qu'à faire la montagne de tests
> et les écritures idoine pour arriver à ce que vous voulez : ça va être
> méga-difficile mais je suis certain que c'est possible.
Si je me remettais à la programmation j'essayerai plutôt de me
focaliser sur des objectifs plus réalistes. (Et plutôt avec qq chose
comme python qu'avec tex, a priori.)
De toute façon l'idée que j'ai voulu exprimer ne peut pas être
réalisée utilement en utilisant le compilateur final mais plutôt en
modifiant celui-ci, et si le compilateur final est TeX, ou quelque
chose basé sur TeX, ce n'est pas utilement possible a priori. Ce n'est
pas à moi de le dire bien sûr (le fait est que si on m'avait dit le
contraire, j'aurais pu le croire aussi), mais si c'est ce qu'on me
dit, je peux confirmer que telle est bien mon impression.
Je croyais pas qu'on allait arriver jusqu'à la veille de vendredi avec
un sujet pareil, mais, bon, je suppose quand même qu'on arrive vers la
fin du fil...
A.H.
Jean-Côme Charpentier
> On 26 nov, 11:19, Jean-C�me Charpentier <Jean-
> Come.Charpent...@wanadoo.fr> wrote:
> [...]
> Je n'ai pas essay� cet exemple, mais, afin que je sois s�r d'avoir un
> peu compris, il faut que le fichier s'appelle jobname.tex pour que �a
> marche non ?
Non. Ce n'est pas jobname.tex, c'est \jobname.tex. \jobname contient
le nom (sans extension) du fichier qui est en train d'�tre compil�. Sur
mon exemple, le fichier de d�part s'appelait fctt.tex et il a
autoproduit un fctt.tex qui ne produisait plus le m�me r�sultat que lors
de la premi�re compilation.
> [...]
> Si je me remettais � la programmation j'essayerai plut�t de me
> focaliser sur des objectifs plus r�alistes. (Et plut�t avec qq chose
> comme python qu'avec tex, a priori.)
Ce serait sans doute un poil plus simple mais juste un poil quand
m�me. Le d�fi est de taille. Essayez juste de faire un quine,
c'est-�-dire ce que vous demandez sans faire aucun changement sur le
source. Bien entendu, c'est le compilateur qui doit produire le nouveau
source : il est interdit de dire : je laisse le source tel quel !
> Je croyais pas qu'on allait arriver jusqu'� la veille de vendredi avec
> un sujet pareil, mais, bon, je suppose quand m�me qu'on arrive vers la
> fin du fil...
Je suis tr�s d��u. Cette ann�e, je ne peux pas participer � fctt le
vendredi. Il y a deux ou trois sujets qui seraient dignes de se
d�cha�ner lors de cette journ�e !
Jean-C�me Charpentier
--
J'ai trouv� une allergique � \newcommand (l'alter ego de Jean-C�me en
somme). ;-)
Jeremy JUST
lionmarron <andre....@gmail.com> a écrit :
>> Et si la compilation plante, que le compilo ajoute n'importe quoi
> On peut utiliser le même argument pour interdire l'assistance
> électronique au freinage
Si ta voiture (de tourisme) ne peut plus freiner ou se diriger en cas
de panne électronique, elle ne passera pas aux Mines. Ça embête bien
les constructeurs (notamment l'obligation d'avoir une colonne de
direction physique, alors qu'une direction entièrement électronique
coûterait moins cher, et un câble pour le frein de parking), mais c'est
comme ça, et c'est rassurant pour l'utilisateur.
Pour les véhicules agricoles ou de chantier, je suppose que c'est
différent, mais ils ne sont que tolérés sur les routes ouvertes à la
circulation publique (avec gyrophare orange).
> le GPS, ou d'une façon plus générale l'ordinateur (peut-être parfois
> avec raison d'ailleurs).
Si ton GPS modifie les fonctions de base de ta voiture (avancer,
tourner et freiner), ne compte pas sur moi pour monter avec toi.
>> As-tu des exemples de langages dans lesquels le compilateur
>> modifie les sources?
> Moi non, mais d'après les messages précédents on dirait que certains
> éditeurs le font.
Ben encore heureux que l'éditeur modifie le fichier sur lequel tu
travailles!
Chaque logiciel a son rôle, dans un enchaînement de tâches qui
rappelle la « marche en avant » de l'industrie:
- l'éditeur édite le fichier source,
- le compilateur compile le fichier source pour produire un fichier
directement utilisable,
- le visualisateur visualise ledit fichier produit par le compilateur.
Si une étape commence à influencer la précédente, ça risque de causer
des problèmes (notamment de gros noeuds au cerveau).
--
Jérémy Just <jerem...@netcourrier.com>
Manuel Pégourié-Gonnard
> Dans la m�me veine, faites un tour sur les quines possibles avec TeX :
> c'est toujours assez impressionnant (et totalement inutile). Par
> exemple, le c�l�bre fichier xii.tex.
Je t'arr�te tout de suite, xii c'est du code obfusqu�, c'est pas un
quine. �a n'en reste pas moins tr�s impressionant. On trouve des vrais
quines en TeX dans certains num�ros d'Around the Bend, je crois :
Stéphane CARPENTIER
>
> Moi non, mais d'apr�s les messages pr�c�dents on dirait que certains
> �diteurs le font. (Cela dit ce n'est pas le genre d'�diteur que je
> sache utiliser, alors il se peut que j'ai mal compris.)
Il y a deux choses diff�rentes.
D'un c�t�, l'�diteur de texte. Il est charg� de modifier le texte sous
notre contr�le. Il peut proposer des fonctions de modifications de texte
automatique. Par exemple une indentation ou une auto-compl�tion ou un
rajout de balises fermentes d�s qu'une balise ouvrante est saisie. Ce
qui, j'en suis persuad�, ne g�ne personne ici.
D'un autre c�t�, il y a le compilateur qui est cens� interpr�ter quelque
chose qui est fini. Or, si tu demandes � ton compilateur de modifier le
code au moment de la compilation, c'est que ton code n'est pas fini. Tu
auras donc une moins bonne ma�trise de ce que tu veux faire.
Ce que tu veux faire n'est pas forc�ment une mauvaise chose. Mais ce que
tu veux faire devrait �tre fait par ton �diteur de texte ou par un autre
programme.
La question qui se pose est : pour quelle raison vouloir le faire
pendant la compilation ?
lionmarron
<stef.carpent...@gratuit.fr.invalid> wrote:
> La question qui se pose est : pour quelle raison vouloir le faire
> pendant la compilation ?
Question qui n'a rien de stupide. Je n'y avais pas vraiment pensé,
mais on pourrait très bien imaginer un type particulier d'analyse du
code qui le fasse et qui ne fasse rien d'autre.
Il vaudrait mieux que ce soit fait par un programme de même facture
que le compilateur, parce que pour le faire il faut analyser le code
d'une façon qui permette de connaitre au moins une partie de ce que le
compilateur aurait fait.
Evidemment les éditeurs font jusqu'à un certain point des choses
comparables, mais pour aller aussi loin que ce que j'ai décrit ce doit
être tout de même compliqué, même si c'est peut-être possible avec
Emac d'après ce que dit manuel (dans le message qui a pour l'instant
le numéro 14) :
> La dernière fois qu'on a essayé de me convernir à Emacs (et comme
> c'était David Kastrup, un mainteneur enthousiaste d'AucTeX, il
> avait
> failli y arriver, au moins pour le TeX), il me semble qu'on
> m'avait jeté
> au visage une fonctionnalité de ce genre. Pas le truc de
> \ssectionement,
> mais afficher les numéros des sections et des références dans le
> source
> après la première compilation.
Si mon idée avait déclenché un enthousiasme à la fois dangereux et
communicatif (je pense à quelque chose qui aurait pu porter atteinte à
l'ordre public par exemple), normalement j'aurais suggéré que l'idée
soit transmise aux concepteurs de Luatex (je ne risque pas de le faire
moi-même compte tenu de mon anglais), mais je crois qu'on est encore
un peu loin d'en être là.
A.H.
Stéphane CARPENTIER
> On 26 nov, 19:31, St�phane CARPENTIER
> <stef.carpent...@gratuit.fr.invalid> wrote:
>
>> La question qui se pose est : pour quelle raison vouloir le faire
>> pendant la compilation ?
>
> mais on pourrait tr�s bien imaginer un type particulier d'analyse du
> code qui le fasse et qui ne fasse rien d'autre.
Oui, c'est ce que j'avais �crit en parlant d'un programme d�di�.
> Il vaudrait mieux que ce soit fait par un programme de m�me facture
> que le compilateur, parce que pour le faire il faut analyser le code
> d'une fa�on qui permette de connaitre au moins une partie de ce que le
> compilateur aurait fait.
De m�me que quand ton �diteur de texte te colorie ton code, il est
oblig� de savoir quel langage tu utilises pour savoir quoi colorier.
> Evidemment les �diteurs font jusqu'� un certain point des choses
> comparables, mais pour aller aussi loin que ce que j'ai d�crit ce doit
> �tre tout de m�me compliqu�, m�me si c'est peut-�tre possible avec
> Emac d'apr�s ce que dit manuel (dans le message qui a pour l'instant
> le num�ro 14) :
Emacs est une sombre merde qu'il ne faut surtout pas utiliser (He Ho,
vous avez vu, c'est vendredi, m�me pas besoin d'attendre).
Cependant, Emacs �tant programmable, s'il ne fait pas �a nativement, il
est possible de programmer quelque chose qui lui permettra de le faire.
Ma remarque pr�c�dente ayant montr� ma parfaite objectivit� vis � vis
d'Emacs, je pr�ciserai que le langage utilis� est un d�riv� du LISP.
LISP voulant dire Lot Of Insane and Stupid Parenthesis, ce qui montre le
peu d'estime qu'il est possible d'avoir pour un logiciel qui utilise ce
langage.
Il existe d'autres �diteurs de textes qui sont programmable si tu veux
vraiment que ce soit fait par un �diteur de texte. Sinon, tu peux le
programmer dans le langage de ton choix.
lionmarron
<stef.carpent...@gratuit.fr.invalid> wrote:
> Oui, c'est ce que j'avais écrit en parlant d'un programme dédié.
>
> > Il vaudrait mieux que ce soit fait par un programme de même facture
> > que le compilateur, parce que pour le faire il faut analyser le code
> > d'une façon qui permette de connaitre au moins une partie de ce que le
> > compilateur aurait fait.
>
> De même que quand ton éditeur de texte te colorie ton code, il est
> obligé de savoir quel langage tu utilises pour savoir quoi colorier.
Oui, mais ce à quoi je pensais pourrait être plus compliqué que ce que
j'en avais dit. Il serait possible de mettre une instruction dans un
commentaire réservé pour demander quelque chose de précis. Si c'est
par exemple un numéro de page, pour calculer l'information
correspondante il faut faire pratiquement ce que fait le compilateur.
Il n'est effectivement pas théoriquement impossible de le faire faire
par un éditeur, mais dans ces conditions ce n'est pas le plus simple.
Ce que je voulais dire par un programme de même facture que le
compilateur, en fait et a priori, c'est un programme réalisé par la
même équipe de programmeurs. Peut-être que j'aurais plutôt dû écrire
de même mouture.
A.H.
Stéphane CARPENTIER
>
> Oui, mais ce � quoi je pensais pourrait �tre plus compliqu� que ce que
> j'en avais dit. Il serait possible de mettre une instruction dans un
> par exemple un num�ro de page, pour calculer l'information
> correspondante il faut faire pratiquement ce que fait le compilateur.
L�, ce que tu veux, c'est que ton compilateur change le code pendant la
compilation, pas avant.
> Il n'est effectivement pas th�oriquement impossible de le faire faire
> par un �diteur, mais dans ces conditions ce n'est pas le plus simple.
Je ne suis pas un expert LaTeX et encore moins TeX. Mais je crois savoir
que TeX ne revient jamais en arri�re. Donc (*), une fois que TeX a
modifi� le source, il ne peut plus l'interpr�ter. Donc, il faut une
deuxi�me passe de compilation. Donc, �a revient � modifier le code avant
de l'interpr�ter. Je ne suis donc pas s�r que ce soit vraiment plus
simple de modifier la compilation.
(*) il y a une grosse possibilit� que je raconte n'importe quoi, ne pas
h�siter � me corriger.
lionmarron
<stef.carpent...@gratuit.fr.invalid> wrote:
> (*) il y a une grosse possibilité que je raconte n'importe quoi, ne pas
> hésiter à me corriger.
On dirait oui, mais là je crois que mes propres possibilités n'en sont
pas moins dépassées...