Open Petr-Hlavenka opened 4 years ago
This is a neat idea, but really hard to do in practice, afaict. We don't have any information on where the next statement is actually located, so I think the only option is to do pattern matching on the function name/argument names.
This would indeed be awesome. If we someday get https://github.com/JuliaLang/julia/issues/31162 it will be reasonably straightforward. Until then, it seems nearly impossible.
Until then, Rebugger's old-style Alt-e
is actually the best control you have for choosing which expression you descend into.
While stepping with debugger in more complex function calls that have also their parameters evaluated as a function call, one can quickly get lost or tired by actually watching the debugger pane instead of the code pane in order to determine which step will be executed next. Just so simple example:
is not pleasant to step through at all - if one is only interested in the vcat functionality. MS visual studio - as the golden standard of how debugging can be done excellently - visually highlights in such cases the tokens of the line that will be executed in the next step. So in this case, each line corresponds to single step-over action:
vcat(a[1:10], b[6:12+i])
vcat(a[1:10], b[6:12+i])
vcat(a[1:10], b[6:12+i])
vcat(a[1:10], b[6:12+i])
It is then much easier to distinguish when to use step-over, step-into without having to do the "manual" pattern recognition of the debuggers
next-expression
text in the active line in code. I think, Juno has all the information from debugger to identify the executed part of code automatically.I can see that for meta-programmed functions that might be more tricky (no actual code written, or no obvious code written for the running function), but in such case it can just give-up and highlight the whole expression. In such a case I have no objection to really look into
next-expression
with my mind prepared for a complex "pattern-recognition" and reasoning.