[ESS] ess-tracebug behavior [probably wishlist]

[Vitalie Spinu]

 >> Ross Boylan <ross at biostat.ucsf.edu>
 >> on Sat, 4 May 2013 11:50:25 -0700 wrote:

 > On Saturday, May 04, 2013 03:28:13 AM Vitalie Spinu wrote:
 >> >> Ross Boylan <ross at biostat.ucsf.edu>
 >> 
 >> >> on Fri, 03 May 2013 18:38:02 -0700 wrote:
 >> [...]
 >> 
 >> > I am now using the latest git:
 >> > 650a142597a3be857407e180381acf617f333676.
 >> 
 >> There have been some (not yet documented) breaking changes in tracebug's
 >> user interface.
 > Any I might want to know about, other than the undebug you mentioned
 >> below?

No electric debug keys anymore only M-N.
 
 >> 
 >> > C-c C-t d to debug a function.  It was exported from a package, and did
 >> > appear on the autocompletion list.
 >> > 
 >> > I did enter the debugger when I hit it, though no special code display. 
 >> > The status area of emacs listed a bunch of keys like (M)-N for next.  I
 >> > hit Esc-n and got an error"M-n is undefined".   If I enter the R window
 >> > I can debug in the usual R way.  Apparently Esc-N (uppercase) works;
 >> > having to hit the shift key for a basic debugging operation is awkward.
 >> 
 >> Why Esc? M-S-n should work and is pretty convenient.
 > To get M-something I use the Esc key; my understanding is that M=Esc for my 
 > environments (WIndows andLinux, though the stuff I've been reporting here is 
 > all Windows).  Maybe alt or the windows key would be alternates, with alt 
 > allowing simultaneous keypresses (Esc must be hit and released before the 
 > others, or at least that's how I do it).

M is Alt on Windows and linux. 

 > I don't find hitting 3 keys convenient.  It may be all the obvious single keys 
 > are taken.  Perhaps you could do something like ediff, that basically puts you 
 > in a separate control window where the keys have special meanings.  That 
 > interface has always struck me as being a little odd, but it does solve the 
 > key shortage problem.

That was before with electric keys, and it was annoying because it was
interfering with the editing process. As I said, if you don't like the
key Alt-Shift-n, you can reconfigure the ess-debug-minor-mode-map to
whatever keys you want.

[...]

 >> 
 >> The worst case happens when you debug a package level function. If you
 >> call it directly the package version is invoked, but when this function
 >> is called by another function from the same package, then the namespace
 >> version is invoked.
 > It's hard to see how that could cause a  problem since I tried typing 
 > debugonce and debug within the browser while debugging the outer function.  
 > Shouldn't that get the same function as the code will call if you then step 
 > into its invocation?

Unfortunately the visibility of the ESS completions for debug is
dynamic, in the sense that the function names are searched through the
call stack.  The function that is called is the function in the
enclosure of the function that calls it. This is lexical scoping.

It was an oversight and the current behavior is definitely not what is
usually wanted when working with a package. Searching for completions in
lexical scope is a right way to go about it. I will change this
tomorrow.

 > OTOH, it's possible it did work in those scenarios & I just got confused.  I 
 > may have scanned the stack trace too quickly; one of the problems when they're 
 > huge is that they are hard to follow.
 >> 
 >> I might be able to handle these issues transparently for the user. Will
 >> look into it. For time being you have to keep track of it yourself.
 > Since I'm not sure I understand, that will be difficult :)  It would be great if 
 > this complexity could be concealed.

 > Let P be the package version of the function and N the namespace version and F 
 > be the unadorned function name.  I think you are saying that for an exported 
 > function when you are at the global environment F=P.  But if you're inside the 
 > namespace, e.g., running P, then F=N. If you debug P and are in a browser 
 > while doing that debugging, typing debug(F) gets N.  Finally, interactively 
 > setting debugging with the ess-developer tools is effectively in the same 
 > environment as your R session, so C-c C-t d F debugs P if you are at outer 
 > scope, but N if you are in the debugging browser for P.

That is indeed how it should be, but it doesn't work this way because of
the above lexical scoping issue. Once that is solved it all comes to
debug(F) doing debug(N) and on that we have to rely on R.

 > And if you do C-c C-t a <pkg>  where <pkg> defines F and the C-c C-l, you end 
 > up debugging... I'm not sure.

If you flag pkg::F then you end up debugging N, if just F you will debug P. 


    Vitalie