[Rd] RFC: API to allow identification of warnings and errors in the output stream

[Thomas Friedrichsmeier]

> I am strongly opposed to locking in anything from the C internals of
> error handling that is not already part of the API.  This is all very
> much subject to change and anything along the lines you propose will
> make that change more difficult.

Let's discuss this in two separate parts, then. The first is: adding 
ptr_R_WriteErrConsole as an anologon to ptr_R_WriteConsole. I can see nothing 
wrong with that (of course I'm not an R developer), and it would already help 
me a lot. As I pointed out in the previous mail, a distinction between a 
"message" channel and an "output" channel is done everywhere in R, except in 
the interface pointers. The R_WriteErrConsole comes into play at the very end 
of the "message" channel (REvprintf), and only there, exactly parallel to how 
R_WriteConsole works/gets invoked.
Even if you're going to reject the other part of the proposed patch, please 
consider this small addition. If it helps, I can provide a stripped down 
patch for that.

I'll discuss the second part (making inError, inWarning and inPrintWarnings 
available) in more detail below.

> Condition handling was added to make this sort of thing possible.  If
> there are aspects of condition handling, or your understanding of
> condition handing, that need to be improved then we can work on that.

Both is quite possible. However I have reason to believe it's not just my 
understanding of condition handling that is lacking. If not so, I'll happily 
accept suggestions. Here's why I think condition handling will not help me 
much:

First, for clarification, let me tell you some more about what I need: Besides 
other GUI elements, there is a pseudo-console for running commands in R 
interactively (or at least providing that illusion). I reality, all commands 
are evaluated using R_tryEval (). Still, the user should not see any of this, 
and the "console" should behave mostly just like R in a plain terminal, 
including how errors are printed (+ marking up errors in another color, 
however).
So how could I use condition handlers?

a) Wrap each call inside withCallingHandlers (...) before evaluating it in 
R_tryEval ():
This would probably work, but add quite a bit of overhead for string 
manipulation, and parsing. The GUI runs a lot of small commands during normal 
operation. There are additional hazzles, such as error messages would then 
all look like "Error in withCallingHandlers(...", and I'd have to use yet 
more string operations to make them look normal.
Also: Can I be sure, that all warnings (i.e. even from C-code) are signalled 
as conditions? I'm afraid I do not fully understand the internal going-ons, 
here.

b) Use ".Internal (.addCondHands (...))" once to set up persistent handlers:
This worked fine, when testing it in the R-console. However, when testing in 
my GUI, it seems the condition handlers do not carry over between two 
successive calls of R_tryEval. So effectively, I'd once again be back at 3a.

Of course, if there was an API to efficiently set up condition handlers from 
C, and persist over at least one call of R_tryEval, I could in fact use that, 
and would happily do so. I have not found something like that, however.

Thanks!
Thomas