On Wed, May 29, 2013 at 10:58 AM, Vitalie Spinu <spinuvit@gmail.com> wrote:

>  >> "Josh O'Brien" <joshmobrien@gmail.com>
>  >> on Wed, 29 May 2013 10:26:53 -0700 wrote:
>
>  > Hello,
>  > To show what I mean, let's say I was interested in using a browser call
> to
>  > examine the contents of the dots object from within a function call.
>
>  > Running R from the Windows R gui (for example), I could just do this:
>
>  >> f <- function(...) browser()
>
> This is an artificial example which is unfortunately pops on rare
> occasions. But it is a small price to pay for proper visual debugging.
>
> In general you should put browser before a line on which you want to
> stop. ESS indeed skips first step because R stops on browser() and
> doesn't display source references at all. So that step is completely
> useless for visual debugger.
>

Where this behavior is especially annoying is when byte-compiling is
enabled -- in which case browser stepping is not supported; 'n' does the
same as 'c'. So if byte-compiling and ess-debug-skip-first-call are both
enabled, browse() stops and always just immediately continues again.
Without ess-debug-skip-first-call you can at least inspect the environment.

Peter

I have added an option ess-debug-skip-first-call that you can set to nil
> to completely inhibit this behavior. But then you will have to press M-N
> to enter into visual debugger.
>
> [...]

	[[alternative HTML version deleted]]

