Take a look at watch-expressions.png. Watched expression should be updated on every call. Similar behavior can be achieved in Chrome DevTools using a conditional breakpoint with console.log statement. http://www.randomthink.net/blog/2012/11/breakpoint-actions-in-javascript/. It is cumbersome and hard to discover. Evaluated expression block should appear inline but shouldn’t be editable; the same way it’s done in Light Table IDE (http://www.lighttable.com/). What do you think?
Created attachment 219539 [details] Mockup
Putting more data into the text editor like this is something we have talked about internally (DFG JIT types for variables, heat map for profiles, etc.) While inline expressions would solve the problem when the expression is visible, often I think people use watch expressions for things not used in the code. Figuring out what and why people use the Chrome watch expressions pane for might give us clues to better UXs. I don't really like the old watch expressions pane as-is. One thing I know people use it for is tracking important variables as they step in one place — which is a horrible UI. You might have only a few expressions that apply to the current stack, and the others are exceptions. A better UI for watching important variables is a way to flag scope chain variables or variable paths (nested in objects) and promote/bubble them up to the top or color them or something special. That way they are scope specific and wouldn't clutter a global expression list. Joe and Antoine apparently talked about a grander idea for watch expressions at some point, maybe they can post their ideas too. I'd be interested in going forward with the inline approach in the mock-up. As far as the current mock-up goes, would there be any other UI for managing the expressions? How do you remove one? How would object values work? A popover on the bubble? The less UI the better.
Note: we have breakpoint actions now too, that is less of a hack like using breakpoint conditions.
Some more thoughts about the inline UI: * The bubble might be better understood if it had a "<" arrow (but not a "greater than") inside it pointing to the expression. This might help more if there are multiple ones on the same line. Maybe a "=" even if it looks too much like a greater than symbol? * Hovering the bubble should highlight the expression. * We might want a toggle button in the navigation bar of the content view to show/hide these bubbles.
Many people constantly add/remove console.log statements in the code for debugging. Watch expressions can replace this. (In reply to comment #2) > Putting more data into the text editor like this is something we have talked about internally (DFG JIT types for variables, heat map for profiles, etc.) Sounds exiting! > While inline expressions would solve the problem when the expression is visible, often I think people use watch expressions for things not used in the code. Figuring out what and why people use the Chrome watch expressions pane for might give us clues to better UXs. I don't really like the old watch expressions pane as-is. Chrome watch expressions only work well in a tandem with breakpoints, e.g. they get updated when debugger stops. They won’t be any use for my example on the mockup. I don’t have any data on my hands, but in my experience, most people use exclusively console over watch expressions.
(In reply to comment #2) > As far as the current mock-up goes, would there be any other UI for managing the expressions? I imagine a panel similar to the breakpoints one that can be used to disable and jump to the watch expression. > How do you remove one? By using delete key. Evaluated values cannot be edited, but the whole thing itself should be removable. > How would object values work? A popover on the bubble? The less UI the better. I like how Light Table shows them inline: http://screencast.com/t/sEEsWgP65 Popovers cover code behind them. Having more than one expanded popover can be troublesome.
(In reply to comment #4) > Some more thoughts about the inline UI: > > * The bubble might be better understood if it had a "<" arrow (but not a "greater than") inside it pointing to the expression. This might help more if there are multiple ones on the same line. Maybe a "=" even if it looks too much like a greater than symbol? "<" looking icon might be a good idea. > * Hovering the bubble should highlight the expression. > * We might want a toggle button in the navigation bar of the content view to show/hide these bubbles. I agree on both.
In the screencast above, Light Table evaluates selected text on Cmd+Enter and selected line when there is no text selected.
(In reply to comment #5) > Many people constantly add/remove console.log statements in the code for debugging. Watch expressions can replace this. > > (In reply to comment #2) > > Putting more data into the text editor like this is something we have talked about internally (DFG JIT types for variables, heat map for profiles, etc.) > > Sounds exiting! > > > While inline expressions would solve the problem when the expression is visible, often I think people use watch expressions for things not used in the code. Figuring out what and why people use the Chrome watch expressions pane for might give us clues to better UXs. I don't really like the old watch expressions pane as-is. > > Chrome watch expressions only work well in a tandem with breakpoints, e.g. they get updated when debugger stops. They won’t be any use for my example on the mockup. > > I don’t have any data on my hands, but in my experience, most people use exclusively console over watch expressions. Doing watch expressions when not paused in scope would likely fail for most expressions. Are you proposing them to always be evaluated? At what interval? What about non-globl expressions? (I have not used Light Table yet.)
(In reply to comment #8) > In the screencast above, Light Table evaluates selected text on Cmd+Enter and selected line when there is no text selected. We currently show a popover when hovering a selection, that matches the expressions popover we show when hovering properties/variables.
(In reply to comment #6) > (In reply to comment #2) > > As far as the current mock-up goes, would there be any other UI for managing the expressions? > > I imagine a panel similar to the breakpoints one that can be used to disable and jump to the watch expression. Yes, it could be a section in the Debugger sidebar. We plan to add a Probes section soon based on the work in the Timelapse project. In a way watch expressions are like probes, and IIRC, probes work without pausing by recording values during normal execution and auto continuing. Maybe the inline treatment you propose should just be used for probes to see the last value? > > How do you remove one? > > By using delete key. Evaluated values cannot be edited, but the whole thing itself should be removable. Sounds good. If the inline bubbles are tied to probes, they will ale have a breakpoint like icon in the gutter. > > How would object values work? A popover on the bubble? The less UI the better. > > I like how Light Table shows them inline: http://screencast.com/t/sEEsWgP65 > Popovers cover code behind them. Having more than one expanded popover can be troublesome. Inline expansion is pretty disruptive too. It requires you to expand and collapse when you are done to get the space back. Popovers are transient and hide automatically when attention (the mouse) moves away. Inline expansion with multiple objects on the same line quickly becomes a chaos, as you can get in the console. I'ver been considering removing inline expansion in the console because of that (at least for multiple objects on one line) and using a popover.
(In reply to comment #11) > (In reply to comment #6) > > (In reply to comment #2) > > > As far as the current mock-up goes, would there be any other UI for managing the expressions? > > > > > How would object values work? A popover on the bubble? The less UI the better. > > > > I like how Light Table shows them inline: http://screencast.com/t/sEEsWgP65 > > Popovers cover code behind them. Having more than one expanded popover can be troublesome. > > Inline expansion is pretty disruptive too. It requires you to expand and collapse when you are done to get the space back. Popovers are transient and hide automatically when attention (the mouse) moves away. Inline expansion with multiple objects on the same line quickly becomes a chaos, as you can get in the console. I'ver been considering removing inline expansion in the console because of that (at least for multiple objects on one line) and using a popover. Another option, if the bubble allows selection (like a token), we could push a selection state, making it show up in the navigation bar path. Then you can have a details sidebar that has the details of the value. This is something we might do for probes, which would show you the history of the value, not just the last value.
(In reply to comment #9) > (In reply to comment #5) > > Many people constantly add/remove console.log statements in the code for debugging. Watch expressions can replace this. > > > > (In reply to comment #2) > > > Putting more data into the text editor like this is something we have talked about internally (DFG JIT types for variables, heat map for profiles, etc.) > > > > Sounds exiting! > > > > > While inline expressions would solve the problem when the expression is visible, often I think people use watch expressions for things not used in the code. Figuring out what and why people use the Chrome watch expressions pane for might give us clues to better UXs. I don't really like the old watch expressions pane as-is. > > > > Chrome watch expressions only work well in a tandem with breakpoints, e.g. they get updated when debugger stops. They won’t be any use for my example on the mockup. > > > > I don’t have any data on my hands, but in my experience, most people use exclusively console over watch expressions. > > Doing watch expressions when not paused in scope would likely fail for most expressions. Are you proposing them to always be evaluated? At what interval? What about non-globl expressions? (I have not used Light Table yet.) No interval. Think of watch expressions as console.log statements. I guess it’s the same as probes in the Timelapse. Timelapse didn’t work for me last time I tried to compile, so I’m not entirely sure.
> No interval. Think of watch expressions as console.log statements. I guess it’s the same as probes in the Timelapse. Timelapse didn’t work for me last time I tried to compile, so I’m not entirely sure. Probes are associated with statements like breakpoints, and executed without pausing like console.log. In the prototype, probes are implemented as a type of breakpoint action. Probes are somewhat slower than console.log, because it is the moral equivalent of a breakpoint, whereas console.log is a native call from JS. Probe samples are aggregated by call site rather than interleaved according to the flow of time in the program. It would be pretty easy to show the last collected probe sample value nearby the probe's call site in the text editor.
I'm going to close this bug in favor of filing smaller, targeted bugs. I think some of the ideas in the comments and mockups could be incorporated with the existing probes UI. We have only implemented the bare minimum for probes and they could be much more useful. Feel free to file more bugs! And cc: me :)
<rdar://problem/19094965>
Brian, how do I turn on probes?