Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
References: <LISTSERV%200809171514075698.0309@LISTSERV.UNI-HEIDELBERG.DE>
Message-ID:  <C881AF7A-7D67-4AA9-9516-4716999B5BEB@gmail.com>
Date:         Wed, 17 Sep 2008 23:33:40 +0930
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: Will Robertson <wspr81@GMAIL.COM>
Subject: Re: l3messages
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <LISTSERV%200809171514075698.0309@LISTSERV.UNI-HEIDELBERG.DE>
Precedence: list
Status: R

Hi,

Thanks for summarising this; I've added it to the internal "todo" for  
this package.

On 17/09/2008, at 10:44 PM, Joseph Wright wrote:

> - The module prefix \err is not really that helpful, as some of the
> functions are related to information rather than errors: would \msg_  
> be
> better (at least for the non-error parts)?

This is a rather sweeping change but I agree. \msg_ is pretty good, I  
think.

> - Saving the error messages to file to save memory is not really  
> relevant
> today, especially as every message needs a tlp in any case.

AND all my working directories keep being littered with .err files :)

> - On the other hand, perhaps having the errors in this way makes
> localisation of messages easier? Is this something that should be
> considered, and if so an alternative mechanism is needed.

I highly, highly approve of writing out error messages (and even  
warnings) separately.
I think the interface that we currently has suffices for a lower  
layer, but like you say we need a better "package author" user  
interface.

I'd imagine hypothetical commands like this: (note the first argument  
of each)

...
\msg_def:Nnnpnn \msg_log: {fontspec/AREA/TAG1}
    #1 {Message with arg '#1'}{"Possible Help text"}

\msg_def:Nnnpnn \msg_info: {fontspec/AREA/TAG2}
    #1 {Message with arg '#1'}{"Possible Help text"}

\msg_def:Nnnpnn \msg_warn: {fontspec/AREA/TAG3}
    #1 {Message with arg '#1'}{"Possible Help text"}

\msg_def:Nnnpnn \msg_err:  {fontspec/AREA/TAG4}
    #1 {Message with arg '#1'}{"Possible Help text"}
...

Used inside the package like this:

\msg_show:nw {fontspec/AREA/TAG1} {<arg>}
\msg_show:nw {fontspec/AREA/TAG2} {<arg>}
\msg_show:nw {fontspec/AREA/TAG3} {<arg>}
\msg_show:nw {fontspec/AREA/TAG4} {<arg>}


This is something of a hybrid between the current expl3 approach and  
what LaTeX2e currently provides. You can imagine the appropriate  
"syntactic sugar" to make it a little more appealing to package authors.

The next important step is that users would then be able to override  
the status of errors. Sick of the warning "fontspec/AREA/TAG3" ? Put  
this in your preamble:

   \MessageStatus{fontspec/AREA/TAG3}{log}

or something like that. Similarly, if you're computing ArcTan{1/0} you  
might want

   \MessageStatus{kernel/math/DivideByZero}{ignore}

You could also provide generic "verbose" and "quiet" modes to promote/ 
demote all messages by one level.

   \MessageStatus{warn}{log}

Or just for particular packages.

   \MessageStatus{fontspec/*/*, warn}{log}


(I'm thinking of something like David Kastrup's makematch syntax for  
this first argument in all the examples above. Whatever the syntax is,  
I think you get the idea.)

***

Anyway, this is purely conjecture at this stage. Any further thoughts?

Will