[R-gui] NEdit Highligth patterns for R

[Philippe Grosjean]

Well said. In general, I appreciate extensions provided in recent versions
of R to ease UI development. For instance, addTaskCallback() is of utmost
importance to communicate information to an object explorer " a la Splus",
but that is another story... However, there are at least two reasons why a
synthax highlighting that does not use the internal R parser would be a good
choice:

1) Independence of the script editor and the R parser allows edition of the
next code line while R computes the previous one. It is not the way the R
console operates: the user must wait that the last command line is achieved
before issuing the following one. Should it always be like that, hum?

2) The parser would identify the correct top level command 'c <- 1' and will
of course not color 'c' as the function c(), which it is not here. However,
I believe that the synthax highlighting should be a mean to warn the user
that he should avoid using 'c' as a variable name because it could be
confusing with the name of an existing function. Also, giving no particular
color to 'c2' in 'c2 <- function(....){....}' would indicate that the name
'c2' is "safe" for a new custom function, while coloring 'c' in 'c <-
function(){}' is a way to tell: "take care, you redefine an existing
function,... is it really what you want do?". Considering the damages an
innocent 'c <- function(x, ...) sum(x, ...)' can do, such a synthax
highlighting technique is useful.

Indeed, there are very few cases, in the S language, where a simple
dictionnary would fail in producing the right colour if synthax highlighting
is used this way, except perhaps mismatch between function and argument
names.

Best,

Philippe

-----Original Message-----
From: r-sig-gui-admin@stat.math.ethz.ch
[mailto:r-sig-gui-admin@stat.math.ethz.ch]On Behalf Of Duncan Murdoch
Sent: vendredi 11 octobre 2002 6:56
To: r-sig-gui@stat.math.ethz.ch
Subject: Re: [R-gui] NEdit Highligth patterns for R


(Apologies if anyone sees this twice; my first attempt seemed to
disappear.)

On Fri, 11 Oct 2002 10:00:03 +0200, Philippe Grosjean wrote:

>2) Of course, one could statically define the dictionnary with, let's say,
>all functions and arguments in the base and recommended packages. I would
>prefer a dynamic construction of the dictionnary: when a library is loaded,
>terms are added, when it is unloaded, they are eliminated. This is only
>possible with a bidirectionnal communication between the editor and the R
>calculation kernel. I got this in SciViews but how to do that in Nedit or
>other separate script editors?

This can be done without bidirectional communication.  R already
maintains the dictionaries you need, so you could query R to find out
how to colour each identifier.

Distinguishing between local and global identifiers is hard.  To do
that the editor needs to parse the code to see if you're in a
function, and to see what local identifiers have been defined.  But in
the editor, functions aren't fully written, so you need a parser that
can handle lots of syntax errors and still do useful things, or at
least one that can keep building the parse tree until it hits an error
and save the partial results at that point.

Adding flexibility like this to the parser would have lots of side
benefits.  It would let you write a debugger that knows the source
file line corresponding to each bit of code being executed, editors
could jump to syntax errors in the source file, hints about function
arguments could be made available in the editor, etc.

Duncan Murdoch
_______________________________________________
R-SIG-GUI mailing list
R-SIG-GUI@stat.math.ethz.ch
http://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui