Unbalanced parentheses crash Xemacs+ESS
Richard M. Heiberger
rmh at temple.edu
Fri Aug 20 20:30:40 CEST 2004
I have always considered this to be a problem with S-Plus and R, not with ESS.
ESS and Emacs do syntax highlighting based on what they see. They are not able
to impute what the user intended the code to look like.
I think the right ESS response to unbalanced parentheses in warnings() and traceback()
listings is to change the value of an option in S-Plus and R that would make
them complete the displayed statements. I would like something like
options(deparse.length=1000)
but that doesn't currently exist. I think therefore that the best ESS solution
is to override in frame 0 the default deparse() with a replacement function
that uses the proposed deparse.length option. I started to do this, but found it
looks like more than a 10-minute exercise. If someone works it out for both
S-Plus and R (I anticipate it will be different for each) I will be happy to
install it in ESS.
There are two ways to do the override. The one I like best is to make the
S-Plus or R deparse() function sensitive to the value of options()$STERM.
This is an option that ESS sets when it starts S-Plus or R under its control.
It has the value "iESS" for Sqpe and R running in an emacs buffer, and the value
"ddeESS" for the S-Plus GUI on Windows controlled through the dde protocol.
This option requires the R and S-Plus developers to change their function.
The other option is for ESS to send over a replacement for deparse when ESS starts
up the inferior S-Plus or R process. This is the option we will most likely actually
use.
The replacement function for deparse is the same with either deployment method.
Rich
More information about the ESS-help
mailing list