Mudlet: Espace de notification après regex $

Bien que très improbable, il n'est pas impossible qu'une expression régulière se termine par \$ donc la recherche d'espaces de fin après un $ n'est pas à 100% infaillible.

:bulb: Ce serait bien si nous pouvions appliquer QTextOption::ShowTabsAndSpaces mais comme l'élément dlgTriggerPatternEdit::lineEdit_pattern est un QLineEdit il n'a pas la capacité d'avoir cette option...

💡 Ce serait bien si nous pouvions appliquer QTextOption::ShowTabsAndSpaces

Cela ne me semble pas très gentil..

Bien qu'il soit _très_ improbable, il n'est pas _impossible_ qu'une expression régulière se termine par \$ donc la recherche d'espaces après un $ n'est pas à 100 % infaillible.

Par conséquent, nous ne bloquons pas cette utilisation mais informons seulement : l'avez-vous vraiment fait ?

Cela pourrait donc conduire à la première utilisation de la méthode (void) dlgTriggerEditor::showWarning(const QString& error) ... :grinning:

Que se passe-t-il si l'expression régulière doit se terminer dans un espace - Mudlet réduit tranquillement les espaces - et ne fournit pas de solution de contournement serait encore pire.

Mudlet dit : NON !

Vous pouvez toujours le faire, via \s+ ou \s{,4} et d'autres similaires... De nombreuses façons de dépecer le chat regex.
Ayant été une utilisation basée sur l'implication pendant si longtemps, la "réparer" ne ferait que casser l'UX. J'ai donc rédigé mon dernier commentaire.

J'ai donc rédigé mon dernier commentaire.

Eh bien, cela a quelque peu brouillé la continuité pour les futurs lecteurs, donc juste pour mémoire, SlySven ci-dessus a réagi à la suggestion d'ajouter un QString::trimmed() au texte du modèle.

Mangled est peut-être le mot que vous recherchez. Le commentaire supprimé est le suivant :

Pourquoi ne pas appliquer QString::trimmed() au texte du motif ?
Regex a des classes de caractères, ainsi que les séquences d'échappement typiques pour faire correspondre les caractères. Ne vaut-il pas mieux forcer des schémas explicites que d'autoriser des schémas ambigus ou implicites ?

Je viens juste de remarquer que vous parlez d' alias - bien sûr, le même problème est présent dans plusieurs types de déclencheurs ...

Un espace après $ a-t-il vraiment un sens dans notre contexte ? Je ne pense pas que ce soit le cas, nous devrions simplement le supprimer automatiquement pour une meilleure UX.

Eh bien, s'il s'agit d'un $ échappé littéral, SlySven a un point par exemple.
Je ne sais pas s'il pourrait encore y avoir d'autres cas, alors je ne l'ai pas suggéré.

Puisque nous devons déjà nous assurer que le dernier caractère avant tout espace est $, serait-il d'autant plus difficile de s'assurer que celui qui précède n'est pas \ , et donc ce n'est pas un $ échappé ?

Supprimez les espaces si les deux derniers caractères sont (anything but \)$ et si les deux derniers caractères avant les espaces sont \$ , ne les supprimez pas.

Avons-nous ce problème uniquement après des signes de dollar non échappés ou devons-nous nous attaquer à tous les espaces blancs environnants ?

Oui, je pense que nous pouvons tous accepter de le faire automatiquement s'il s'agit d'une fin de ligne littérale. De même pour ^ . Dans les cas où ce que l'utilisateur pourrait vouloir est au moins un peu ambigu, nous pouvons lancer un avertissement, mais c'est une preuve assez grossière.

Pas avec mon ordinateur portable pour le coder, mais si quelqu'un d'autre veut essayer, n'hésitez pas.

Puisque nous devons déjà nous assurer que le dernier caractère avant tout espace est $, serait-il d'autant plus difficile de s'assurer que celui qui précède n'est pas \ , et donc ce n'est pas un $ échappé ?

Eh bien, je ne suis pas un pro de l'expression régulière, mais il est clair que le caractère avant cela pourrait être une autre barre oblique, faisant de la deuxième barre oblique une barre oblique littérale et le signe dollar un marqueur de fin de ligne à nouveau.

Là encore, la solution suggérée semble en effet meilleure que le statu quo.

puis vérifiez un autre caractère s'il s'agit d'une barre oblique inverse. Cela signifie simplement que nous devons aller plus loin.

Considérez ^\\\\\\\\\\$

Je veux dire, oui, nous pourrions continuer à créer des exemples improbables que nous pourrions manquer, mais ne perdons pas de vue l'objectif réel d'améliorer les choses =)

Bien que le rognage résolve automatiquement le problème pour $ , certains déclencheurs et alias peuvent néanmoins avoir de l'espace à la fin, par inadvertance. Je dirais que dans la plupart des cas, ce ne sera pas souhaité... La solution universelle serait d'ajouter un indice.

Une autre option, peut-être pas la plus jolie, mais qui donnera certainement un bon indice, serait de donner au texte réel un arrière-plan différent de celui sous-jacent. Peut-être uniquement lorsqu'il se termine ou commence par des espaces.