se fabriquer un font-locking

On 20 Jul 2005, Sébastien Kirche wrote:

Quel est la méthode conseillée ? Il faut commencer par dériver
un mode majeur ?

Je pense qu'il y a deux façons de faire (enfin il y en a d'autres
mais celles là me semblent assez populaires)

1. Tu dérives en totalité ton mode d'un autre et tu en reprends
les définitions de face auxquelles tu rajoutes tes mots clés
comme par exemple:

;;; lisp code
(font-lock-add-keywords 'c-mode
("\<\(g_[-.a-z0-9_]*;?\)\>" . font-lock-keyword-face)
("\<\(dlopen\)\>" . font-lock-keyword-face)
("\<\(dlsym\)\>" . font-lock-keyword-face)
("\<\(dlerror()\)\>" . font-lock-keyword-face)
("\<\(FIXME\):" 1 font-lock-warning-face prepend)
("\<\(TODO\) *:" 1 font-lock-warning-face prepend)
;;; end of lisp code

Ne pas oublier d'enclencher le mode font-lock et d'appeler la
fonction fontify-buffer (enfin là j'en suis moins sûr).

2. Tu décris chacune de tes faces à l'aide de `defface', tu
appelles la fonction propertize pour chaque morceau que tu
veux "colorier".

Par exemple, étant entendu que tu as au préalable définit une
face 'test-face', ça pourrait donner:

(insert (propertize "test" 'face 'test-face) "n")

Un truc encore plus cool est d'appeler propertize avec un
format-spec pour gérer des variables dans le style des variables
qui gèrent la modeline ( [ %toto %i %n - ... ]).

Footnotes:
[1] c'est le langage de description de ressource Apple
(fichiers .r),
mais avec des types custom en supplément.

A ce moment là, reprends un mode existant et ajoute tes mots pour
le mode en question.
--
,--. Xavier Maillard, Reims, France ,= ,-_-. =.
/ ,- ) http://www.emacsfr.org/ ((_/)o o(_))
`-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. _/

Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:

Quel est la méthode conseillée ? Il faut commencer par dériver un mode
majeur ?

C'est le mieux à mon avis.

Voir C-h f define-generic-mode RET, C-h f define-derived-mode RET et
C-h v font-lock-defaults RET.

--
Matthieu

Sébastien Kirche writes:

j'aimerais me fabriquer un font-locking pour colorier des fichiers de
ressources[1] propres au dev que je fais pour ma boîte.

Quel est la méthode conseillée ? Il faut commencer par dériver un mode
majeur ?

À priori, je dirais oui. Mais je ne connais pas le format des
fichiers que tu utilises pour ta boîte. Cela te permet de plus
d'ajouter plus facilement (et de manière plus cohérente) des
fonctionalités supplémentaires, comme l'aide à la modification.

S'il est assez simple, tu peux regarder du côté de 'generic.el'
dans ta distro Emacs (et 'generic-x.el' pour des exemples). Et
bien sûr, (info "(elisp)Modes") et (info "(elisp)Major Modes")
sont intéressants.

--drkm

Le 20 July 2005 à 12:07, drkm vraute :

Sébastien Kirche writes:

> j'aimerais me fabriquer un font-locking pour colorier des fichiers
> de ressources[1] propres au dev que je fais pour ma boîte.

> Quel est la méthode conseillée ? Il faut commencer par dériver un
> mode majeur ?

À priori, je dirais oui. Mais je ne connais pas le format des
fichiers que tu utilises pour ta boîte. Cela te permet de plus
d'ajouter plus facilement (et de manière plus cohérente) des
fonctionalités supplémentaires, comme l'aide à la modification.

S'il est assez simple, tu peux regarder du côté de 'generic.el'
dans ta distro Emacs (et 'generic-x.el' pour des exemples). Et
bien sûr, (info "(elisp)Modes") et (info "(elisp)Major Modes")
sont intéressants.

Simple ? Pas vraiment. Ce langage permet de décrire des ressources
accessibles par un programme pendant son fonctionnement.
Ce peut être des chaînes, des icônes, des bitmaps, des boîtes de
dialogue, ou des structures arbitraires comme des tableaux de bytes ou
plus élaborées puisqu'on peut définir des types.

Avec les anciens systèmes Mac, les ressources faisaient partie des
exécutables (façon windows) ou se trouvaient dans des fichiers dédiés.
Avec OSX, elles sont généralement regroupées dans des fichiers de
données à côté des exécutable à l'intérieur d'un même répertoire vu par
l'utilisateur comme une seule application (notion de Bundle).

Pour les créer, on peut utiliser une éditeur graphique de ressource ou
compiler un fichier source (.r).
Le format reprend la syntaxe du C, c'est d'ailleurs parsable par le
compilo, on peut y avoir des #define et on peut inclure d'autres .r ou
des .h avec #include. J'ai recopié quelques exemples pour montrer la
syntaxe.

Merci à toi et aux autres pour vos conseils, je vais regarder tout ça.


8<------8<------8<------8<------8<------8<------8<------8<------8<------
Exemples simples :

resource 'WIND' (RWINDOW, purgeable) {
{60, 40, 290, 160},
kWindowDocumentProc,
invisible, GoAway, 0x0, "Traffic", staggerParentWindow
};

resource 'RECT' (RSTOPRECT, purgeable) {
{10, 10, 110, 110}
};

type CREATOR as 'STR ';

#ifndef DEBUG
resource CREATOR (0) {
APPLNAME " : Version " VERSION " du " $$Date;
};
#else
resource CREATOR (0) {
APPLNAME " : Version " VERSION " du " $$Date SUPDEBUG;
};
#endif

resource 'MENU' (MEDIT) {
MEDIT,
textMenuProc,
AllItems & ~ (MENUITEM2),
enabled,
"Edition",
{
"Annuler", noIcon, "Z", noMark, plain;
"-", noIcon, noKey, noMark, plain;
"Couper", noIcon, "X", noMark, plain;
"Copier", noIcon, "C", noMark, plain;
"Coller", noIcon, "V", noMark, plain;
"Effacer", noIcon, noKey, noMark, plain
}
};

resource 'STR#' (IDLG_LISTESMEM+1, "", purgeable)
{
{
"Zero",
"Un",
"Deux",
"Trois",
"Quatre"
}
};

--
Sébastien Kirche

Sébastien Kirche writes:

resource 'WIND' (RWINDOW, purgeable) {
{60, 40, 290, 160},
kWindowDocumentProc,
invisible, GoAway, 0x0, "Traffic", staggerParentWindow
};

Si tu veux vraiment définir une grammaire exacte, tu peux
utiliser Semantic. L'avantage est qu'après, tu bénéficies
d'outils de navigation, et tu peux plus facilement coder des
outils d'insertion ou modification, puisque tu n'as plus à te
soucier de l'analyse syntaxique.

Mais ÀMHA dans ce cas, il est possible d'arriver à quelque
chose d'honnête avec quelques expressions rationnelles.

Cela dépend si tu es payé si tu passes plusieurs mois à
développer ce mode, ou si tu cherches juste à te faciliter la
vie.

Dans le premier cas, on peut s'arranger. Dans le second aussi,
mais ça te coutera plus cher (personnellement, je veux dire) :-p

--drkm

Le 20 juillet 2005 à 20:07, drkm a dit :

Si tu veux vraiment définir une grammaire exacte, tu peux
utiliser Semantic. L'avantage est qu'après, tu bénéficies
d'outils de navigation, et tu peux plus facilement coder des
outils d'insertion ou modification, puisque tu n'as plus à te
soucier de l'analyse syntaxique.

J'aimerais bien apprendre à me servir de ce truc. Je suppose que ça doit
permettre de faire des choses assez intéressantes, cependant je manque
cruellement de maîtrise du lisp.

Peut-être qu'on arrivera à combler ça si Xavier trouve moyen d'obtenir
le manuel.

J'ai aussi cherché si je ne pouvais pas trouver la grammaire du langage
sans succès. Mais par contre il y a dans la doc Apple la description de
la syntaxe et des instructions.

Mais ÀMHA dans ce cas, il est possible d'arriver à quelque
chose d'honnête avec quelques expressions rationnelles.

C'est peut-être le plus simple dans le cadre d'un mode.

Cela dépend si tu es payé si tu passes plusieurs mois à
développer ce mode, ou si tu cherches juste à te faciliter la
vie.

C'est toute la question :)

Dans le premier cas, on peut s'arranger. Dans le second aussi,
mais ça te coutera plus cher (personnellement, je veux dire) :-p

Je suis payé, mais pas pour ce genre de choses. Si je planche sur cette
problématique c'est pour m'écrire une boîte à outils pour effectivement
me simplifier la vie. Et aussi pour apprendre.

Comme dernièrement quand j'ai commencé à porter en python pour mon mac
une série d'outils qu'un collègue a écrit en macros vb pour ms visual
studio.

Je me suis aussi intéressé aux parsers et aux grammaires. J'avais dans
l'idée d'écrire un outil (recherche d'erreurs de codage, stats,
navigation et génération de code personnalisés pour mon travail)a l'aide
d'un parser en python, mais je manque un peu de bagage sur la question.

Peut-être que ça pourrait être fait avec semantic également ?

Et je me suis demandé si avec eieio il n'y aurait pas moyen de générer
une sorte de schéma du modèle physique de données à partir d'un fichier
décrivant une base (SGBD séquentiel indexé propriétaire) dans une
syntaxe particulière...

Si tu peux fournir une assistance, je prends, évidemment :)

--
Sébastien Kirche

Sébastien Kirche writes:

Le 20 juillet 2005 à 20:07, drkm a dit :

Si tu veux vraiment définir une grammaire exacte, tu peux
utiliser Semantic.

J'aimerais bien apprendre à me servir de ce truc. Je suppose que ça doit
permettre de faire des choses assez intéressantes, cependant je manque
cruellement de maîtrise du lisp.

Personnellement, je ne connais pas. Mais je pense que tu as
plus d'avantage à connaître ce qu'est une grammaire (et/ou Yacc
ou Bison) qu'à maîtriser l'ELisp, pour utiliser Semantic.

Peut-être qu'on arrivera à combler ça si Xavier trouve moyen d'obtenir
le manuel.

Heu ... ? J'ai vu qu'il avait demandé sur g.emacs ou g.e.help
après le manuel Emacs Lisp imprimé. Mais je suppose que tu
parles d'autre chose. Pour rappel, le manuel imprimé est le même
que le manuel Info (sauf qu'il doit être plus vieux, j'imagine).
Et Semantic ne fait pas partie de GNU Emacs. Le manuel est
disponible sur <URL:http://cedet.sf.net/>.

J'ai aussi cherché si je ne pouvais pas trouver la grammaire du langage
sans succès. Mais par contre il y a dans la doc Apple la description de
la syntaxe et des instructions.

Donc tu as la grammaire :-). Le tout est de la retranscrire
dans une autre langue.

Je me suis aussi intéressé aux parsers et aux grammaires. J'avais dans
l'idée d'écrire un outil (recherche d'erreurs de codage, stats,
navigation et génération de code personnalisés pour mon travail)a l'aide
d'un parser en python, mais je manque un peu de bagage sur la question.

Peut-être que ça pourrait être fait avec semantic également ?

Oui. C'est ce que je voulais dire en parlant de ce que tu
avais en plus si tu écrivais une grammaire Wisent. C'est que, je
pense, tu as alors en bonus la navigation, la détection d'erreurs
de syntaxe, etc.

Et je me suis demandé si avec eieio il n'y aurait pas moyen de générer
une sorte de schéma du modèle physique de données à partir d'un fichier
décrivant une base (SGBD séquentiel indexé propriétaire) dans une
syntaxe particulière...

EIEIO est une implémentation (très limitée) de CLOS. C'est à
dire du système objet de Common Lisp (pour utiliser des classes,
des objets, des méthodes, etc.).

Il peut donc servir dans la conception et l'implémentation d'un
tel outil, mais il n'est pas plus adapté pour cela que pour un
gestionnaire d'arbre généalogique ou que pour décrire les
relations entre les véhicules à roues, à pattes ou amphibies.

Si tu peux fournir une assistance, je prends, évidemment :)

Comme d'habitude, pose tes questions précises (et moins
précises :-p), on tentera d'y répondre. Maintenant, si c'est un
poste de développeur Emacs Lisp que tu me proposes, là c'est moi
qui prend :-p.

--drkm

Le 20 juillet 2005 à 21:07, drkm s'est exprimé ainsi :

> J'aimerais bien apprendre à me servir de ce truc. Je suppose que ça
> doit permettre de faire des choses assez intéressantes, cependant je
> manque cruellement de maîtrise du lisp.

Personnellement, je ne connais pas. Mais je pense que tu as
plus d'avantage à connaître ce qu'est une grammaire (et/ou Yacc
ou Bison) qu'à maîtriser l'ELisp, pour utiliser Semantic.

Certes mais ça peut aider, comme l'autre jour quand tu parlais de
defclass.

> Peut-être qu'on arrivera à combler ça si Xavier trouve moyen
> d'obtenir le manuel.

Heu ... ? J'ai vu qu'il avait demandé sur g.emacs ou g.e.help
après le manuel Emacs Lisp imprimé. Mais je suppose que tu
parles d'autre chose. Pour rappel, le manuel imprimé est le même
que le manuel Info (sauf qu'il doit être plus vieux, j'imagine).
Et Semantic ne fait pas partie de GNU Emacs. Le manuel est
disponible sur <URL:http://cedet.sf.net/>.

Oui, mais pour les docs techniques quand je suis en phase
d'apprentissage, je préfère toujours avoir le bouquin dans les mains.
Ainsi j'ai le manuel papier d'Emacs21, le Latex par la pratique ou
Python en concentré...

Ce n'est plus pareil quand je recherche un point précis, un paramètre ou
une syntaxe, là je me satisfait d'un man ou de Info (voir de Google) car
c'est beaucoup plus rapide.

> J'ai aussi cherché si je ne pouvais pas trouver la grammaire du
> langage sans succès. Mais par contre il y a dans la doc Apple la
> description de la syntaxe et des instructions.

Donc tu as la grammaire :-).

Si on veut...

Le tout est de la retranscrire dans une autre langue.

Voilà :)

> Je me suis aussi intéressé aux parsers et aux grammaires. J'avais
> dans l'idée d'écrire un outil (recherche d'erreurs de codage, stats,
> navigation et génération de code personnalisés pour mon travail)a
> l'aide d'un parser en python, mais je manque un peu de bagage sur la
> question.

> Peut-être que ça pourrait être fait avec semantic également ?

Oui. C'est ce que je voulais dire en parlant de ce que tu
avais en plus si tu écrivais une grammaire Wisent. C'est que, je
pense, tu as alors en bonus la navigation, la détection d'erreurs
de syntaxe, etc.

Cas concret : est-ce que par exemple on pourrait facilement coder un
détecteur à coquille du style « return dans un bloc TRY/EXCEPT» ?

TRY et EXCEPT sont des macros C++ qui nous permettent d'écrire des blocs
try/catch. Or si par mégarde on sort du bloc try par un return() (ce qui
est juste syntaxiquement et qui compile) on explosera le programme à la
prochaine exception qui n'aura (murphy oblige) aucun rapport avec la
portion de code où se cache le return(). Le cas normal étant soit de
sortir par return dans la partie gestion de l'exception, ou en dehors du
bloc try s'il n'y a pas d'erreur.

> Et je me suis demandé si avec eieio il n'y aurait pas moyen de
> générer une sorte de schéma du modèle physique de données à partir
> d'un fichier décrivant une base (SGBD séquentiel indexé
> propriétaire) dans une syntaxe particulière...

EIEIO est une implémentation (très limitée) de CLOS. C'est à
dire du système objet de Common Lisp (pour utiliser des classes,
des objets, des méthodes, etc.).

Il peut donc servir dans la conception et l'implémentation d'un
tel outil, mais il n'est pas plus adapté pour cela que pour un
gestionnaire d'arbre généalogique ou que pour décrire les
relations entre les véhicules à roues, à pattes ou amphibies.

Ok. D'après la doc il m'avait semblé que c'était capable de schématiser
des classes à partir du code source. Je m'étais dit que ça pouvait
peut-être s'adapter...

> Si tu peux fournir une assistance, je prends, évidemment :)

Comme d'habitude, pose tes questions précises (et moins
précises :-p), on tentera d'y répondre. Maintenant, si c'est un
poste de développeur Emacs Lisp que tu me proposes, là c'est moi
qui prend :-p.

Ben je pourrais éventuellement fournir le gîte si tu comptais passer des
vacances vers chez moi, mais pas beaucoup plus :)

Ou alors tu ajoutes un autre module sur ton cvs et en route :)

--
Sébastien Kirche

Sébastien Kirche writes:

[ Désolé pour le temps de réponse. ]

Oui. C'est ce que je voulais dire en parlant de ce que tu
avais en plus si tu écrivais une grammaire Wisent. C'est que, je
pense, tu as alors en bonus la navigation, la détection d'erreurs
de syntaxe, etc.

Cas concret : est-ce que par exemple on pourrait facilement coder un
détecteur à coquille du style « return dans un bloc TRY/EXCEPT» ?

TRY et EXCEPT sont des macros C++ qui nous permettent d'écrire des blocs
try/catch. Or si par mégarde on sort du bloc try par un return() (ce qui
est juste syntaxiquement et qui compile) on explosera le programme à la
prochaine exception qui n'aura (murphy oblige) aucun rapport avec la
portion de code où se cache le return(). Le cas normal étant soit de
sortir par return dans la partie gestion de l'exception, ou en dehors du
bloc try s'il n'y a pas d'erreur.

Entre parenthèses, je ne vois pas le problème avec le return
dans le bloc try. Sans t'attarder trop sur ce HS, pourrais-tu en
dire un peu plus ?

Sinon, je pense que pendant longtemps les parseurs des langages
C-like ne parsaient que les éléments en namespace-level. Mais je
pense que maintenant ils implémentent presque entièrement la
grammaire et qu'il est donc possible de faire ce que tu cherches.

C'est à dire chercher les blocs try du fichier, et pour chacun
chercher s'il contient une instruction return. Tout cela est à
vérifier du côté de Semantic.

Mais je me demande si ce genre de choses a bien sa place dans
un éditeur. Je parle évidemment du cas où tu voudrais inclure
cela comme support à la saisie (vérification pendant la rédaction
du source). S'il s'agit de choisir un outil pour implémenter ce
vérificateur (qui serait par exemple appelé dans une cible check
d'un Makefile), alors pourquoi pas.

> Et je me suis demandé si avec eieio il n'y aurait pas moyen de
> générer une sorte de schéma du modèle physique de données à partir
> d'un fichier décrivant une base (SGBD séquentiel indexé
> propriétaire) dans une syntaxe particulière...

EIEIO est une implémentation (très limitée) de CLOS. C'est à
dire du système objet de Common Lisp (pour utiliser des classes,
des objets, des méthodes, etc.).

Il peut donc servir dans la conception et l'implémentation d'un
tel outil, mais il n'est pas plus adapté pour cela que pour un
gestionnaire d'arbre généalogique ou que pour décrire les
relations entre les véhicules à roues, à pattes ou amphibies.

Ok. D'après la doc il m'avait semblé que c'était capable de schématiser
des classes à partir du code source. Je m'étais dit que ça pouvait
peut-être s'adapter...

Si je comprend ce à quoi tu fais référence, il s'agit d'une des
premières applications de EIEIO, COGRE, capable de dessiner des
schémas en ASCII. Ou alors d'une fonctionalité de EIEIO qui
dessine l'arborescence des classes. Mais rien de bien excitant,
et surtout de spécifique à EIEIO.

Si tu donnes un exemple de fichier descripteur de DB ou sa
syntaxe, et ce à quoi tu veux arriver, on y verrait peut-être
plus clair.

--drkm

Le 24 July 2005 à 14:07, drkm a formulé :

[ Désolé pour le temps de réponse. ]

Pareil, je voulais prendre le temps de répondre.

> TRY et EXCEPT sont des macros C++ qui nous permettent d'écrire des
> blocs try/catch. Or si par mégarde on sort du bloc try par un
> return() (ce qui est juste syntaxiquement et qui compile) on
> explosera le programme à la prochaine exception qui n'aura (murphy
> oblige) aucun rapport avec la portion de code où se cache le
> return(). Le cas normal étant soit de sortir par return dans la
> partie gestion de l'exception, ou en dehors du bloc try s'il n'y a
> pas d'erreur.

Entre parenthèses, je ne vois pas le problème avec le return
dans le bloc try. Sans t'attarder trop sur ce HS, pourrais-tu en
dire un peu plus ?

En gros (je simplifie l'écriture exacte) j'ai :
#define TRY
{
try
{

#define EXCEPT
}
catch(un_type_d_exception erreur)
{
tErr = erreur;
}
if (erreur)
{

#define ENDTRY
}
}

Ce qui permet de simplifier l'écriture de blocs avec gestion d'erreur,
par exemple :
long Foo (long bar)
{
short baz;

TRY
baz = TraitementQuiPeutLeverUneException(bar);
if (baz)
return(1);
EXCEPT
//libérations éventuelles
return(erreur);
ENDTRY
return(0)
}

Avec ce bout de code,
- si mon TraitementQuiPeutLeverUneException provoque une exception, elle
sera traitée proprement dans la partie EXCEPT qui retourne un code
d'erreur (les #define permettent d'économiser de l'écriture de code,
ils sont utilisée partout)

- s'il n'y a pas de problème (d'exception), on sort normalement par la
fin de fonction qui n'est plus dans un bloc try

- si je passe le test if (baz) qui a pu se retrouver là par inattention
quand les corps de fonction sont assez gros (on a aussi pas mal de
code multiplateforme et d'options en #ifdef), le return permettra de
sortir de la fonction. Cependant si plus tard un autre fonction (ou la
même) provoque une exception, on se retrouve dans la 4ème dimension,
pour reprendre une expression des devs d'ici. Au mieux ça plante, au
pire ça fait autre chose de bizarre, ou rien de visible immédiatement.

Sinon, je pense que pendant longtemps les parseurs des langages
C-like ne parsaient que les éléments en namespace-level. Mais je
pense que maintenant ils implémentent presque entièrement la
grammaire et qu'il est donc possible de faire ce que tu cherches.

C'est à dire chercher les blocs try du fichier, et pour chacun
chercher s'il contient une instruction return. Tout cela est à
vérifier du côté de Semantic.

Mais je me demande si ce genre de choses a bien sa place dans
un éditeur. Je parle évidemment du cas où tu voudrais inclure
cela comme support à la saisie (vérification pendant la rédaction
du source). S'il s'agit de choisir un outil pour implémenter ce
vérificateur (qui serait par exemple appelé dans une cible check
d'un Makefile), alors pourquoi pas.

C'est tout à fait ça. Un collègue implémenté ce genre de vérification
dans des macros vb dans MS Visual Studio en parsant manuellement le code
avec moult select case, if, recherche de texte, etc.

C'est inutilisable pour moi sous Mac avec un compilo différent.

Et surtout chaque parse doit être implémenté séparément : il a par
exemple une énumération des blocs switch dans lesquels il pourrait
manquer des break. Et c'est limité car pas à l'abri d'une surprise en
#ifdef par exemple.

Avec un truc du genre semantic on arrive à parser àma plus
intelligemment.

J'ai commencé à regarder les grammaires wisent pour voir comment ça
s'utilisait. Je vois comment ça se compile pour générer le parseur, mais
il faut que je voie comment le parseur est utilisé ensuite pour analyser
le code par les modules supérieurs (exemple : pour rechercher une
définition ou faire des stats).

> > > Et je me suis demandé si avec eieio il n'y aurait pas moyen de
> > > générer une sorte de schéma du modèle physique de données à
> > > partir d'un fichier décrivant une base (SGBD séquentiel indexé
> > > propriétaire) dans une syntaxe particulière...

> > EIEIO est une implémentation (très limitée) de CLOS. C'est à
> > dire du système objet de Common Lisp (pour utiliser des classes,
> > des objets, des méthodes, etc.).

> > Il peut donc servir dans la conception et l'implémentation d'un
> > tel outil, mais il n'est pas plus adapté pour cela que pour un
> > gestionnaire d'arbre généalogique ou que pour décrire les
> > relations entre les véhicules à roues, à pattes ou amphibies.

> Ok. D'après la doc il m'avait semblé que c'était capable de
> schématiser des classes à partir du code source. Je m'étais dit que
> ça pouvait peut-être s'adapter...

Si je comprend ce à quoi tu fais référence, il s'agit d'une des
premières applications de EIEIO, COGRE, capable de dessiner des
schémas en ASCII. Ou alors d'une fonctionalité de EIEIO qui
dessine l'arborescence des classes. Mais rien de bien excitant,
et surtout de spécifique à EIEIO.

Si tu donnes un exemple de fichier descripteur de DB ou sa
syntaxe, et ce à quoi tu veux arriver, on y verrait peut-être
plus clair.

En gros, je veux la lune :) À partir d'un fichier qui décrit une base
séquentielle indexée propriétaire (des tables, avec pour chaque table la
liste des champs, leur attributs type/unicité et la liste des index
éventuels sur les tables avec les champs concernés) générer un graphe
des liaisons entre les tables.

exemple bidon sur 2 tables :
SERVICE (0x10; 'Services')
{
Champs
{
SE_Code (0x101;'Code service') : String[5](NOTNULL);
SE_Intitule (0x102;'Intitulé service') : String[50];
}
Index
{
ISE_CODE (0x110;'ISE_CODE') {SE_Code}(UNIQUE);
}
}
VEHICULE (0x10; 'Véhicules')
{
Champs
{
VE_Immat (0x201;'Immatriculation véhicule') : String[8](NOTNULL);
VE_Annee (0x202;'Année mise en service') : Short;
SE_Code (0x203;'Service rattaché') : String[5];
}
Index
{
IVE_IMMAT (0x210;'IVE_IMMAT') {VE_Immat}(UNIQUE);
}
}

Partant de ça j'obtiens automagiquement 2 blocs

+---------+ +----------+
| SERVICE |---| VEHICULE |
+---------+ +----------+
| | | |
+---------+ +----------+

Car le parser aura "vu" que VEHICULE référence un champ de SERVICE.

Si c'est faisable, après faut imaginer avec une base qui contient
beaucoup plus de tables et de champs...

Valà, valà... :P

--
Sébastien Kirche