Stephen Eglen's notes on future changes to ESS -*- org -*- * Problem with ESS infrastructure and Martin away? Email isg@math.ethz.ch * ess-history-file needs documenting and possibly updating: From: Stephen Eglen To: Erik Iverson Comments: In-reply-to Erik Iverson message dated "Wed, 20 Apr 2011 09:36:26 -0500." Date: Tue, 26 Apr 2011 09:01:29 +0100 Cc: Feng Li , ess-help@stat.math.ethz.ch Subject: Re: [ESS] ESS and .Rhistory Sender: ess-help-bounces@r-project.org Dear Erik, Feng, Thanks for this -- I was blissfully unaware about this persistence of history across R sessions. Howabout if we change the semantics of ess-history-file to be: nil -- do not attempt to read/write a history file t -- use the default naming scheme for loading the history "some.string" -- use this value as the filename. Stephen > Feng, > > On 04/20/2011 09:00 AM, Feng Li wrote: > > Dear list, > > > > I tried to change the ESS default R history to a permanent file so > > that ESS does not generate .Rhistory everywhere. I tried both > > > > (setq ess-history-directory "~/.R/history") > > > > and > > > > (setq ess-history-file "~/.R/history/.Rhistory") > > If I recall correctly, it's because of the way the ess-history-file > variable is set in the ESS code. The following works for me: > > (defun ei-no-rhistory () > (setq ess-history-file "/dev/null")) > > (add-hook 'inferior-ess-mode-hook 'ei-no-rhistory) * completion of functions within buffers From: Stephen Eglen To: ESS-help@stat.math.ethz.ch Date: Tue, 22 Jun 2010 14:00:25 +0100 Cc: Stephen Eglen Subject: [ESS] request for comments: completion within .R buffers Sender: ess-help-bounces@stat.math.ethz.ch Rodney recently kindly polled ess-help, and a summary of the results can be seen in the SVN sources at: https://svn.r-project.org/ESS/trunk/rsn.txt One thing that came up was (thanks Ista Zhan): Function/variable completion in script files (maybe this already is supposed to work, but for me completion only works in interactive sessions). Below is some suggested code to implement this, based on a hint from Deepayan. If you press TAB at the start of the line, you still get standard indentation, but if you are already typing something, e.g. write.t then hitting TAB will complete to write.table Hitting TAB again, will then bring up a *Completions* window showing (for me): Possible completions are: write.table write.table0 I don't like the *Completions* window hanging around, but apart from that, is that the sort of completion people would like? Erik Iverson mentioned something related: I think ESS is very feature complete at this point. The only thing I've looked at that seems interesting is some sort of 'intellisense' feature that uses R's built-in completion mechanism to temporarily display available completions using something like company-mode, autocomplete, or completion-ui. I had at one point something that almost worked, but I believe the library it was built in, company-mode, has now changed significantly. but I've not explored those options. Code/ideas welcome! Stephen ---------------------------------------------------------------------- (defun ess-indent-or-complete (&optional whole-exp) (interactive "P") "Function bound to TAB key in R mode buffers. If at the start of the line, or numeric prefix provided, call `ess-indent-command', otherwise try to complete object at point." (if (or whole-exp (save-excursion (skip-chars-backward " \t") (bolp))) (ess-indent-command whole-exp) (ess-complete-object-name))) (add-hook 'ess-mode-hook '(lambda () (local-set-key "\t" 'ess-indent-or-complete))) * ess-eldoc.el ** Switch to use R-mode-hook, rather than ess-mode-hook ** Document in the info node. * Debugger Would like to implement a debugger akin to Norm Matloff's work: http://cran.r-project.org/web/packages/edtdbg/index.html http://www.stats.uwo.ca/faculty/murdoch/software/debuggingR/ Norm posted that he had started work on ESS, but had to abandon it. * Comint so slow? ess-eval-visibly-p should be t again. Why is comint so slow when passing code line by line? Markus Triska recently looked at this: To: ess-help@stat.math.ethz.ch connect(): No such file or directory From: Markus Triska Date: Sun, 16 May 2010 13:59:57 +0200 Subject: Re: [ESS] ESS on Mac slower than R.app? Sender: ess-help-bounces@stat.math.ethz.ch Hi Rodney, Rodney Sparapani writes: > I think if you update to the latest version of ESS this problem will > go away. See the previous discussion of a very similar GNU Emacs bug > fix at https://stat.ethz.ch/pipermail/ess-bugs/2009q4/000584.html I think ess-eval-visibly-p should remain true by default, as it is quite useful. If you change the accept-process-output call in ess-eval-linewise to: (accept-process-output sprocess 0 timeout-ms) (the difference being that you explicitly state to wait for input from "sprocess"), the test case works instantly also with ess-eval-visibly-p. All the best, Markus * Funny indentation if semicolon follows brace: From: Stephen Eglen To: Paul Burkander Comments: In-reply-to Paul Burkander message dated "Sat, 04 Jun 2011 10:17:03 -0400." Date: Mon, 06 Jun 2011 10:35:27 +0100 Cc: ess-help@r-project.org Subject: Re: [ESS] ess-indent-exp follow OWN style? Sender: ess-help-bounces@r-project.org > I think it must be ess-electric-brace, and I think it warrants a bug report. > > The behavior is the same in R and Stata (though I don't know if it > would ever come up in R) > > Typing any line (excluding comments) that ends in { sets the > indentation of the next line to ess-indent-level > Typing any line (excluding comments) that ends in {; sets the > indentation of the next line to so that the first character is below > the preceding semicolon. > > I know basically nothing about Lisp, otherwise I'd like to try to > debug this thing.  It seems like an important replicable issue that > warrants a bug report. Thanks; I can see this behaviour in R mode. As I don't think its a common idiom in R to write something like for (i in seq) {; ... I'm afraid its not high enough on my priority list to fix right now (sorry, too many other things already need fixing in ESS), but I will make a note of it. Is this biting other users? Stephen ** is ess-electric-brace working okay? should reindent line? * Handing the *ESS* buffer Is the *ESS* buffer necessary for end users? If not, have a toggle to switch it off. From: Stephen Eglen Date: Mon, 6 Jun 2011 22:12:08 +0100 > Re: the *ESS* buffer, how much of a pain is it? I recall also > finding it a bit offputting seeing this many years ago, and in all > my years of developing ESS, I for one have yet to find reason of > inspecting it! I imagine other developers may differ -- but one > thing I could suggest to other core members is having a variable > to inhibit this buffer? This could be as simple as having a variable ess-dribble-buffer which if nil, means that the buffer is not created, otherwise, the variable contains (as a string) the name of the buffer to use, which defaults to "*ESS*". It could even be " *ESS*" so that it doesn't appear in buffer lists, but is there and will be included into reports generated by ess-submit-bug-report. * Add ess-r-versions-list Subject: Re: [ESS] Customisation of ess-r-versions or ess-r-versions-list From: John Maindonald Date: Thu, 18 Aug 2011 10:19:44 +1000 Cc: ess-help@stat.math.ethz.ch To: Stephen Eglen On 18/08/2011, at 5:38 AM, Stephen Eglen wrote: >> Yes, >> (setq ess-s-versions-list >> '( ("R64" "/usr/bin/R64") >> ("R32" "/usr/bin/R32"))) >> works. The buffer for R64 is however called *S+6*. No doubt there is >> some variable that one can set that will fix this; I have not >> investigated. > I don't recall ever doing this for R, but this was quite a few years > ago. Did it ever work for you in earlier versions of ESS? The lines that I had commented out had 'ess-r-versions-list'. If this variable has never been available, this would be something that I tried by analogy with 'ess-s-versions-list' and never did work. If 'ess-s-versions-list' is to stay, it would seem to be cleanest to have a matching 'ess-r-versions-list' also, following the precedent of 'ess-s-versions' and 'ess-r-versions'. An advantage of this way of doing things (an 'ess-r-versions-list'), for some users at least, is that it is explicit about the command line statement that is invoked. > One can have defvar in place of setq. Does it matter which one uses? > Better to use setq -- as it will always update the value. By contrast: > > (defvar apple 1) > (defvar apple 2) > > Evaluate both lines above, in order, and check "apple" -- it has the > value 1. > > Stephen John Maindonald email: john.maindonald@anu.edu.au phone : +61 2 (6125)3473 fax : +61 2(6125)5549 Centre for Mathematics & Its Applications, Room 1194, John Dedman Mathematical Sciences Building (Building 27) Australian National University, Canberra ACT 0200. http://www.maths.anu.edu.au/~johnm * Toolbar is missing from file.Rt transcript buffers Add toolbar?