SAMPI - Editeur structuré
1. Le Problème et la Proposition
2. Le Langage Primitif de Représentation Textuelle
2.1. Présentation de la Syntaxe Concrète
2.2. Notations
2.3. Exemple de structuration des données
2.4. Exemple de structuration des traitements
2.5. Exemple de structurations connexes
3. Le Langage Complété pour la Structuration des Textes
3.1. Présentation de la Syntaxe Complétée
3.2. Etude quantitative de l'évolution des programmes
3.3. L'édition syntaxique
3.4. étude de cas : le langage LTR3 et l'atelier ENTREPRISE
4. L'Enrichissement du Langage par de Nouveaux Concepts
4.1. Présentation de la Syntaxe Abstraite
4.2. Les difficultés
4.3. Compléter la Syntaxe
5. La Formalisation des Solutions Techniques
5.1. L'évaluation fonctionnelle
5.2. La structuration par les objets
5.3. Modèle sémantique comparé de l'évaluateur
5.4. Comparaison critique
5.5. Construction de la Syntaxe Abstraite
6. Les Comparaisons avec d'autres Approches
7. Les Perspectives
8. Les Editeurs
8.0. brisé sur la barrière de la complexité (une fois de plus)
8.1. L'éditeur ligne : Manuel de l'utilisateur
8.2. L'éditeur page : Guide de l'utilisateur
8.2.0. L'état des travaux
8.2.00.1. La syntaxe de l'éditeur
8.2.00.2. L'utilisation d'emacs
8.2.1. Généralités
8.2.2. Le curseur
8.2.3. Les fenêtres
8.2.4. Les tampons
8.2.5. Les fichiers
8.2.6. Le mode "Défaire"
8.2.7. Commandes du Buffer
8.2.8. Commandes du Buffer-Edit
8.2.9. Résumé
9. Les Aspects d'Implantation
9.1. Contexte d'évaluation
9.2. La Syntaxe Abstraite : Manuel du concepteur
9.3. L'éditeur page : Guide de l'implanteur
Références
Rubrique Perl-Javascript

L'état des travaux

Comme il a été dit, l'éditeur page n'est que partiellement réalisé. Il présente une interface très proche de l'éditeur emacs.

1. La syntaxe de l'éditeur

2. L'utilisation d'emacs

1. La syntaxe de l'éditeur

La syntaxe conviviale des « textes » est un sous-ensemble strict de la syntaxe commune présentée auparavant (cf. Chapitre 3.1, « Présentation de la Syntaxe Complétée ») ; on rappelle cette dernière ici :

syntaxe commune

(1)	`env ::= ε \| trm env`
(2)	`trm ::= def \| ref \| env`
(3)	`def ::= <nom> env rep`
(4)	`ref ::= <nom> env`
(5)	`rep ::= ε \| atm rep`
(6)	`atm ::= stg \| use \| <string> \| rep`
(7)	`stg ::= <nom>`
(8)	`use ::= <nom> env`

(1)	un environnement est une liste de termes
(2)	un terme est une définition `def` ou une référence `ref` ou un environnement `env` – et ceci même avant l'évaluation
(3)	une définition est : un nom `<nom>`, un environnement, une représentation
(4)	une référence est : un nom `<nom>`, un environnement
(5)	une représentation est une liste d'atomes
(6)	un atome est une string `stg` ou une utilisation `use` ou une chaîne de caractères `<string>` ou une représentation `rep` – et ceci même avant l'évaluation
(7)	une string `stg` est : un nom `<nom>`
(8)	une utilisation est : un nom `<nom>`, un environnement

syntaxe conviviale

(a)	`env ::= ε \| trm env`
(b)	`trm ::= def`
	`def ::= <nom> env rep`
(c)	`rep ::= ε \| atm rep`
(d)	`atm ::= <string> \| rep`

(a)	un environnement `env` est un tampon pour l'édition de tampons ; on l'appelle dans la suite un « Buffer-Edit ».
(b)	un terme `trm` est une définition `def` ; c'est une ligne d'une fenêtre d'édition d'un Buffer-Edit.
(c)	une représentation `rep` est un tampon d'édition d'un « texte » ; c'est le tampon d'édition classique d'un éditeur, qu'on appelle ici « Buffer ».
(d)	un atome `atm` est la position du curseur dans une fenêtre d'édition d'un Buffer ; c'est le « point d'insertion » sous l'éditeur qui se rattache à la notion classique de curseur.

Remarques :

1	La champ `<nom>` d'une définition `def` est décomposé en deux champs : - la nom du texte, - le nom du fichier auquel est rattaché le texte (`"[None]"` par défaut).
2	Une chaîne de caractères `<string>` devient ici un caractère : - un caractère « graphique » : `" "`, `"!"`, `"*"`, `"#"`, ... - le caractère de retour à la ligne : `NL`. La distinction est transparente à l'utilisateur – si ce n'est la forme graphique du caractère `NL` – mais fondamentale dans l'implantation.