Improve log search with multi-term and exclusion support

[limad]

Superseded by #3313, which was extracted from #3303 at the request of @Salvialf and @Mips2648 to keep functional changes separate from the var→const/let refactoring PR.

[Mips2648]

Hello,
Thanks for re-submitting this PR

I've few questions:

• Why use coma for term separation? I feel it is more common and intuitive to use a space
• why using var and not let ?

[limad]

Hello

• Why use coma for term separation? I feel it is more common and intuitive to use a space
  Peu importe.
• why using var and not let ?
  pour éviter des problèmes JS connues sur le fronted Jeedom "...already declared", le code d'origine est aussi en "var"

[Mips2648]

Peu importe

non, pas "peu importe": le but ce n'est pas de faire n'importe quoi, n'importe comment donc c'est important de réfléchir à tous les aspects: qualité du code, pertinence de l'idée, UX, facilité d'utilisation etc...

et par rapport au var vs let;
c'est une mauvaise pratique d'utiliser var, le défaut en JS actuellement est d'utiliser des const si possible ou let lorsqu'on doit modifier mais pour que dans les 2 cas le scope soit limité et sous controle.
si une autre var existe dans le dom, c'est juste écrasé car variable globale...

ici on est dans une fonction et c'est clair que son but n'est pas de ré-utiliser des variables globales, donc la réponse "pour éviter des problèmes already declared" est injustifiée.
Ce n'est pas parce que c'était comme ca qu'on ne peut pas améliorer la situation progressivement...

---

Nouveau et dernier point pour l'instant:
pourquoi juste gérer ce champ de recherche? si on veut garder une cohérence et que les utilisateurs s'y retrouvent, la feature "multi-terms search" devrait exister ailleurs aussi probablement;
il faut au moins se poser la question

[limad]

non, pas "peu importe": le but ce n'est pas de faire n'importe quoi, n'importe comment donc c'est important de réfléchir à tous les aspects: qualité du code, pertinence de l'idée, UX, facilité d'utilisation etc...

J'avais mis "virgule" car cela me paraissait cohérent et plus rationnel d'avoir un caractère qu'on ne peut pas rencontrer couramment. Si d'autres personnes jugent qu'un espace est mieux pour les logs, pourquoi pas, du moment qu'on a la fonctionnalité.

par rapport au var vs let; c'est une mauvaise pratique d'utiliser var, le défaut en JS actuellement est d'utiliser des const si possible ou let ...

Ma PR est une "New feature (non-breaking change which adds functionality)" et non une "code review".
Il serait plus cohérent de traiter les questions de let/var/const dans des PR spécifiques et pour l'ensemble des JS du core.

Nouveau et dernier point pour l'instant: pourquoi juste gérer ce champ de recherche? si on veut garder une cohérence et que les utilisateurs s'y retrouvent, la feature "multi-terms search" devrait exister ailleurs aussi probablement; il faut au moins se poser la question

Certainement, j'ai fait la PR pour les logs (que j'utilise souvent), mais ce besoin peut concerner d'autres pages.

Plus globalement, je ne sais pas s'il existe des règles pour soumettre des PR sur le Core, mais il serait bien d'en établir quelques-unes, pour que chacun ne perde pas son temps.