OK
AJAX error!

Les forumsGrammalecteUsage de cli.py

Usage de cli.py

Je viens de commencer à écrire un plugin Grammalecte pour Vim. Il utilise
Grammalecte en ligne de commande (cli.py) avec l'option json (-j). Je vois quelques problèmes :

Remarque #1 : L’option -j devrait produire un document JSON. Mais la première ligne contient
"Grammalecte v0.5.9" qui n’est pas valide pour un document JSON. J’ai corrigé ça :

$ diff -c cli.py.orig cli.py
*** cli.py.orig 2016-09-19 00:47:58.325699518 +0200
--- cli.py 2016-09-19 00:47:48.341699604 +0200
***************
*** 80,86 ****

gce.load()
gce.setOptions({"html": True})
! echo("Grammalecte v{}".format(gce.version))
oDict = gce.getDictionary()
oTokenizer = tkz.Tokenizer("fr")
oLexGraphe = lxg.Lexicographe(oDict)
--- 80,87 ----

gce.load()
gce.setOptions({"html": True})
! if not xArgs.json:
! echo("Grammalecte v{}".format(gce.version))
oDict = gce.getDictionary()
oTokenizer = tkz.Tokenizer("fr")
oLexGraphe = lxg.Lexicographe(oDict)


Remarque #2 : Grammalecte considère les retours chariot comme séparateurs de paragraphes.
Pour Grammalecte, chaque ligne dans le fichier texte est donc un paragraphe différent.
En général, c'est une ligne vide qui sépare les paragraphes dans les fichiers textes,
pas un simple retour chariot. Cela pose problème. Grammalecte ne trouve pas d'erreur
dans le fichier suivant par exemple :

$ cat test.txt
Ceci est un
un test.

Grammalecte ne trouve pas le doublon "un un" à cause du retour chariot quand je tape
en ligne de commande :

$ python3 .cli.py -j -f test.txt

LanguageTool en ligne de commande trouve le doublon contrairement à Grammalecte.
LanguageTool a l'option -b pour ceux qui veulent considérer un retour chariot comme
séparateur de paragraphes.


Remarque #3 : Pourquoi Grammalecte regroupe les erreurs par paragraphe?
Le fichier JSON créé par cli.py contient une liste de paragraphes, et pour chaque
paragraphe, une liste d'erreurs. Ce n'est pas un problème, mais je ne vois pas
l’utilité de regrouper par paragraphe.


Remarque #4 : Grammalecte produit une ligne json pour chaque paragraphe,
même pour les paragraphes qui n'ont pas d'erreurs. Cela ne semble pas
nécessaire.


Remarque #5 : les noms de règles sont un peu obscure. Par exemple le fichier
JSON contient : "sRuleId": "1305s" pour un doublon comme "un un".
LanguageTool a des noms de règles plus clairs comme:
ruleId="FRENCH_WORD_REPEAT_RULE" subId="1"
Ah je vois, le nom de règle tel que "1305s" corresponds au numéro de ligne
de la règle dans le fichier fr-rules.txt. Hmm, cela veut dire que les règles peuvent
avoir des ID différents quand on met à jour Grammalecte, ce qui est
ennuyeux si l'utilisateur configure quelles règle ignorer.


Remarque #6 : Je ne vois pas d’option pour ignorer des règles. Par exemple
la règle 107p ""Espace(s) en début de ligne à supprimer [...]" est candidate pour
être ignorée quand on vérifie des fichiers textes. Avec LanguageTool en
ligne de commande, je peux supprimer un telle règle avec l’option -d WHITESPACE_RULE
où WHITESPACE_RULE est l’ID de la règle à ignorer.

J'espère mettre le plugin Grammalecte de Vim sur Github bientôt, quand il sera fini.
Il fonctionne déjà plus ou moins, mais il y a quelques problèmes à résoudre dû à certaines
des remarques ci-dessus, et je dois encore écrire la documentation.
le 19 septembre 2016 à 01:06

dominiko :Remarque #1 : L’option -j devrait produire un document JSON. Mais la première ligne contient
"Grammalecte v0.5.9" qui n’est pas valide pour un document JSON.


Ah oui, le problème m’a déjà été signalé, mais j’ai oublié de m’en occuper.
À l’origine, le mode interactif ne devait pas produire du JSON, puisque j’avais pensé l’option pour les résultats sur les fichiers.
Il me semble que c’est plus le rôle de server.py de servir de liant avec vim, mais on m’a déjà fait remarquer que cli.py le pouvait aussi.


Remarque #2 : Grammalecte considère les retours chariot comme séparateurs de paragraphes.
[…]
LanguageTool en ligne de command trouve le doublon contrairement à Grammalecte.
LanguageTool a l'option -b pour ceux qui veulent considérer un retour chariot comme
séparateur de paragraphes.


Noté.


Remarque #3 : Pourquoi Grammalecte regroupe les erreurs par paragraphe?


C’est le fonctionnement par défaut parce qu’on renvoie les erreurs paragraphe par paragraphe dans LO. Sauf erreur de ma part, LT fonctionne pareillement pour LO au moins.
C’est un comportement qu’il sera compliqué de modifier. Cela dit, je ne vois pas en quoi il est problématique, c’est même un avantage de mon point de vue. Il va donc falloir me chercher querelle sur la question. :)
De mémoire, Daniel Naber était d’accord avec moi quand j’ai abordé la question sur la liste de LO. (Mais je ne sais pas ce que fait vraiment LT sur ce chapitre.)


Remarque #4 : Grammalecte produit une ligne json pour chaque paragraphe,
même pour les paragraphes qui n'ont pas d'erreurs. Cela ne semble pas
nécessaire.


Effectivement.


Remarque #5 : les noms de règles sont un peu obscurs.


Chaque règle est identifiée par son numéro de ligne et un “p” ou un “s” pour signaler que la règle examine un paragraphe ou une phrase.
Je suis encore partagé sur la manière de gérer la question des options, parce que LO me limite dans ce que je voudrais faire et je n’ai pas encore trouvé un moyen correct de contourner le problème.
Mais effectivement, ce serait mieux d’avoir aussi des noms de règle fixes. Je vais réfléchir à la question quoi qu’il en soit, même si aucune solution ne se profile pour l’instant dans LO.



Remarque #6 : Je ne vois pas d’option pour ignorer des règles.


Ah oui, effectivement.
Pour l’instant, il est possible de désactiver les options par groupe, mais dans cli.py, je n’ai rien prévu pour le faire au lancement… Oubli de ma part. En revanche, c’est possible avec server.py dans le fichier de config ou lors d’une requête.
Je vais essayer de corriger ça vite.


J'espère mettre le plugin Grammalecte de Vim sur Github bientôt, quand il sera finit.
Il fonctionne déjà plus ou moins, mais il y a quelques problèmes à résoudre dû à certaines
des remarques ci-dessus, et je dois encore écrire la documentation..


Cool.

Je suis encore assez pris pour deux jours, mais je vais m’efforcer de résoudre certains de ces problèmes rapidement.

Merci pour le retour.
le 19 septembre 2016 à 13:52

Il me semble que c’est plus le rôle de server.py de servir de liant avec vim, mais on m’a déjà fait remarquer que cli.py le pouvait aussi.


Je ne savais pas que je pouvais utiliser server.py. Mais cli.py semble plus simple de toute façon pour un plugin vim (pas de serveur à démarrer). Le serveur pourrait être utile si le plugin fonctionne en mode asynchrone (c’est-à-dire sans bloquer Vim), mais c'est plus compliqué.

C’est le fonctionnement par défaut parce qu’on renvoie les erreurs paragraphe par paragraphe dans LO. Sauf erreur de ma part, LT fonctionne pareillement pour LO au moins.


LangageTool en mode CLI produit une seule liste d'erreurs (erreurs de grammaire et fautes d'orthographes dans la même liste). Elles ne sont pas groupées par paragraphe. J'avoue ne pas savoir comment cela fonctionne avec LibreOffice.

C’est un comportement qu’il sera compliqué de modifier. Cela dit, je ne vois pas en quoi il est problématique


Ce n'est pas un problème. C'est juste un peu plus compliqué à utiliser qu'une simple liste d'erreurs, mais pas beaucoup plus compliqué. Ce n'est donc pas la peine de changer ça.

Mais effectivement, ce serait mieux d’avoir aussi des noms de règle fixes.


Je pense désactiver par défaut (mais ce sera configurable) certaines règles telles que:
* 381p (Espace(s) en début de ligne à supprimer : utilisez les retraits de paragraphe) : elle ne s'applique pas vraiment à un fichier texte.
* 371p (Apostrophe typographique) : l'apostrophe ASCII est souvent utilisée dans les fichiers texte.

Je suis encore pris assez pour deux jours, mais je vais m’efforcer de résoudre certains de ces problèmes rapidement.


Merci ! Les remarques les plus importantes (pour moi) sont les remarques #1, #2, #5 et #6.
le 20 septembre 2016 à 09:23
Problème 1 (JSON). Corrigé.

Problème 2 (Texte multi-ligne). Corrigé, mais je suis encore embêté avec un petit problème d’espace surnuméraire qui n’a rien à voir. Je vais essayer de corriger ça demain.

Problème 3 (Erreurs groupées par paragraphe). Aucune modification prévue.

Problème 4 (Gestion des paragraphes sans erreur). Corrigé, via une option.

Problème 5 (Renommage des règles). Impossible à faire dans un délai court, il faudra qu’on en discute.

Problème 6 (Désactivation des options via la ligne de commande). Corrigé.
À mon avis, les options à désactiver pour Vim sont : “esp” (Espaces surnuméraires), “nbsp” (espaces insécables), “unit” (espaces insécables pour les unités de mesure), “num” (espaces insécables pour les grands nombres).
le 22 septembre 2016 à 21:18
Super merci !

Question: l'API de Grammalecte donne dans le document JSON pour chaque erreur:

* le numéro de paragraphe ("iParagraph" : …)
* le numéro de colonne du début de l’erreur ("nStart": …)
* le numéro de colonne de la fin de l’erreur ("nEnd": …)

Si Grammaecte accepte un paragraphe sur plusieurs lignes, je suppose que l'API doit alors aussi donner les numéro de lignes du début et fin de l'erreur, qui peuvent être différentes quand une erreur s'étend sur plusieurs ligne.

LT donne:

* le numéro de ligne du début de l'erreur (fromy=…)
* le numéro de colonne du début de l'erreur (fromx=…)
* le numéro de ligne de la fin de l'erreur (toy=…)
* le numéro de colonne de la fin de l'erreur (tox=…)

LT ne donne pas de numéro de paragraphe.

Voici ce que donne LT en ligne de commande avec l’option --api avec un fichier texte simple où une erreur (double) s’étend sur 2 lignes :

$ cat test.txt
Ceci est un
un test.

$ java -jar languagetool/languagetool-standalone/target/LanguageTool-3.5-SNAPSHOT/LanguageTool-3.5-SNAPSHOT/languagetool-commandline.jar -l fr --api < test.txt > test.xml

$ cat test.xml
<?xml version="1.0" encoding="UTF-8"?>
<matches software="LanguageTool" version="3.5-SNAPSHOT" buildDate="2016-09-10 21:32">
<language shortname="fr" name="French"/>
<error fromy="0" fromx="9" toy="1" tox="2" ruleId="FRENCH_WORD_REPEAT_RULE" subId="1" msg="Faute de frappe possible : un mot est répété : un un. Correction : &apos;un&apos;." shortmsg="Doublon" replacements="un" context="Ceci est un un test. " contextoffset="9" offset="9" errorlength="5" category="Règles de base" categoryid="CAT_REGLES_DE_BASE" locqualityissuetype="uncategorized"/>
</matches>
<!--
Time: 501ms for 1 sentences (2.0 sentences/sec)
-->

Contrairement à Grammalecte, LT donne aussi le contexte de l’erreur (context="…" contextoffset="…" errorlength="…") qui est assez utile.
le 23 septembre 2016 à 22:24
Navré pour le délai, mais les imprévus s’accumulent depuis plusieurs jours et me prennent un temps considérable.

Pour l’instant, en ce qui concerne les paragraphes multi-lignes, Grammalecte parvient à les corriger comme un seul paragraphe, mais les signalements se font toujours « à l’ancienne », c’est-à-dire avec un numéro de paragraphe et la position de l’erreur dans le paragraphe.

Dans un texte comme :

bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla

bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla

bla bla bla bla bla bla bla bla

bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla
erreur bla bla bla


il va renvoyer : erreur sur le paragraphe 4, caractère 123 à 129.
Les lignes vides ne sont plus comptabilisées.

J’imagine que ce n’est pas idéal. J’espère que j’aurai le temps de me consacrer à ça dès mardi.
le 25 septembre 2016 à 19:39

… il va renvoyer : erreur sur le paragraphe 4, caractère 123 à 129.
Les lignes vides ne sont plus comptabilisées …

J’imagine que ce n’est pas idéal. J’espère que j’aurai le temps de me consacrer à ça dès mardi.


Oui, ce n’est pas idéal. Ce n’est pas facile à utiliser. J’espère que les numéros de lignes seront disponibles. Je ne suis pas pressé.

Pour l’instant, je considère les numéros de paragraphes comme numéros de lignes, même si ce n’est pas correct. Le plugin Vim pour Grammalecte n’est pas fini (entre autre à causes des remarques discutées dans ce fil), mais voici des copies d’écran pour comparer les plugins Vim pour Grammalecte et LanguageTool avec le même texte :

* Grammalecte : dominique.pelle.free.fr…
* LanguageTool : dominique.pelle.free.fr…
le 25 septembre 2016 à 21:43
Ça a l’air de fonctionner.
Qu’est-ce que tu voudrais pour le contexte ?
Pour l’instant, ça renvoie deux chaînes supplémentaires par erreur : ce qu’il y a avant, ce qu’il y a après. Mais point important : il y a les erreurs de phrases (le contexte, c’est la phrase) et les erreurs de paragraphes (le contexte, c’est le paragraphe). À mon avis, il serait bon de limiter le contexte qu’on renvoie, sinon ça peut être énorme.
le 28 septembre 2016 à 17:01

Qu’est-ce que tu voudrais pour le contexte ?


Je n’ai pas eu le temps de voir comment LT choisit le contexte. Mais je pense que retourner la phrase (ou paragraphe?) ou se situe l’erreur, tronquée à gauche et à droite si le contexte est trop long devrait être OK, avec indication ou se trouve l’erreur dans ce contexte.
le 01 octobre 2016 à 09:19
Essaie avec : [[ lien supprimé, la dernière version publiée contient ces améliorations ]]
le 02 octobre 2016 à 05:40
Bonjour,

Je viens vous signaler que l'api de LT a changé wiki.languagetool.org… maintenant c'est une api json languagetool.org…

Maintenant comme vous pourrez le voir dans la documentation il n'y a plus que l'offset de l'erreur avec ça longueur et l'offset est basé sur tout le texte qu'on lui envoie. C'est assez rare qu'elle renvoie un contexte (en tout cas pour le français).

Sinon concernant le cli.py vu que la séparation des strophes se fait par le script, je pense que ça serait bien que l'offset et la fin soit relative a tout le texte qui lui est passé (ou au moins une option pour le faire) et non sur la strophe.

Pour le renvoie du contexte peut être que juste renvoyer un offset et longueur suffit et éviterait surtout dans certain cas renvoyer tout le texte qu'on lui envoie et c'est a l'application cliente de retrouver le texte.
le 04 octobre 2016 à 17:23

Je viens vous signaler que l'api de LT a changé wiki.languagetool.org… maintenant c'est une api json languagetool.org…



Ce lien décrit l'API du serveur. En ligne de commande, LT-3.5 utilise encore XML.

Maintenant comme vous pourrez le voir dans la documentation il n'y a plus que l'offset de l'erreur avec ça longueur et l'offset est basé sur tout le texte qu'on lui envoie. C'est assez rare qu'elle renvoie un contexte (en tout cas pour le français).



Je viens d'essayer l'API json ici languagetool.org…
Le continu JSON à l'air similaire au contenu XML (à part la syntaxe évidemment). Je vois toujours le contexte retourné dans le document JSON.

@Admin: je n'ai pas eu le temps d'essayer le dernier Grammalecte www.dicollecte.org… mais j'espère faire cela bientôt.
le 04 octobre 2016 à 23:24
On n’a pas forcément vocation à suivre ce que fait LT.

Par ailleurs, le contexte renvoyé par Grammalecte est optionnel (pour ma part, ça ne me sert pas du tout), fourni uniquement sur demande. C’est toujours la position des erreurs qui est renvoyée :
— dans le paragraphe [option par défaut],
— dans le texte (avec un numéro de ligne et de colonne).
le 05 octobre 2016 à 08:11

Admin :
Navré pour le délai, mais les imprévus s’accumulent depuis plusieurs jours et me prennent un temps considérable.

Pour l’instant, en ce qui concerne les paragraphes multi-lignes, Grammalecte parvient à les corriger comme un seul paragraphe, mais les signalements se font toujours « à l’ancienne », c’est-à-dire avec un numéro de paragraphe et la position de l’erreur dans le paragraphe.

Dans un texte comme :
</p>

bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla

bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla

bla bla bla bla bla bla bla bla

bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla
erreur bla bla bla


il va renvoyer : erreur sur le paragraphe 4, caractère 123 à 129.
Les lignes vides ne sont plus comptabilisées.

J’imagine que ce n’est pas idéal. J’espère que j’aurai le temps de me consacrer à ça dès mardi.<p>



En commençant à développer un petit frontend avec PySide, je me suis rendu compte qu'il y avait un problème au niveau des indices de caractères lorsqu'un paragraphe contient un "?": ce dernier n'est pas comptabilisé et cela décale la position d'un caractère. Cela ne permet alors pas de retrouver le mot fautif. Tant qu'à changer des choses dans ce coin là, ça pourrait être bénéfique de jeter un coup d'oeil à ce bug là en même temps.

EDIT: J'ai découvert que le bogue affecte également le point d'exclamation.
le 10 octobre 2016 à 09:01
Je viens de modifier mon plugin Vim pour utiliser la nouvelle option -cl de Grammalecte-v0.5.11.
Je suis désolé de répondre si tardivement, je n'avais pas beaucoup de temps.

Pour certaines phrases, ça marche. Je peut maintenant signaler les erreurs qui sont sur plusieurs lignes. Merci !

Mais je vois un problème. Pour certaines phrases, il n'y a ni nStartX ni nStartY.

Exemple:

$ cat test.txt
Lorsqu'il est parti.

$ python3 ~/Downloads/Grammalecte-v0.5.11/pythonpath/cli.py -f test.txt -j -cl | json_pp -f json -t json
{
"lang" : "fr",
"grammalecte" : "0.5.11",
"data" : [
{
"lGrammarErrors" : [
{
"sRuleId" : "509p",
"aSuggestions" : [
"Lorsqu’"
],
"nEndX" : 7,
"URL" : "",
"sType" : "apos",
"sMessage" : "Apostrophe typographique.",
"nEndY" : 1
}
],
"lSpellingErrors" : []
}
]
}

Je m'attendais à voir les tags nStartX et nStartY ici. Mais peut-être que je n'ai pas bien compris.

À part cela, le plugin liste certaines règles à désactiver, mais les ID des règles changent à chaque version de Grammalecte ce qui est problématique. Le plugin devra être mis à jour pour chaque version de Grammalecte :-(

Je vois aussi des messages JSON vides pour les phrases correctes, qui ne me semble pas utile.

Exemple :

$ cat test2.txt
Une phrase correcte.

Un phrase incorrecte.

$ python3 ~/Downloads/Grammalecte-v0.5.11/pythonpath/cli.py -f test2.txt -j -cl | json_pp -f json -t json
{
"data" : [
{
"lSpellingErrors" : [],
"lGrammarErrors" : []
},
{
"lSpellingErrors" : [],
"lGrammarErrors" : [
{
"nStartX" : 4,
"nStartY" : 3,
"aSuggestions" : [
"phrase"
],
"nEndY" : 3,
"sType" : "gn",
"nEndX" : 11,
"sMessage" : "Accord de nombre erroné : « phrases » devrait être au singulier.",
"URL" : "",
"sRuleId" : "3228s"
}
]
}
],
"grammalecte" : "0.5.11",
"lang" : "fr"
}
le 13 octobre 2016 à 11:52

dominiko :
Pour certaines phrases, il n'y a ni nStartX ni nStartY.


Corrigé. Il manquait aussi parfois nEndX et nEndY.
Ça se corrige facilement. Va dans “text.py”, fonction “convertToXY”.
Dans les deux conditions, tu remplaces “>” par “>=”, ainsi que “<” par “<=”.

À part cela, le plugin liste certaines règles à désactiver, mais les ID des règles changent à chaque version de Grammalecte ce qui est problématique. Le plugin devra être mis à jour pour chaque version de Grammalecte :-(


Je vais essayer de m’occuper de ça très vite. Dès demain.

Je vois aussi des messages JSON vides pour les phrases correctes, qui ne me semble pas utile.


Utilise l’option --only_when_errors.
Je devrais peut-être l’activer par défaut avec le JSON.
C’est surtout utile quand cli.py renvoie du texte.
le 13 octobre 2016 à 19:20

memophysic :
En commençant à développer un petit frontend avec PySide, je me suis rendu compte qu'il y avait un problème au niveau des indices de caractères lorsqu'un paragraphe contient un "?": ce dernier n'est pas comptabilisé et cela décale la position d'un caractère. Cela ne permet alors pas de retrouver le mot fautif. Tant qu'à changer des choses dans ce coin là, ça pourrait être bénéfique de jeter un coup d'oeil à ce bug là en même temps.

EDIT: J'ai découvert que le bogue affecte également le point d'exclamation.


Je ne reproduis pas le problème. Il va falloir que vous soyez plus précis.
le 13 octobre 2016 à 19:35
@dominiko : J’ai commencé le renommage… Comme il y a des milliers de règles, mieux vaut me dire lesquelles dont tu voudrais des noms en priorité. Je présume qu’il s’agit surtout des règles typographiques et des espaces.

Il y aura donc dorénavant deux identifiants : sLineId et sRuleId (ce dernier étant égal au premier si rien n’est spécifié).
le 13 octobre 2016 à 21:41
Je n’ai toujours pas fini le renommage (j’en ai profité pour revoir pas mal de choses dans l’organisation des règles), mais si tu veux, tu peux avoir une préversion.
le 15 octobre 2016 à 18:21

Admin :

memophysic :
En commençant à développer un petit frontend avec PySide, je me suis rendu compte qu'il y avait un problème au niveau des indices de caractères lorsqu'un paragraphe contient un "?": ce dernier n'est pas comptabilisé et cela décale la position d'un caractère. Cela ne permet alors pas de retrouver le mot fautif. Tant qu'à changer des choses dans ce coin là, ça pourrait être bénéfique de jeter un coup d'oeil à ce bug là en même temps.

EDIT: J'ai découvert que le bogue affecte également le point d'exclamation.


Je ne reproduis pas le problème. Il va falloir que vous soyez plus précis.



J'ai compris le problème, il s'agit de la fonction formatText dans textformatter.py qui, assez bizarrement, ajoute une espace avant les points d'exclamation et d'interrogation.
le 19 octobre 2016 à 01:58

Ça se corrige facilement. Va dans “text.py”, fonction “convertToXY”.
Dans les deux conditions, tu remplaces “>” par “>=”, ainsi que “<” par “<=”.


J'ai fait cela, mais l'erreur persiste, en utilisant le même exemple que précédemment :

$ cat test.txt
Lorsqu'il est parti.
$ python3 Grammalecte-v0.5.11/pythonpath/cli.py -f test.txt -j -cl
{ "grammalecte": "0.5.11", "lang": "fr", "data" : [
{"lGrammarErrors": [{"sMessage": "Apostrophe typographique.", "sRuleId": "509p", "sType": "apos", "URL": "", "nEndY": 1, "nEndX": 7, "aSuggestions": ["Lorsqu’"]}], "lSpellingErrors": []}
]}


(pas de nStartX ni nStartY)


@dominiko : J’ai commencé le renommage… Comme il y a des milliers de règles, mieux vaut me dire lesquelles dont tu voudrais des noms en priorité. Je présume qu’il s’agit surtout des règles typographiques et des espaces


Oui. Règles avec apostrophe typographique, les trois points de suspension. tiret, espace insécable.

si tu veux, tu peux avoir une préversion.


OK, je trouverai le temps d'essayer ce weekend. Oui puis-je télécharger une nouvelle version ?
le 20 octobre 2016 à 06:58
@dominiko:

(pas de nStartX ni nStartY)


Chez moi, ça fonctionne. Peut-être ai-je modifié quelque chose d’autre… ?

J’ai finalement eu le temps de nommer toutes les règles, sauf celles du préprocesseur de texte (ce n’est pas urgent et je ne suis même pas sûr de le faire).
Note que ces noms sont susceptibles de changer avec le temps. J’ai tout nommé assez vite, peut-être trouverais-je plus tard une nomenclature plus plaisante. L’autre raison qui provoquera des changements de nom, c’est la fusion ou la séparation des règles. Il n’est pas rare que je fusionne plusieurs règles en une seule, notamment depuis que Grammalecte peut effectuer plusieurs actions par règle. En renommant toutes les règles de contrôle, j’en ai profité pour passer en revue le mode de fonctionnement de nombreuses d’entre elles, qui ont été fusionnées. Quant aux séparations, c’est souvent la nécessité qui commande.
Donc, je te suggère d’inclure une procédure contrôlant que les noms des règles que tu veux brider existent toujours.
Mais il est certain que ça va à présent beaucoup moins changer qu’auparavant.

Nouvelle version : [[ lien supprimé ]]
le 20 octobre 2016 à 12:15
@memophysic:

J'ai compris le problème, il s'agit de la fonction formatText dans textformatter.py qui, assez bizarrement, ajoute une espace avant les points d'exclamation et d'interrogation.


Ah oui, mais ce n’est pas bizarre du tout. C’est le fonctionnement attendu du formateur de texte, dont le rôle est de modifier le texte (supprimer les espaces surnuméraires, en ajouter d’autres, etc.). Du coup, les positions des erreurs données au format JSON ne correspondent pas forcément au texte initial mais au texte transformé par le formateur.

Donc, afin d’éviter ces décalages, plusieurs solutions possibles :
— ne pas employer le formateur de texte si vous demandez des résultats au format JSON,
— demander le contexte (option --context) pour connaître ce qui se trouve avant et après les erreurs,
et (nouvelle possibilité),
— utiliser le champ “sText” (qui contient le texte transformé par le formateur de texte) que renvoie désormais automatiquement Grammalecte si vous activez l’option JSON avec le formateur de texte.
le 20 octobre 2016 à 12:25
J'ai essayé la version 0.5.12 :

* le problème des nStartX nStartY qui manquaient parfois est résolu.
* je n'ai pas compris comment désactiver des règles. Je suppose que je dois utiliser l'option -off, mais comment ?
* je vois la nouvelle option -ctx. Merci. Je vais modifier mon plugin pour l'utiliser.

Une petite correction dans pythonpath/cli.py :

$ diff cli.py-old cli.py
24c24
< /-opt1 [opt2] ... disactivate grammar checking options
---
> /-opt1 [opt2] ... deactivate grammar checking options
109c109
< xParser.add_argument("-off", "--opt_off", nargs="+", help="disactivate options")
---
> xParser.add_argument("-off", "--opt_off", nargs="+", help="deactivate options")
le 21 octobre 2016 à 05:20
Je pensais que tu désactivais de ton propre côté, mais il est effectivement logique de proposer ces options moi-même. Retélécharge l’extension.
Note : Il n’est pas possible d’activer une règle indépendamment des options. Les options générales prévalent.

Édition 13 h 26 : mise à jour avec la possibilité de lister les options et les règles.
le 21 octobre 2016 à 09:52

Je pensais que tu désactivais de ton propre côté, mais il est effectivement logique de proposer ces options moi-même. Retélécharge l’extension.
Note : Il n’est pas possible d’activer une règle indépendamment des options. Les options générales prévalent.



Oui, je veux désactiver quelques règles par défaut, mais aussi laisser l'utilisateur du plugin
configurer quelles règles désactiver.

J'avoue ne pas encore comprendre. Comment utiliser l'option -off ? Un exemple serait utile.
L'usage est un peu laconique à propos de "-off". Il indique :

usage: cli.py [-h] [-f FILE] [-ff FILE_TO_FILE] [-owe] [-j] [-cl] [-tf] [-tfo]
[-ctx]
[-w {40,50,60,70,80,90,100,110,120,130,140,150,160,170,180,190,200}]
[-lo] [-lr [LIST_RULES]] [-on OPT_ON [OPT_ON ...]]
[-off OPT_OFF [OPT_OFF ...]] [-roff RULE_OFF [RULE_OFF ...]]
[-d]

optional arguments:
-h, --help show this help message and exit
-f FILE, --file FILE parse file (UTF-8 required!) [on Windows, -f is
similar to -ff]
-ff FILE_TO_FILE, --file_to_file FILE_TO_FILE
parse file (UTF-8 required!) and create a result file
(*.res.txt)
-owe, --only_when_errors
display results only when there are errors
-j, --json generate list of errors in JSON (only with option
--file or --file_to_file)
-cl, --concat_lines concatenate lines not separated by an empty paragraph
(only with option --file or --file_to_file)
-tf, --textformatter auto-format text according to typographical rules
(unavailable with option --concat_lines)
-tfo, --textformatteronly
auto-format text and disable grammar checking (only
with option --file or --file_to_file)
-ctx, --context return errors with context (only with option --json)
-w {40,50,60,70,80,90,100,110,120,130,140,150,160,170,180,190,200}, --width {40,50,60,70,80,90,100,110,120,130,140,150,160,170,180,190,200}
width in characters (40 < width < 200; default: 100)
-lo, --list_options list options
-lr [LIST_RULES], --list_rules [LIST_RULES]
list rules
-on OPT_ON [OPT_ON ...], --opt_on OPT_ON [OPT_ON ...]
activate options
-off OPT_OFF [OPT_OFF ...], --opt_off OPT_OFF [OPT_OFF ...]
deactivate options
-roff RULE_OFF [RULE_OFF ...], --rule_off RULE_OFF [RULE_OFF ...]
deactivate rules
-d, --debug debugging mode (only in interactive mode)


Ah ! je viens de voir l'option -roff. Ça fonctionne si je l'utilise comme cela par exemple :

$ python3 Grammalecte-fr-v0.5.12/pythonpath/cli.py -f foo.txt -roff apostrophe_typographique apostrophe_typographique_après_t typo_points_suspension1 typo_tiret_incise nbsp_avant_double_ponctuation -j -cl -owe -ctx

Le plugin grammalecte de vim commence à devenir très utilisable avec la dernière version de grammalecte.
Je donnerai le lien sur github après quelques améliorations.
le 21 octobre 2016 à 20:45
Quelques remarques supplémentaires.

1) Le document JSON donne les les résultats qui semblent triés par l'ID de la règle. Trier par nStartY puis par nStartX me semple plus utile. Mais je peux trier moi-même.

2) L'option -ctx ne fonctionne pas bien : je vois que sBefore et sAfter contiennent des chaînes de caractères très longues. Exemple :

{
"lang" : "fr",
"data" : [
{
"lGrammarErrors" : [
{
"sBefore" : "Lorsqu'il a demandé qui avait cassé la fenêtre, tous les garçons ont pris un air innocent. Je ne supporte pas ce type. Pour une fois dans ma vie je fais un bon geste... Et ça ne sert à rien. Ne tenez aucun compte de ce qu'il dit. Essayons quelque chose ! Qu'est-ce que tu fais ? Qu’est ce que c’est ? Aujourd'hui nous sommes le 18 juin et c'est l'anniversaire de Muiriel ! Joyeux anniversaire Muiriel ! Muiriel a 20 ans maintenant. Le mot de passe est \"Muiriel\". Je serai bientôt de retour. Je ne sais pas. J'en perds mes mots. Ça ne va jamais finir. Je ne sais simplement pas quoi dire... C’était un méchant lapin. J'étais dans les montagnes. Est-ce que c'est une photo récente ? Je ne sais pas si j'ai le temps. Pour une certaine raison le microphone ne marchait pas tout à l'heure. Tout le monde doit apprendre par soi-même en fin de compte. L'éducation dans ce monde me déçoit. L'apprentissage ne devrait pas être forcé. L'apprentissage devrait être encouragé.

(et je je tronque, car c'est en fait bien plus long)


3) Pour afficher le contexte, je veux par exemple indiquer pour une phrase telle que "Ceci est une une erreur." :

Erreur : doublon @ 1L 10C
Correction : une
Contexte : Ceci est une une erreur.

L'option -ctx donne le contexte avant et après l'erreur (sBefore, sAfter), mais ne donne pas le texte de l'erreur c-à-d "une une" dans mon exemple.

Voilà. J’espère ne pas donner trop de travail avec toutes ces remarques :-) Merci bien.
le 21 octobre 2016 à 21:27
OK. Quand je dis que les options prévalent sur les règles, ça veut dire ceci : tu ne peux pas activer une règle si l’option de groupe englobant ladite règle n’est pas elle-même active.
Mettons que tu veuilles activer une des règles concernant l’OCR : tu ne peux le faire qu’en activant l’option “ocr” et en désactivant les règles dont tu ne veux pas.

1) Le document JSON donne les les résultats qui semblent trié par l'ID de la règle. Trier par nStartY puis par nStartX me semple plus utile. Mais je peux trier moi-même.


Le flux est potentiellement important. Si deux règles soulignent une même erreur, la première devrait avoir la priorité (la plupart du temps). Ceci jusqu’à ce que j’implémente un mécanisme de priorité… Mais pas le temps pour l’instant.

je vois que sBefore et sAfter contiennent des chaînes de caractères très longues


Oui, en effet. J’attendais ta remarque sur la question. Les règles de paragraphe ont le paragraphe pour contexte (les phrases n’existent pas encore à ce point). Les règles de phrase ont la phrase pour contexte. J’ai commencé à migrer des règles de paragraphe pour réduire ce problème, mais je n’ai pas fini. Il n’en reste pas moins que cette longueur sera peut-être gênante. Il est facile de réduire le contexte à un nombre de caractères donné, si tu le désires. Des suggestions ?

L'option -ctx donne le contexte avant et après l'erreur (sBefore, sAfter), mais ne donne pas le texte de l'erreur


Je n’y avais pas songé. Facile à faire. C’est d’ailleurs fait.

Je te déconseille de fournir le plugin pour Vim avant que j’aie sorti une version stable. Je suis en train de revoir les mécanismes de suggestion, ce n’est pas stable.
le 21 octobre 2016 à 22:08

Le flux est potentiellement important. Si deux règles soulignent une même erreur, la première devrait avoir la priorité (la plupart du temps). Ceci jusqu’à ce que j’implémente un mécanisme de priorité… Mais pas le temps pour l’instant.


Le plugin Vim trie maintenant les erreurs par ligne et colonne. Pas la peine donc de changer quoi que ce soit dans Grammalecte.

L'option -ctx donne le contexte avant et après l'erreur (sBefore, sAfter), mais ne donne pas le texte de l'erreur



Je n’y avais pas songé. Facile à faire. C’est d’ailleurs fait.


Merci. Je vais regarder ça.

Pour l’instant, je te déconseille de fournir le plugin pour Vim avant que j’aie sorti une version stable. Je suis en train de revoir les mécanismes de suggestion, ce n’est pas stable.


Je ne suis pas pressé. Prends ton temps.
le 22 octobre 2016 à 00:30
J’ai retéléversé l’extension : www.dicollecte.org…

Le contexte renvoie dorénavant aussi un champ “sUnderlined”.
J’ai limité les champs “sBefore” et “sAfter” à 80 caractères.
le 22 octobre 2016 à 09:48

Notification par e-mail    0