# nulib\output

* dans msg::action($m, function() {}), *bloquer* la marque pour empêcher d'aller
  plus bas que prévu. comme ça s'il y a plusieurs success ou failure dans la
  fonction, c'est affiché correctement.

* [ ] possibilité de paramétrer le nom du fichier destination pour faire une
  rotation des logs
  * [ ] lors de la rotation, si l'ouverture du nouveau fichier échoue, continuer
    à écrire dans l'ancien fichier
  * ou alors un moyen pour ré-ouvrir la sortie, afin de pouvoir indiquer à un
    long running process qu'une rotation a eu lieu
* [ ] dans `StdMessenger::resetParams()`, `[output]` peut être une instance de
  StdOutput pour mettre à jour $out ET $err, ou un tableau de deux éléments pour
  mettre à jour séparément $out et $err
* [ ] vérifier que la date affichée pour un TITLE est celle à laquelle l'appel
  a été fait, même si le premier événement en dessous arrive bien plus tard
* [ ] pareil pour action: sauf si c'est une seule ligne, la date de action est
  la date du premier appel, alors que la date de $result est celui du result si
  c'est affiché sur une autre ligne
* réorganiser pour que msg:: attaque un proxy dans lequel est configuré un
  ensemble standard de sorties: say, log, debuglog
  * `--aD, --av, --aq, --asilent` pour les valeurs d'ajustement qui sont un
    incrément à la valeur courante (+2, +1, -1, -2)
  * `--yD, --yv, --yq, --ysilent, -D, -v, -q, --silent` pour say
  * `--lD, --lv, --lq, --lsilent` pour log, `-L:, --L` l'active
  * `--DD, --Dv, --Dq, --Dsilent` pour debuglog, `--DL:` l'active

question à régler: trouver un moyen pour que l'affichage web soit "un niveau au
dessus" afin de ne pas se retrouver avec dans les logs des messages uniquement
pour l'UI
peut-être rajouter `ui` (ou `web`?) en plus de say, log, debuglog?
--> ou renommer `say` en `console`, et `ui` en `say`

* [ ] ajouter une option `Application::MSG_SIGNALS` qui fait que
  * les méthodes `msg::eXXX()` appellent automatiquement `app::_dispatch_signals()`
* [ ] ajouter une option `Application::MSG_ACTIONS` qui fait que
  * `msg::section()` et/ou `msg::title()` appellent automatiquement `app::action()`
  * `msg::estep()` appelle automatiquement `app::step()`

* support des logs structurés: log:: ajoute des objets json, un par ligne, dans
  le fichier destination. msg::, say:: mettent en forme l'information structurée.
  * clés standards: timestamp, user, tech, exception
  * string ou list deviennent ["user" => string|list]
    ne pas faire cette transformation si le tableau est associatif
  * un trait Tlogger permet de spécifier le cas échéant comment mettre en forme
    une donnée structurée --> il permet de calculer les valeurs de user_message
    et tech_message

-*- coding: utf-8 mode: markdown -*- vim:sw=4:sts=4:et:ai:si:sta:fenc=utf-8:noeol:binary