Erreurs du parseur SPIP

1) Eléments de grammaire

cf http://programmer.spip.net/Syntaxe-complete-des-balises

À l’intérieur d’une paire de { et }, il n’est pas nécessaire de poser des [( et )]

• dans les critères de boucle :
  <BOUCLE_a(TABLE) {champ op #TRUC|filtre{param}}>
• dans les balise de langue :
  <:module:clef{arg1=txt, arg2=#BALISE}|filtre1{txt,#BALISE}|filtre2:>

Cependant, dans le cas de #SET ou #ARRAY il est nécessaire de poser les [( et )] à la balise elle-même si elle n’est pas utilisée comme argument d’une autre balise :

[(#SET{var, #BALISE|filtre{arg}})]
   [(#ARRAY{1,a, 2,b, 3,#BALISE|filtre})]

Ainsi, pour le #GET, suivant où il est utilisé, il faudra ou non poser les [( et )] :

[(#GET{truc}|filtre)]
   <BOUCLE_a(TABLE) {champ op #GET{truc}|filtre{param}}>

2) Erreurs du lexer et parseur

• JLuc :

Les codes suivants provoquent une erreur du compilateur :

#SET{tel,[(#TEL|oui) telephone #TEL]}
#SET{mel,[(#WEB|non) [(#EMAIL|oui) mel #EMAIL]]}
	

L’erreur affichée est « Argument manquant dans la balise SET ».

Par contre ça passe avec des crochets autour du SET. [(#SET{tel,[(#TEL|oui) telephone #TEL]})]
Cette erreur est donc « normale ».

• Habon :

  #ID_ANNONCE n’est pas interprété :

  #URL_ACTION_AUTEUR{
                  ajouter_lien,
                annonce-#ID_ANNONCE-auteur-#SESSION{id_auteur}-candidater,
                  #SELF}

#ID_ANNONCE est interprété :

#URL_ACTION_AUTEUR{
               ajouter_lien,
               auteur-#SESSION{id_auteur}-annonce-#ID_ANNONCE-candidater,
               #SELF},
               '

Si le #SESSION{id_auteur} est un #NOM,#ID_ANNONCE est bien interprété. On dirait donc que c’est les arguments des balises :
-  2 balises avec des arguments, c’est bon.
-  2 balises sans arguments, c’est bon.
-  Mais une balise avec et une balise sans, c’est pas bon.

Astuce trouvée : remplacer mon #ID_ANNONCE par un #ENV{id_annonce}, mais ça marche pas avec tous les contextes.

Rq : C’est une difficulté pour le créateur de squelette SPIP, mais cette difficulté peut être contournée en utilisant la syntaxe complète des balises, à savoir avec les crochets + parenthèses, autour de toutes les balises.
Mais permettre l’écriture sans crochets parenthèses faciliterait l’écriture.

3) Erreurs de syntaxes non signalées

Les erreurs suivantes ne sont pas détectées ni signalées.
C’est probablement difficile à changer car tout ce qui n’est pas compris comme code SPIP est compris comme texte. Faudrait il que SPIP détecte « ce qui ressemble presque à un code mais n’en est pas un » pour le signaler et inviter à vérifier si c’est ya en fait une erreur dans ce qui devrait être un code ?

• JLuc : Dans <INCLURE{fond=sla/main_head_fin.sla}}/> aucune erreur n’est signalée mais ça comprend pas ce qu’il faut (il y a un } en trop à la fin).
  Indice : SPIP pourrait signaler l’erreur vu qu’il y a <INCLURE au début

• JLuc : [avant (#VAL{arg}|unfiltre|#NOM_SITE_SPIP) après]] aucune erreur signalée mais il manque un |sinon. SPIP pourrait éventuellement détecter que le résultat est ignoré et remplacé par une constante et présumer qu’il y a une erreur ?

• JLuc :[(#BALISE|filtre{texte1,texte2})] pose problème si il y a des virgules dans texte1 ou texte2 : cette virgule est considérée comme séparatrice des arguments du filtre. Même si on entoure les arguments avec #VAL{...}, le problème persiste.