[ESS-bugs] tracking options(continue= *) etc ? {was "..Starting eval... hangs"}

[Martin Maechler]

>>>>> "StEgl" == Stephen Eglen <S.J.Eglen at damtp.cam.ac.uk>
>>>>>     on Mon, 21 Aug 2006 09:43:05 +0100 writes:

    >> I actually had the same thought..
    >> 
    >> So, Stephen here tells how to do it "manually" :
    RoSp> http://article.gmane.org/gmane.emacs.ess.general/1835
    >> 
    >> {{Stephen: It would be phantastic if you could add this to the 
    >> ESS manual ...}}

    StEgl> I have added this text to the Bugs section of the manual:

    StEgl> * Changes to the continutation prompt in R (e.g.  `options(continue
    StEgl> = "    ")') are not automatically detected by ESS.  Hence, for
    StEgl> now, the best thing is not to change the continuation prompt.  If
    StEgl> you do change the continuation prompt, you will need to change
    StEgl> accordingly the value of `inferior-ess-secondary-prompt' in
    StEgl> `R-customize-alist'.

Thanks a lot!


    >> Of course, in principle, ESS could track even more than it does now:
    >> it currently already looks at  "?"  "help("  "library(" ..
    >> and takes action for these.
    >> 
    >> So we could do the same for options(..)
    >> and in particular not only for
    >> options(prompt   = .)      and
    >> options(continue = .)  
    >> but also
    >> options(width = .)  
    >> 
    >> But of course the drawback of such an approach is that it only
    >> works when the functions are used explicitly at the prompt,
    >> but not when they are inside "eval-region" {which actually
    >> already now can be a bit confusing} or even when just inside
    >> another function that is called.

    StEgl> Alternatively, if this was something that many people needed, what
    StEgl> about a new function, ess-R-parse-options, that when called by the
    StEgl> user (kind of like ess-resynch-completions!), will examine the current
    StEgl> settings in options(), and change things accordingly.

That's a very good proposal, and definitely better from a
maintenance point of view!

Actually, it should be  'ess-S-parse-options'
since options() is a "good old S" concept,
and those options we are talking about
 ('prompt','continue','width')
are all shared by all implementations of S.

Martin