sje-ess-notes.txt

Stephen Eglen's notes on future changes to ESS                   -*- org -*-

* Problem with ESS infrastructure and Martin away?  Email [email protected]
* ess-history-file

needs documenting and possibly updating:

From: Stephen Eglen <[email protected]>
To: Erik Iverson <[email protected]>
Comments: In-reply-to Erik Iverson <[email protected]>
	message dated "Wed, 20 Apr 2011 09:36:26 -0500."
Date: Tue, 26 Apr 2011 09:01:29 +0100
Cc: Feng Li <[email protected]>, [email protected]
Subject: Re: [ESS] ESS and .Rhistory
Sender: [email protected]

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 <[email protected]>
To: [email protected]
Date: Tue, 22 Jun 2010 14:00:25 +0100
Cc: Stephen Eglen <[email protected]>
Subject: [ESS] request for comments: completion within .R buffers
Sender: [email protected]

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: [email protected]
connect(): No such file or directory
From: Markus Triska <[email protected]>
Date: Sun, 16 May 2010 13:59:57 +0200
Subject: Re: [ESS] ESS on Mac slower than R.app?
Sender: [email protected]

Hi Rodney,

Rodney Sparapani <[email protected]> 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 <[email protected]>
To: Paul Burkander <[email protected]>
Comments: In-reply-to Paul Burkander <[email protected]>
	message dated "Sat, 04 Jun 2011 10:17:03 -0400."
Date: Mon, 06 Jun 2011 10:35:27 +0100
Cc: [email protected]
Subject: Re: [ESS] ess-indent-exp follow OWN style?
Sender: [email protected]

> 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 <[email protected]>
  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 <[email protected]>
Date: Thu, 18 Aug 2011 10:19:44 +1000
Cc: [email protected]
To: Stephen Eglen <[email protected]>

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: [email protected]
phone : [phone]    fax  : [phone]
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?