User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0)
            Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <541F658C.2000007@clear.net.nz>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <543A7F27.8050708@morningstar2.co.uk>
Date:         Sun, 12 Oct 2014 14:16:23 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: Capturing messages in a token list variable?
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <541F658C.2000007@clear.net.nz>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 22/09/2014 00:55, aparsloe wrote:
> 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

There are at least a couple of issues here. The first is that (TeX)
messages are tied pretty closely to the log/terminal. Thus the usual
approach to dealing with any automation is to parse the log after a run
and extract the information. The l3msg system is designed to work with
this as the messages all have 'names' and can be set to display just
that information in the log. Capturing in a token list is for 'standard'
messages doable but not something built-in.

The bigger issue in the context given is that we are talking about
expandable messaging. Floating point calcs are expandable, and we can't
issue 'normal' messages there. Nor can we set any variables, and that is
an issue with the requested functionality: it's not doable in TeX.
--
Joseph Wright