Bonjour a tous.

J'utilise grammalecte depuis quelques années, et ayant de lourds problèmes d'orthographe, je ne connais que trop bien les déboires de ceux qui ne le maitrisent pas convenablement.

Je suis donc très heureux de voir sous GNU/Linux un correcteur grammatical digne de ce nom, qui est de plus bien plus pédagogique que les équivalents propriétaires.

Une constatation me laisse pourtant un arrière goût amère : le fait que grammalecte soit un plug-in pour un programme spécifique plutôt qu’une solution « autonome » interfacé avec libreoffice.

En tant que programmeur professionnel et utilisateur assidu de GNU emacs, j'en suis triste.
En tant qu’auteur d’articles généraliste ou dédié a l’art utilisant texmacs, j’en suis frustré.
En tant que développeur web utilisant django (en python donc) j’aimerais beaucoup proposer a mes utilisateurs (et a la communauté libriste, tant qu'a faire) une correction grammaticale lors de la prévisualisation des postes, et suis donc déçut de ne pouvoir le faire.

J’ai vu ce poste : www.dicollecte.org… qui laisse poindre un début de solution, mais comme il date de l’année dernière (et que la situation a évoluée ?), je préfère recréer un sujet afin de faire repartir la discussion :

peut-on envisager un fonctionnement de grammalect au travers d'une interface minimaliste du genre, (après lancement et configuration des dictionnaires/règles à utiliser) :

dict({position:{description de l'alerte}}) correctSentences( str sentences)

Je suppose qu’en l’état actuel, ça c’est pas faisable directement, je suis prêt à aider à y remédier, j’aurais cependant besoin de quelques pistes. Savoir s’il est possible d’externalisé la gestion de la configuration hors de libreoffice. Savoir si l’auteur accepterais une modification architecturale du genre (sachant que les problèmes d’interopérabilité avec les OS privateurs peuvent être contournées en fournissant au moins les mêmes fonctionnalités qu’a présent pour eux). et éventuellement savoir par quelle bout prendre le code (quelle fichier sert a quoi etc.)

voilà, dans l’espoir d’une réponse,

Webshinra

J’aimerai beaucoup aussi utiliser Grammalecte hors de LibreOffice. Je n’utilise presque jamais Grammalecte, car je trouve LibreOffice trop lourd. Mais quand on pourra utiliser Grammalecte hors de OpenOffice, alors je pense que je vais l’utiliser beaucoup plus.

En tant que programmeur professionnel et utilisateur assidu de GNU emacs, j'en suis triste.

En attendant de pouvoir utiliser Grammalecte hors de LibreOffice, il est possible d’utiliser LanguageTool dans Emacs. J'ai vu un plugin ici :

github.com…

J’avoue ne pas l'avoir essayé. J’utilise LanguageTool avec mon plugin pour Vim :

www.vim.org…

Quand Grammalecte peut fonctionner hors de LibreOffice, j’écrirai un plugin pour Vim.

Bonjour,

Oui, Grammalecte serveur est toujours au programme, c’est juste que cette année, je manque vraiment de disponibilité pour m’y atteler. C’est pourquoi je me suis contenté de faire des améliorations qui ne nécessitaient pas de refondre le moteur (formateur de texte, lexicographe, améliorations des règles et moteur multi-passes).

En ce moment, je travaille lentement à une réorganisation du dictionnaire pour lui faire subir une cure d’allégement qui devrait simplifier la tâche au correcteur grammatical. Il faut aussi que je porte les fonctionnalités de Grammalecte dans Lightproof.

Quant au serveur grammatical, désolé, cette année, j’y ai peut-être consacré un peu de temps au printemps (j’ai l’impression que ça fait une éternité). À mon avis, j’aurai le temps à partir d’avril prochain. Peut-être. Pour ça, il faut reprendre le boulot commencé sur l’automate à états finis : www.dicollecte.org…

Bonjour à tous, je réveille après des années ce sujet, parce que finalement, en recréer un eût été faire un duplicata.

Suite a la campagne de financement participatif (à laquelle j'ai contribué avec enthousiaste, bien que j'ai oublié d'envoyer ma suggestion de mot pour le dico, ça m'apprendra) je suis revenu sur ces forums, et ai constaté à ma grande surprise, qu'avant même de passé en JS (pour le bonheur des surfeurs et le malheur de ceux qui exècrent JS) Grammalecte avait fait un saut par la case Python.

La perspective de ne plus avoir à attendre pour commencer l'intégration à emacs m'a fait grand plaisir et je m'y suis donc attelé il y a quelques jours.

Qu'on se rassure, le gros du module d'intégration que je code effectue la majorité des manipulations coté emacs et il devrait être simple de passer au serveur quand celui-ci sera opérationnel (il ne devrait en fait y avoir qu'une ou deux fonctions à modifier).

D'ailleurs, à cette heure, ça ressemble ça : framapic.org… (il manque tout ce qui est interprétation sémantique du retour de Grammalecte, pour ça je pense éditer le cli.py (ou créer un fichier semblable à côté) pour que celui-ci me retourne des expressions agréables à parser).

Bref, même si je suis content de vous faire partager cet avancement, je viens en réalité quérir des informations sur lesquels je n'ai réussi à mettre la main.

L'idée est d'avoir une intégration transparente de la configuration au travers customize, l'interface d'emacs. Ce fût surprenament facile à faire et j’ai donc sans soucis synchronisé les deux ( framapic.org… ).

Sauf que, et j'en suis navré, je n'arrive pas a comprendre le sens de la majorité des options, dont le nom n'est pas des plus explicites. Ma question est donc la suivante, je poste la liste des options proposés et le sens que je pense avoir trouvé pour certaines d'entre elles.

Serait-il possible qu'une âme charitable et éclairée accepte de me guider pour celles qui restent?

apos: True ; Apostrophe typographique?
bs: True
chim: False; typographie des formules chimiques?
conf: True
date: True
esp: True
gn: True
gv: True
html: True; ignoré les balises html?
idrule: False
imp: True
infi: True
inte: True
liga: False
maj: True
mapos: True
mc: False
nbsp: True ; présence des espaces iscéquables?
neg: False
nf: True
num: True
ocr: False
pleo: True
redon1: False
redon2: False
sgpl: True
tu: True
typo: True
unit: True
virg: True

En vous remerciant.

Ah oui, j’ai oublier de mettre le libellé des options dans cli.py.
Dans la prochaine version, vous verrez ceci :
framapic.org…

Grammalecte avait fait un saut par la case Python.

Grammalecte a toujours été écrit en Python, mais auparavant il était dépendant de Hunspell et de LibreOffice.

je pense éditer le cli.py (ou créer un fichier semblable à côté) pour que celui-ci me retourne des expressions agréables à parser).

Le JSON, ça ne convient pas ?

Ah oui, j’ai oublier de mettre le libellé des options dans cli.py.
Dans la prochaine version, vous verrez ceci :
framapic.org…

Ah, vraiment cool, je documente de ce pas.

Grammalecte a toujours été écrit en Python, mais auparavant il était dépendant de Hunspell et de LibreOffice.

Oui, j'entendais par là «que du python d'exécuté». C’était en effet maladroit.

Le JSON, ça ne convient pas ?

Si complètement, il y a un parseur dans emacs depuis 2008 ( edward.oconnor.cx… ).

Passer par une interface texte simplifie grandement l'intégration, je comptais donc faire générer du json (ou s'il n'y avait possibilité d'exporter les données dans un format lisp-friendly des sexpressions) à cli_emacs.py (qu'il serait peut-être donc plus juste d'appeler cli_json.py [ou de créer une option dans le cli.py, mais ça rend plus difficile l'intégration des éventuelles mises à jour de la version python de mon côté]), car il ne m'a pas semblé que les autres fichiers comportaient une repl ?

En tout cas, merci de votre réponse :)

cli.py peut déjà générer du JSON.
Faites :

cli.py -j -f texte_à_analyser.txt

Pour toutes les options :

cli.py -h

j'ai oublié d'envoyer ma suggestion de mot pour le dico

Il n’est pas trop tard.

Admin :
Il n’est pas trop tard.

Oh? cool, je fais ça dans la journée.

Sinon, petit flash de nouvelle rapide, j'ai une interface correcte entre emacs et Grammalecte (sur le cli.py d'origine), il me reste deux choses à faire avant d'avoir une première version publiable:

- Reformater le texte en entrée de Grammalecte pour qu'il supporte les lignes «filées» sur 75 caractères comme des lignes normales, la seule difficulté consiste à conserver une traçabilité entre les caractères d'origines et ceux du string passé au moteur (pour interpréter correctement la réponse de celui-ci)

- Intégrer le tout convenablement avec helm, l'interface de complétion qui me sert de lib.

Merci pour vos réponses.

Reformater le texte en entrée de Grammalecte pour qu'il supporte les lignes «filées» sur 75 caractères comme des lignes normales

Je ne comprends pas. Pourquoi limiter la longueur d’une ligne à 75 caractères ? Grammalecte n’est pas fait pour corriger du code, mais du français. Ajouter une fin de ligne tous les 75 caractères n’a aucun sens en français.

Utilisez-vous l’interface en JSON ?

Je ne comprends pas. Pourquoi limiter la longueur d’une ligne à 75 caractères ? Grammalecte n’est pas fait pour corriger du code, mais du français. Ajouter une fin de ligne tous les 75 caractères n’a aucun sens en français.

Alors, si je devais donner la réponse historique, je dirais «parce que les terminaux affichent 80 caractères de large». Mais ça serait mentir à l'époque des écrans HD ou 4k.

La réponse est AMHA plus subtile.

Comme premier point, j'avancerais que la nuance entre code en français est plus subtile qu'il n’apparaît au premier abord.

D'après les normes de code GNU, et celle que j'adopte personnellement, un commentaire commence par une majuscule et termine par un point tout en étant une phrase correctement formée. Si on commente généralement en anglais pour des raisons d'universalité, il est des cas où ça ne fait pas nécessairement sens, comme lorsque qu'on code une interface pour un correcteur grammatical français, ou qu'on écrit du code «pour soi» (et qu'on est plus à l'aise pour exprimer sa pensée dans sa langue maternelle). Il est également possible de vouloir rédiger un programme qui va communiquer en français avec l'utilisateur (à travers gettext ou non), il est dès lors légitime de vouloir vérifier la grammaire des éventuels strings.

Dans ces cas, on se retrouve avec des chaines non seulement précédées de chars spécifiques (emacs dispose de regex spécifiques pour chaque mode majeurs pour les extraire) mais ils sont assez souvent coupés de façon… créative :

framapic.org…

C'est un exemple un peu capillotracté, mais qui montre quelles facéties on trouve parfois.

Cependant, et même s'il est important a mes yeux, corriger du français entremêlé de cette façon est le plus souvent anecdotique.

Le cas où on passe de la lubie à un véritable attrait est celui de LaTeX, où on entremêle sauvagement langage naturel et langage formel.

En LaTeX, un espace et un retour à la ligne sont équivalent, la marque de saut de paragraphe étant le double retour a la ligne.

On sait qu'il est difficile de lire une ligne trop longue, il faut donc la couper. Ce pourrait être le rôle de l'éditeur de texte, mais ça pose problème pour trois raisons:

- Le lecteur qui ouvre le fichier le fait peut-être dans une fenêtre en pleine largeur, ce qui l'oblige à faire une manipulation spécifique pour choisir la largeur de coupe, ce problème s'accentue encore avec les éditeur à interface dynamique (ou l'on coupe et fusionne des buffers à l'envi pour éditer plusieurs morceaux de texte simultanément ou en se référant aux uns et aux autres simultanément).

- Le texte peut être indenté différemment pour des questions de lisibilité, on se retrouve alors avec l'éditeur qui crée des retours à la ligne sans indentation au milieu d'un bloc indenté, créant une attaque de ligne en dent de scie, inesthétique et difficile a suivre.

- On ne peut pas prédire l'interface qui manipulera le texte. L'utilisateur fera-il un cat dans un terminal, prendra-t-il la sortie d'un grep pour trouver des références spécifiques ? Nul ne le sait, mais si les lignes font 349 caractères, il sera bien plus malaisé de le triturer.

En réalité, il faut imaginé le texte brut comme une feuille de papier de largeur infinie sur laquelle on tape à la machine.

A titre exemple, la session que j'utilise pour écrire un livre de jeu de rôle ressemble à ça (dans cool-retro-term, parce que j'ai de mauvais goûts): framapic.org…

Je conclurais que les lignes de 75 caractères n'ont pas de sens dans un éditeurs WYSIWYG indépendamment de la langue ou du langage, mais sont pertinentes dans le monde du texte brut.

Utilisez-vous l’interface en JSON ?

Tout à fait, je récupère le JSON en sortie de Grammalecte et le convertis en une plist elisp qui est ensuite triviale à manipuler.

J’allais dire : réduire la largeur de son éditeur de texte, ça marche aussi… :)
Mais j’avais oublié LaTeX. Tiens, d’ailleurs… une petite option LaTeX, à l’arrache, c’est mieux que rien.

P.S. Merci de faire attention à votre grammaire et votre orthographe. Vous êtes difficile à lire. Même si Grammalecte ne parvient pas à détecter toutes vos erreurs, ça vous aiderait.

Au cas où, Manuel Serrano de l'INRIA a écrit une regexp pour flyspell qui détecte les commandes latex, la voici:

"\\(\\(begin\\|end\\)[ \t]*{\\|\\(cite[a-z*]*\\|label\\|ref\\|eqref\\|usepackage\\|documentclass\\)[ \t]*\\(\\[[^]]*\\]\\)?{[^{}]*\\)"

A noter que le comportement de Grammalecte m'a surpris, malgré l'option -j, lorsqu'il n'y a pas d'erreur il retourne "\nNo error found.\n\n" au lieu d'un json vide. J'ai vu que l'option pouvait être passée en interne à la fonction de rapport pour qu'il retourne quelque-chose de la bonne forme, mais je n'ai pas constaté qu'elle était accessible depuis la ligne de commande.

Si c'est effectivement le cas, elle n'est pas mentionnée dans -h; je me permet de suggérer accessoirement qu'il serait de toutes façons plus cohérent que l'option -j retourne systématiquement du json, ce qui limite les cas particuliers à traiter par l'utilisateur.

Pour LaTeX, j’ai regardé ceci : www.math.ens.fr…

Par contre, je ne reproduis pas votre problème avec le JSON. Quand il ne trouve pas d’erreurs, je reçois quelque chose comme :

{ "grammalecte": "0.5.8", "lang": "fr", "data" : [
{"lSpellingErrors": [], "iParagraph": 1, "lGrammarErrors": []},
{"lSpellingErrors": [], "iParagraph": 2, "lGrammarErrors": []}
]}

Admin :
Pour LaTeX, j’ai regardé ceci : www.math.ens.fr…

C'est relativement exhaustif (sachant que latex est turing-complet et permet de définir ses propres symboles, il n'existera jamais de liste les référençant tous). Le seul soucis est que certaines commandes ne sont pas lié au contenu, par exemple:

\input{foo.tex}

tandis que d'autres ne sont là que pour y ajouté de la sémantique (et éventuellement en affecter le rendu, selon le contexte définit par l'utilisateur et le type de document), je citerais:

\emph{La bête humaine} est un roman de Zola.

On y trouve également une grande partie des commande qui commence par \text (\textit, \textbf etc.).

Notons que la commande de l'inria match également les environnements:

\begin{itemize}
\item foo;
\item bar.
\end{itemize}

Par contre, je ne reproduis pas votre problème avec le JSON. Quand il ne trouve pas d’erreurs, je reçois quelque chose comme :
</p>

{ "grammalecte": "0.5.8", "lang": "fr", "data" : [
{"lSpellingErrors": [], "iParagraph": 1, "lGrammarErrors": []},
{"lSpellingErrors": [], "iParagraph": 2, "lGrammarErrors": []}
]}

<p>

Le problème semble ne pas se présenter si on passe a grammalecte un fichier texte mais se produit si le programme est lancé en mode interactif:

16 ╣./cli.py -j -f ./test.txt
Grammalecte v0.5.6
{ "grammalecte": "0.5.6", "lang": "fr", "data" : [
{"lSpellingErrors": [], "lGrammarErrors": [], "iParagraph": 1}
]}

17 ╣cat test.txt | ./cli.py -j
Grammalecte v0.5.6

~==========~ Enter your text [/h /q] ~==========~

No error found.

(après vérification, le même phénomène se produit avec la version 0.5.7)

Ah oui, en effet, j’aurais dû préciser dans l’aide que l’option JSON ne fonctionne qu’avec l’option -f ou -ff, le mode interactif étant prévu pour être interactif.

Avez-vous essayé le serveur (qui ne renvoie que du JSON) ?

le mode interactif étant prévu pour être interactif.

Je ne comprend pas la cohérence sémantique dans le cas présent, mais soit.

Avez-vous essayé le serveur (qui ne renvoie que du JSON) ?

Non, mais c'est simplement parce que j'ignorais son existence. Où le trouve-on?

Je ne comprend pas la cohérence sémantique dans le cas présent, mais soit.

Il n’y en a effectivement pas, parce que dans mon esprit l’option -j ne fonctionnait pas du tout avec le mode interactif, mais je découvre que ça fonctionne en partie. Il faudra donc que je rende les choses plus cohérentes dans un sens ou dans l’autre.

Le serveur est avec les sources.

Bonjour webshinra,

Le serveur se trouve dans les sources : www.dicollecte.org…
Je l'ai découvert par hasard car il ne me semble pas qu'il y avait eut une annonce a propos de se serveur.

En effet, autant tabler sur le serveur qui est à priori l'avenir de Grammalecte.

Je vais prendre quelques temps pour me remettre d'utiliser http plutôt que des tubes, et je vous tiens au courant.
(en réalité ça pose aussi un problème de concurrence, l'idée étant qu'un buffer est supposé pouvoir avoir sa propre configuration de grammalecte, il est gênant d'avoir un serveur web supplémentaire par buffer plutôt qu'un sous-processus asynchrone avec qui j'échange du texte [occupation de port, etc.], il me faut prendre un peu de recul pour savoir quelle est la bonne solution)

Merci pour votre aide.

N'est-il pas possible que tu démarre le serveur au démarrage de emac et puis par la suite tu interroge se serveur pour chaque buffer.

Personnellement après avoir regarder le code du serveur j'ai préféré en refaire un en m'inspirant fortement du cli.py ou il suffit de faire une requette avec le texte et la config à utilisé. Je pense qu'il faudrait aussi que tu en écrive un ;)

Voilà comment je pense un peu au fonctionnement de ton besoin :
Démarrage de Emac => déclenche le serveur
Le buffer est envoyer au serveur avec la config de grammalecte à appliquer
=> Le serveur retourne les erreurs
=> Gestion des erreurs retourner par le serveur

Le serveur permet d’appliquer des options spécifiques à chaque requête.