[ESS] Font-locking

[Martin Maechler]

>>>>> "StEgl" == Stephen Eglen <S.J.Eglen at damtp.cam.ac.uk>
>>>>>     on Fri, 03 Apr 2009 16:16:58 +0100 writes:

    StEgl> S. McKay Curtis <smcurtis at stat.washington.edu> wrote:
    >> I'm still hoping somebody will show me a more elegant
    >> way, but the way above works for now.

    StEgl> Your recipe sounds as good as any.  One 'neat' way
    StEgl> might to get emacs to ask R dynamically for teh list
    StEgl> of possible functions, but that might be overkill as
    StEgl> you probably start and stop emacs far more many times
    StEgl> than new versions of R are released (and hence the
    StEgl> list changing).  What might make sense is for ESS to
    StEgl> include a text file with the output of:

    StEgl> base.obj <- objects("package:base",all.names=TRUE)
    StEgl> base.obj[-grep("(^[^.[:alpha:][:digit:]]|<-|__)",base.obj)]
    StEgl> write(base.obj, file='/tmp/r_names.txt')

    StEgl> (with that file being updated after every major
    StEgl> release of R) and then, upon loading ESS within
    StEgl> Emacs, that file is consulted, and the functions
    StEgl> added to the keywords to be font locked.  (All
    StEgl> customizable of course so that users who don't want
    StEgl> this behaviour won't get annoyed by everything
    StEgl> lighting up.)

Hmm, sorry to say, but I don't like the approach at all, as a whole.
"base" is just the most basic of the  "base R" packages,
which notably also includes "stats" if you want  to see
'median' or 'var' highlighted.
And then, where should stop?

In R 2.8.1,  we have

 > (ip <- installed.packages(lib.loc = tail(.libPaths(), 1)))[,c(1,3:5)]
	    Package      Version   Priority      Bundle
 base       "base"       "2.8.1"   "base"        NA    
 boot       "boot"       "1.2-34"  "recommended" NA    
 class      "class"      "7.2-45"  "recommended" "VR"  
 cluster    "cluster"    "1.11.11" "recommended" NA    
 codetools  "codetools"  "0.2-1"   "recommended" NA    
 datasets   "datasets"   "2.8.1"   "base"        NA    
 foreign    "foreign"    "0.8-29"  "recommended" NA    
 graphics   "graphics"   "2.8.1"   "base"        NA    
 grDevices  "grDevices"  "2.8.1"   "base"        NA    
 grid       "grid"       "2.8.1"   "base"        NA    
 KernSmooth "KernSmooth" "2.22-22" "recommended" NA    
 lattice    "lattice"    "0.17-17" "recommended" NA    
 MASS       "MASS"       "7.2-45"  "recommended" "VR"  
 methods    "methods"    "2.8.1"   "base"        NA    
 mgcv       "mgcv"       "1.4-1.1" "recommended" NA    
 nlme       "nlme"       "3.1-89"  "recommended" NA    
 nnet       "nnet"       "7.2-45"  "recommended" "VR"  
 rpart      "rpart"      "3.1-42"  "recommended" NA    
 spatial    "spatial"    "7.2-45"  "recommended" "VR"  
 splines    "splines"    "2.8.1"   "base"        NA    
 stats      "stats"      "2.8.1"   "base"        NA    
 stats4     "stats4"     "2.8.1"   "base"        NA    
 survival   "survival"   "2.34-1"  "recommended" NA    
 tcltk      "tcltk"      "2.8.1"   "base"        NA    
 tools      "tools"      "2.8.1"   "base"        NA    
 utils      "utils"      "2.8.1"   "base"        NA    
 > 

and in R 2.9.0 (released within two weeks), there's the
additional Matrix package (just "recommended"),
but why stop here?

If you work in biostats, you may want "survival" ("recommended",
not "base"), and in biology you may want the functions from
bioconductor bioBase, or in earth sciences, you "need" all of 
'sp', i.e., from packages that are neither "base" nor
(explicitly) "recommended".

I'd prefer the current approach of just highlighting very few language
"keywords".

If we want to optionally allow users to go beyond,
then the should specify a list of R packages (with a default of
all "base" packages ?) from which they want functions to be highlighted.
Maybe ESS could use a cache-file, and update that file whenever
it's older than 6 months ( = y-release cycle of R x.y.z) ?

Martin