Is there any way to capture the expanded content of a message (in the
sense of l3msg) in a token list variable? As I understand it, messages
at present go either to the terminal or the log file. To use a message
in some other way, doesn't seem to be allowed for.
The question arises from the following context. I've been writing a
program that takes mathematical expressions constructed in LyX's math
editor, changes them into a form that can be digested by l3fp, and uses
the mini-LaTeX runs of LyX's instant preview facility to evaluate and
display the result. Each preview run creates a LaTeX log but that is
buried in the temporary directory where LyX does its previewing and is
not easily accessed by the LyX user, unlike the LaTeX log for the whole
document which can be displayed in a LyX window. I've put in an
enhancement request to make the preview log similarly available but that
has attracted no interest whatever. Hence the wish to make at least some
messages available to be displayed in the preview inset (where the
calculated result would otherwise have gone).
Certainly I can capture errors that occur at the level of what I've
programmed and display an appropriate message in the preview inset,
although it's frustrating not being able to use the l3msg machinery for
this purpose. But errors that occur at the level of l3fp seem
frustratingly inaccessible. Many of these errors are not fatal or
critical. (For instance an extra, or absent, parenthesis is often
harmless: try \fp_eval:n { 3((1+1) }. It will flag an error, "Missing )
inserted." but one press of the <return> key and the correct answer, 6,
is displayed.) A more appropriate response than the preview never
compiling, which is what happens now, would be to let compilation
continue if it can, and display the message in the preview inset.
I write in happy ignorance of kernel internals, but envisage (for
instance) a new class of message, "display" perhaps, to which certain
errors could be redirected. This class, like "warning" and "info",
would not stop compilation, although subsequent cumulating errors might
have that consequence, but try to 'blunder on' (like the "r" option in
TeX) and, unlike the other classes, would load the message into a
tl-variable and set a boolean. The higher level program would check for
the boolean and branch to display the tl-variable (in my case, in the
preview inset displayed within the larger LyX document). The "display"
class, with the associated l3msg machinery, would also be available to
the higher level program for its own messages.
Andrew
|