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