gmane.emacs.ess.general

Re: Problem with Sweave after upgarde to 13.05

2013-05-23T21:39:40

Hi, I re-installed ESS 12.09 and all works fine. I think the problem is
about the latest ESS version (13.05) with emacs 23.1. I also tried your
suggestion (to remove all of my noweb configuration) but nothing
changed. Unfortunly there were no error message.

Best Regards, Riccardo 

On Thu, 2013-05-23 at 19:30 +0200, Vitalie Spinu wrote:

______________________________________________
ESS-help< at >r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: Problem with Sweave after upgarde to 13.05

Vitalie Spinu — 2013-05-23T17:30:52

Hi Riccardo, 

Do you see any errors messages? From what version did you upgrade?

Try to remove all of your noweb configuration from your .emacs. It
should work by default. If not, try upgrading your emacs to a more
recent version. Last time I tested ess-noweb with 23.3, it worked fine.

    Vitalie

 >> r <ric.romoli< at >gmail.com>
 >> on Thu, 23 May 2013 16:10:29 +0200 wrote:

 > Hi, my name is Riccardo, I use EMACS 23.1.1 and I have some trouble
 > after I upgrade ESS to the latest version (13.05). In particular I'm
 > having trouble working with .Rnw files because emacs is not able do
 > distinguish between ESS code and LaTeX code, and the major mode of the
 > buffer still remain in ESS mode and do not switch to LaTeX when I edit
 > the TeX code.  

 > I hope you can help me.

 > Best Regards, Riccardo

 > ______________________________________________
 > ESS-help< at >r-project.org mailing list
 > https://stat.ethz.ch/mailman/listinfo/ess-help

______________________________________________
ESS-help< at >r-project.

Problem with Sweave after upgarde to 13.05

2013-05-23T14:10:29

Hi, my name is Riccardo, I use EMACS 23.1.1 and I have some trouble
after I upgrade ESS to the latest version (13.05). In particular I'm
having trouble working with .Rnw files because emacs is not able do
distinguish between ESS code and LaTeX code, and the major mode of the
buffer still remain in ESS mode and do not switch to LaTeX when I edit
the TeX code.  

I hope you can help me.

Best Regards, Riccardo

______________________________________________
ESS-help< at >r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

ESS hangs emacs start

Ross Boylan — 2013-05-22T03:49:48

I thought I'd report this even though the case may be too idiosyncratic to
worry about. I recently found  that emacs hung on startup, consuming all
CPU, after an eccentric uninstallation of R.

See the bottom for a solution; I don't currently have any problem.

Windows XP, ESS from git 7c9f491805e06f3998ce841c5ac5330e25bb38fb, which I
think is a few commits post the 13.05 release (ESS as of a few days ago). 
The system is partly locked down so that I can install programs but not
access the add/remove programs to remove them (!).

R 3.0.0 was installed at the start.
1. Run uninst000.exe from the top R directory under Program Files.
2. Some files could not be removed.  I think I may have had an R session
active, or at least the conventional R GUI up.  In particular, bin remains
with executables.
3. install R 3.0.1.
4. Start emacs 24.3.1.
5. It hangs with all CPU.
6. Typing ctl-G allows me to interact with emacs, though it continues to
consume all CPU.
7. The *ESS* buffer shows
(R): ess-r-versions-create making

Re: ess-history-file nil is not respected anymore

Marius Hofert — 2013-05-21T13:59:58

Thanks a lot for the quick help, Vitalie, now it works (I chose Option 4
:-) )

Cheers,

Marius


Vitalie Spinu writes:


______________________________________________
ESS-help< at >r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: ess-history-file nil is not respected anymore

Vitalie Spinu — 2013-05-21T13:36:28

Something went wrong with your update or you have some 
 >> Marius Hofert <marius.hofert< at >math.ethz.ch>
 >> on Tue, 21 May 2013 15:11:03 +0200 wrote:

 > Hi Vitalie,

 > thanks for helping.

 > I did several tests, but the variable it is not respected (anymore).
 > This is essentially my whole ESS setup in ~/.emacs:

 > (add-to-list 'load-path "/usr/share/emacs/site-lisp/ess/lisp")
 > (require 'ess-site)
 > (setq ess-eval-visibly-p nil)
 > (setq inferior-R-args "--no-restore-history --no-save ")
 > (setq ess-history-file nil)

Ah, ok. That makes sense. Because this variable is buffer local now, you
are not setting the default value. Either use custom interface, or move
(setq ...) line before (require 'ess-site), or just

   (set-default 'ess-history-file nil) 

That buffer local value is needed, but marking it buffer local could
have been avoided. I have adjusted that in SVN. Now you have the 4th
option, update your SVN:)

Thanks for the report, 

    Vitalie

______________________________________________

Re: ess-history-file nil is not respected anymore

Marius Hofert — 2013-05-21T13:11:03

Hi Vitalie,

thanks for helping.

I did several tests, but the variable it is not respected (anymore).
This is essentially my whole ESS setup in ~/.emacs:

--8<---------------cut here---------------start------------->8---
(add-to-list 'load-path "/usr/share/emacs/site-lisp/ess/lisp")
(require 'ess-site)
(setq ess-eval-visibly-p nil)
(setq inferior-R-args "--no-restore-history --no-save ")
(setq ess-history-file nil)
--8<---------------cut here---------------end--------------->8---

I restarted emacs, but C-h v ess-history-file reads:

--8<---------------cut here---------------start------------->8---
ess-history-file is a variable defined in `ess-custom.el'.
Its value is ".Rhistory"
Original value was t
Local in buffer *R*; global value is t
--8<---------------cut here---------------end--------------->8---

What's wrong?

Cheers,

Marius


Vitalie Spinu writes:


______________________________________________
ESS-help< at >r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: ess-history-file nil is not respected anymore

Vitalie Spinu — 2013-05-21T12:58:06

It still should work. It definitely does so for me. Check your
ess-history-file if it is indeed nil.

    Vitalie

 >> Marius Hofert <marius.hofert< at >math.ethz.ch>
 >> on Tue, 21 May 2013 14:35:57 +0200 wrote:

 > Hi,
 > I have

 > (setq ess-history-file nil)

 > in ~/.emacs to avoid that .Rhistory files are written. This worked well
 > for me for quite some time until I updated to 13.05-1 [rev. 5586
 > (2013-05-17)]. Since then it shows .Rhistory and not nil (maybe this is
 > due to
 > https://github.com/emacs-ess/ESS/commit/710f4e462f0ede6e9f09ae9bd46f83ebaa3cfb77?).

 > The question is, how can I get 'nil', so really no .Rhistory being
 > written?

 > Thanks & cheers,

 > Marius

 > ______________________________________________
 > ESS-help< at >r-project.org mailing list
 > https://stat.ethz.ch/mailman/listinfo/ess-help

______________________________________________
ESS-help< at >r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

ess-history-file nil is not respected anymore

Marius Hofert — 2013-05-21T12:35:57

Hi,

I have

(setq ess-history-file nil)

in ~/.emacs to avoid that .Rhistory files are written. This worked well
for me for quite some time until I updated to 13.05-1 [rev. 5586
(2013-05-17)]. Since then it shows .Rhistory and not nil (maybe this is
due to
https://github.com/emacs-ess/ESS/commit/710f4e462f0ede6e9f09ae9bd46f83ebaa3cfb77
?).

The question is, how can I get 'nil', so really no .Rhistory being
written?

Thanks & cheers,

Marius

______________________________________________
ESS-help< at >r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: ess-boolean-command incorrectly assumes case-fold-searchis 't'

Vitalie Spinu — 2013-05-20T16:20:06

Hi Michael, 

Yeh, an oversight. Thanks for the report and figuring it out.

    Vitalie

PS: BTW *ess-command-output* is there but it starts with space. This is a
hidden buffer. 


 >> Michael Lawrence <lawrence.michael< at >gene.com>
 >> on Mon, 20 May 2013 09:03:35 -0700 wrote:

 > Sorry to keep pestering you guys, but I really wanted to try the
 > (relatively) new developer mode. Got this error message:

 > ess-toggle-developer: Could not source ess-developer.R. Please investigate
 > the output of *ess-command-output* buffer for errors

 > There was no ess-command-output buffer, because the source actually
 > succeeded. Instead, the culprit appears to be ess-boolean-command, which
 > tries to match TRUE/true in a case-insensitive fashion. However, it calls
 > (re-search-forward "true" nil t), and the case-sensitivity of
 > re-search-forward depends on case-fold-search being 't'. This then fails
 > when case-fold-search is 'nil', for R at least.

 > Hope that helps,
 > Michael

 > [[alternative HTML version

ess-boolean-command incorrectly assumes case-fold-search is't'

Michael Lawrence — 2013-05-20T16:03:35

Sorry to keep pestering you guys, but I really wanted to try the
(relatively) new developer mode. Got this error message:

ess-toggle-developer: Could not source ess-developer.R. Please investigate
the output of *ess-command-output* buffer for errors

There was no ess-command-output buffer, because the source actually
succeeded. Instead, the culprit appears to be ess-boolean-command, which
tries to match TRUE/true in a case-insensitive fashion. However, it calls
(re-search-forward "true" nil t), and the case-sensitivity of
re-search-forward depends on case-fold-search being 't'. This then fails
when case-fold-search is 'nil', for R at least.

Hope that helps,
Michael

[[alternative HTML version deleted]]

______________________________________________
ESS-help< at >r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

suggestion for R: indicating symbol scope / existence

Michael Lawrence — 2013-05-20T13:12:38

This might be a lot of work, but it would be cool. Not completely though
out yet. I'll volunteer to help out, on the R side at least. The codetools
package should help a lot.

Via font-locking or similar, indicate the scope of every symbol in the
buffer. This would distinguish symbols found in the:
* Current scope (e.g., function)
* Package imports (in developer mode) -- and which package by tooltip?
* Base namespace (in developer mode)
* Search path (when buffer has a session) -- and which element?

The goal here would be to make it more obvious when the wrong symbol is in
scope, or if a symbol is unbound. Would be cool if this updated
continuously, in a separate thread or something, but for now cold updating
by key-press would work.

A simpler first shot might be to implement this for the session buffer:
does what I'm typing exist? Is it in my workspace, or a package?

Michael

[[alternative HTML version deleted]]

______________________________________________
ESS-help< at >r-project.org mailing list
https://

Re: suggestion: eldoc support for S4 methods

Kasper Daniel Hansen — 2013-05-18T18:47:45

On Sat, May 18, 2013 at 9:57 AM, Michael Lawrence <lawrence.michael< at >gene.com



I will second Michael's usage request here. How S4 is used is quite
different from project to project, but Bioconductor is certainly a big
group and we have may cross-packages generics which - as Michael says -
tend to heavily use that a specific method may have different arguments.

In fact I dare say that our experience - based on quite a lot of time and
testing - is that one should only define arguments in the generic if they
are being dispatched upon.

Best,
Kasper





[[alternative HTML version deleted]]

______________________________________________
ESS-help< at >r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: suggestion: eldoc support for S4 methods

Michael Lawrence — 2013-05-18T13:57:26

Ok, well, in Bioconductor, we tend to define our generics very generically,
with most having the signature function(x, ...) and the methods having many
arguments. This happens very often with S3 generics, as well. So I don't
really agree with Deepayan's opinion. I'm constantly frustrated by the need
to use selectMethod() or the help to see argument lists.


Yes, that's what I meant. I'll defer to you on the keybinding, because
you're more aware of the key bindings that exist.




[[alternative HTML version deleted]]

______________________________________________
ESS-help< at >r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: ess-describe-object-at-point: how to cycle?

Vitalie Spinu — 2013-05-18T13:50:13

 >> Michael Lawrence <lawrence.michael< at >gene.com>
 >> on Sat, 18 May 2013 06:38:48 -0700 wrote:

[...]

 > Thanks, I will use C-e. Strangely, when I use your method above, it says
 > press 'e' to cycle, but when I M-x ess-describe-object-at-point, it says
 > press 'm'.

The command is dynamic in a sense that it assumes that
ess-describe-object-at-point is bound to a key and you will use the last
part of that binding to cycle. For example if you bind it to C-c g the
cycling is done with g.

"m" comes from C-m (aka RET). A small glitch in the message; it doesn't
show the prefix.

    Vitalie

______________________________________________
ESS-help< at >r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: eval-line-and-step broken in org mode buffer

Michael Lawrence — 2013-05-18T13:47:05

Yes, I'm sure it's 13.05. I reloaded the buffer, and now I no longer
receive that error message. But the weird popping up to the comment line
still occurs. Interestingly, ess-eval-line-and-step-invisibly advances
correctly.

Michael


On Sat, May 18, 2013 at 6:24 AM, Vitalie Spinu <spinuvit< at >gmail.com> wrote:


[[alternative HTML version deleted]]

______________________________________________
ESS-help< at >r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: suggestion: eldoc support for S4 methods

Vitalie Spinu — 2013-05-18T13:45:03

It does work for S3 methods, all arguments sown after || are not from
generic.

ESS heavily relies on internal R completion. I asked Deepayan Sarkar
(the author of R's completion) several years ago if it would be possible
to dispatch on first argument, and he ruled it out as inefficient and
not worth it in terms of the benefits it brings.

I tend to agree with that, because S4 methods usually use the same
arguments as the generic so it's really not a big deal. I am a heavy
user of S4 and with current eldoc I almost never have a need for this
feature.

I also don't yet see a convenient user workflow. When you say "on
demand" do you mean a reserved key for eldoc invocation with evaluation
of arguments? That might be a good idea, any suggestions for a key
binding?

    Vitalie

 >> Michael Lawrence <lawrence.michael< at >gene.com>
 >> on Sat, 18 May 2013 06:19:34 -0700 wrote:

 > I really like the new eldoc that is turned on in 13.04, and it would be
 > cool to make it work on S4 methods. Right now, it accesses on

Re: ess-describe-object-at-point: how to cycle?

Michael Lawrence — 2013-05-18T13:38:48

Thanks, I will use C-e. Strangely, when I use your method above, it says
press 'e' to cycle, but when I M-x ess-describe-object-at-point, it says
press 'm'.




[[alternative HTML version deleted]]

______________________________________________
ESS-help< at >r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: ess-describe-object-at-point: how to cycle?

Vitalie Spinu — 2013-05-18T13:31:02

It is C-e. That is C-c C-d C-e C-e C-e C-e ... 

e should also have worked, but it doesn't and I forgot to fix this
before the release. But it might actually be a good thing because of
smaller chance of interfering with editing. I will correct the docs and
message.

 >> Michael Lawrence <lawrence.michael< at >gene.com>
 >> on Sat, 18 May 2013 06:07:58 -0700 wrote:

 > Hi guys,
 > When I issue ess-describe-object-at-point, it brings up the electric
 > buffer, as expected, and instructs to type 'm' to cycle. 

Hm, that should not be. May be it's some system specific glitch. I see
"Press e to cycle". Have you rebound ess-describe-object-at-point to
some other key?

    Vitalie

______________________________________________
ESS-help< at >r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help

Re: eval-line-and-step broken in org mode buffer

Vitalie Spinu — 2013-05-18T13:24:45

Works fine for me. 

Are you sure you are loading 13.05? I think the stringp error has to do
with unavailability of dialect association with the buffer and that was
fixed half an year ago, or even more.

    Vitalie


 >> Michael Lawrence <lawrence.michael< at >gene.com>
 >> on Sat, 18 May 2013 05:17:33 -0700 wrote:

 > Hi,

 > If I have an org-mode buffer with these contents:

 > # Skips to here


 > #+begin_src R
 > library(tools) # eval-line-and-step issued here
 > library(MASS)
 > #+end_src


 > And I issue eval-line-and-step at the library(tools) line, ESS (13.05 at
 > least) will "skip" up to the first commented line ABOVE the current line,
 > instead of just going down to the next line.

 > This error is emitted in the mini-buffer: Wrong type argument: stringp, nil.

 > Thanks,
 > Michael

 > [[alternative HTML version deleted]]

 > ______________________________________________
 > ESS-help< at >r-project.org mailing list
 > https://stat.ethz.ch/mailman/listinfo/ess-help

_____________________________________

suggestion: eldoc support for S4 methods

Michael Lawrence — 2013-05-18T13:19:34

I really like the new eldoc that is turned on in 13.04, and it would be
cool to make it work on S4 methods. Right now, it accesses only the
generic, which is often insufficient, because S4 methods will add arguments
as allowed by the presence of "..." in the generic formals.

Having no idea of how this works inside ESS, I thought that if you could
somehow get the text of the call, you could use selectMethod() to find the
actual method. I threw together the function below just for fun. It takes a
string representation of an R call, parses it, evaluates the arguments,
matches them to elements of the generic signature, and resolves the method.
It even handles the ".local" delegation that happens when methods add
formal arguments as mentioned. The evaluation of the arguments might be
expensive, so this should be on-demand only.

parseToSelectMethod <- function(expr) {
    call <- parse(text = expr)[[1]]
    generic <- match.fun(call[[1]])
    matched.call <- match.call(generic, call)
    args <- lapply(as.list(m