Coloration de syntaxe

La coloration de syntaxe est fournie dans la structure de texte de la plate-forme selon un modèle de destruction, réparation et réconciliation.  Pour chaque changement appliqué à un document, le réconciliateur de présentation détermine la région de la présentation visuelle à détruire et comment la réparer.  Différentes stratégies peuvent être utilisées pour différents types de contenu de partition dans le document.

L'implémentation de la coloration de syntaxe (et ce avec un réconciliateur de présentation) est facultative.  Par défaut, SourceViewerConfiguration n'installe pas de réconciliateur de présentation puisqu'il ne connaît pas le modèle de document qu'utilise un éditeur particulier et n'a pas de comportement générique pour la mise en évidence de syntaxe.  

Pour utiliser les classes de réconciliation en vue d'implémenter la mise en évidence de syntaxe, l'afficheur de code source de votre éditeur doit être configuré de manière à définir un réconciliateur de présentation.  Une fois encore, nous commencerons par JavaSourceViewerConfiguration pour voir comment un réconciliateur de présentation est défini pour l'éditeur.

public IPresentationReconciler
getPresentationReconciler(ISourceViewer sourceViewer) {

	PresentationReconciler reconciler= new PresentationReconciler();
	...
	return reconciler;
}

Pour comprendre le fonctionnement d'un réconciliateur de présentation, vous devez commencer par aborder les concepts de destruction, réparation et réconciliation.

Destruction, réparation et réconciliation

Lorsque l'utilisateur modifie du texte dans un éditeur, des parties de l'éditeur doivent être réaffichées pour refléter les modifications.  Le traitement du texte à réafficher est appelé traitement des iestructions.  Lorsque la coloration de syntaxe est impliquée, le nombre de destructions provoquées par une opération d'édition augmente car la présence ou l'absence d'un seul caractère peut modifier la coloration du texte alentour.  

Des destructeurs (IPresentationDamager) déterminent quelle région d'une présentation de document doit être reconstruite pour cause de modification du document. Un destructeur de présentation doit être propre à un type de contenu de document (ou une région). Il doit être capable de signaler une région détruite qui constitue une entrée valide pour un réparateur de présentation (IPresentationRepairer).  Un réparateur doit également être à même d'extraire les informations nécessaires d'une région détruite afin de décrire correctement les réparations requises pour un type de contenu spécifique.

La réconciliation correspond au processus global de gestion de la présentation d'un document à mesure que des modifications sont apportées dans l'éditeur.  Un réconciliateur de présentation IPresentationReconciler) surveille les modifications apportées au texte via l'afficheur associé.  Il utilise les régions du document pour déterminer les types de contenus affectés par la modification et avertit le destructeur approprié au type de contenu affecté.  Une fois la destruction traitée, elle est transmise au réparateur approprié qui construit les descriptions de réparation applicables à l'afficheur afin de le synchroniser avec le contenu sous-jacent. 

Les classes de org.eclipse.jface.text.reconciler définissent des classes de support supplémentaires pour la synchronisation d'un modèle de document avec manipulation externe du document.

Les réconciliateur de présentation doivent disposer d'un couple réparateur-destructeur pour chaque type de contenu présent dans le document.  Chaque éditeur détermine l'implémentation appropriée d'un réconciliateur de présentation.  Toutefois, la plate-forme prend en charge dans org.eclipse.jface.text.rules l'utilisation de scanners de document de base de règles pour traiter et réparer les destructions.  Les destructeurs et réparateurs par défaut sont définis dans ce package.  Vous pouvez le utiliser parallèlement aux réconciliateurs standard de org.eclipse.jface.text.presentation pour implémenter la coloration de syntaxe en définissant des règles d'analyse pour le document.

Réconciliation de base de règles

Vous avez maintenant suffisamment de connaissances pour analyser en détail la création de l'exemple de réconciliateur de présentation.  Rappelez-vous que l'exemple d'éditeur Java implémente un JavaPartitionScanner qui partitionne le document en types de contenus correspondant à des commentaires javadoc, des commentaires multilignes, etc. 

Un destructeur/réparateur doit être défini pour chacun de ces types de contenus.  Cette opération s'effectue à l'aide du PresentationReconciler et du DefaultDamagerRepairer.

	JavaColorProvider provider=
JavaEditorEnvironment.getJavaColorProvider();
	PresentationReconciler reconciler= new PresentationReconciler();
		
	DefaultDamagerRepairer dr= new
DefaultDamagerRepairer(JavaEditorEnvironment.getJavaCodeScanner());
	reconciler.setDamager(dr, IDocument.DEFAULT_CONTENT_TYPE);
	reconciler.setRepairer(dr, IDocument.DEFAULT_CONTENT_TYPE);

	dr= new DefaultDamagerRepairer(new SingleTokenScanner(new
TextAttribute(provider.getColor(JavaColorProvider.JAVADOC_DEFAULT))));
	reconciler.setDamager(dr, JavaPartitionScanner.JAVA_DOC);
	reconciler.setRepairer(dr, JavaPartitionScanner.JAVA_DOC);

	dr= new DefaultDamagerRepairer(new SingleTokenScanner(new
TextAttribute(provider.getColor(JavaColorProvider.MULTI_LINE_COMMENT))));
	reconciler.setDamager(dr, JavaPartitionScanner.JAVA_MULTILINE_COMMENT);
	reconciler.setRepairer(dr, JavaPartitionScanner.JAVA_MULTILINE_COMMENT);

	return reconciler;

Notez que l'exemple fournit des scanners pour chaque type de contenu.  

Le type de contenu par défaut est défini à l'aide d'un JavaCodeScanner de sorte que les mots clés soient détectés et colorés.  Le JavaCodeScanner établit des règles de détection des différents types de jetons, tels que les commentaires monolignes, les espaces blancs et mes mots.  Il décrit les couleurs utilisables pour les mots des différents types de jetons.   

Les autres types de contenus sont définis à l'aide d'un SingleTokenScanner et une couleur leur est attribuée.

Tous les détails relatifs à la destruction et la réparation de parties précises des documents en fonction des règles de scannage sont gérés par DefaultDamagerRepairer.  Ces détails n'ont généralement pas à être compris du code du plug-in.  Votre plug-in doit s'attacher à élaborer un jeu de règles appropriées au partitionnement et au scannage du contenu de son éditeur.

Installation dynamique d'un réconciliateur

L'exemple d'éditeur Java fournit une sous-classe de SourceViewerConfiguration pour l'installation du réconciliateur de présentation comme indiqué précédemment.  Un réconciliateur de présentation peut également être installé dynamiquement sur un afficheur de texte à l'aide du protocole IPresentationReconciler.  Les deux méthodes offrent les mêmes bénéfices du point de vue de l'exécution, mais le regroupement des substitutions de comportement de plug-in dans une sous-classe de SourceViewerConfiguration offre l'avantage de consolider toutes les substitutions comportementales en un même emplacement.  Le protocole dynamique peut se révéler utile lorsque différents réconciliateurs de présentation sont associés à un afficheur au cours du cycle de vie d'un éditeur.