[ESS-bugs] OOps! ESS partly fails in non-English locales!

[Martin Maechler]

>>>>> "MM" == Martin Maechler <maechler at stat.math.ethz.ch>
>>>>>     on Tue, 2 Aug 2005 15:02:31 +0200 writes:

>>>>> "StEgl" == Stephen Eglen <S.J.Eglen at damtp.cam.ac.uk>
>>>>>     on Tue, 2 Aug 2005 12:31:40 +0100 writes:

    StEgl> thanks for follow up Martin.

    >>> One thing: May be it is not "more problematic" than the problem I
    >>> reported.  The "only" mistake is the mini-buffer message "Not a
    >>> syntax error", but then one at least gets to see a relatively
    >>> simply to understand message.

    StEgl> Yes, agree - sorry, "problematic" was a bad choice of wording from me.

    StEgl> I can fix the regexp for this particular error:

    StEgl> Error in parse(file, n = -1, NULL, "?") : syntax error on line 3

    StEgl> perhaps by a regexp searching for

    StEgl> syntax error on line [line number]

    StEgl> but is that likely to be good enough for catching all R errors?

    MM> not all R errors for sure.

In the mean time, I've checked what happens for S-plus 6.2:
It also says "Not a syntax error" and shows you *ESS-errors*
which is

------------------------------------------------
Problem in parse(n = n, file = file): Syntax error: No opening parenthesis before unbalanced (")")  on input line 1, file "/u/maechler/R/err.R" 
Use traceback() to see the call stack
------------------------------------------------

{which is actually quite superior to R's error message !}


    MM> But for C-c C-l, we know that R (and S-plus) uses source(),
    MM> so we have to think about the errors that happen from source().

{the above just confirms, that also for S-plus, source() -> parse() is
 called and giving syntax error message}


    MM> There, the syntax error is really a special interesting case,
    MM> because that one can be pointed to by a line number.
    MM> For R, it will always happen from
    MM> .Internal(parse(file, n = -1, NULL, "?")))

    MM> now that leads to calling do_parse in source.c, i.e.
    MM> https://svn.R-project.org/R/trunk/src/main/source.c

    MM> which shows you

    MM> if (status != PARSE_OK)
    MM> errorcall(call, _("syntax error on line %d"), R_ParseError);

    MM> The "errorcall(call, ..)" part entails that the message (in an
    MM> English locale!) will be

    MM> Error in parse(.....) : syntax error on line <n>

    MM> In a German locale, it's e.g.

    MM> Fehler in parse(file, n = -1, NULL, "?") : Syntaxfehler in Zeile 1

    MM> --

    MM> Hence, for English

    MM> "^Error .* syntax error"

    MM> or German

    MM> "^Fehler .* Syntaxfehler"

    MM> would work.
    MM> I think ideally, one would make use of the things we have
    MM> already
    MM> ess-dump-error-re  ( == "[Ee]rror" for English)

    MM> and/or better of something derived from

    MM> (defvar ess-R-message-prefixes
    MM> '("Error:" "Error in"
    MM> "Warning:" "Warning in"
    MM> "Warning messages?"))

    MM> (which would need to be put in two parts: one for errors the
    MM> other for warnings).

    MM> --------

    MM> I still think the best solution would be that R (or S-plus or
    MM> ...) at startup of "inferior-*"
    MM> produces these errors on purpose by eval-ing erronous examples
    MM> i.e. sends some commands to R such as 

    MM> parse(text="1]")
    MM> eval(parse(text="rpois(-1)"))
    MM> eval(parse(text="rpois(-1,1)"))
    MM> cat("1]", file=(.tf <- tempfile())) ; try(parse(file=.tf)); unlink(.tf)

    MM> and out of the R (or S+ ..)
    MM> error message  auto-produces the relevant pattern to use.

    MM> This way, ESS adapts to the system, including locale setting,
    MM> also for future systems / locales.

    MM> Martin