Handle inspection on cursor movement #5906
Conversation
|
There's a lot of duplication in this PR but I wanted to put this out there to make sure I'm on the right track first before working on consolidating. |
|
A test failed in |
There was a problem hiding this comment.
Thanks @ntdef! This approach is sensible, though I agree there is a fair amount of duplication.
What do you think about adding the ability for the ActivityMonitor to connect to more than one signal, with a single activityStopped emitter? In that case we could just connect both signals to the same monitor. I';m unsure whether it's a good idea, just musing...
| timeout: 1000 | ||
| }); | ||
| this._valueMonitor.activityStopped.connect( | ||
| this.onEditorChange, | ||
| this | ||
| ); | ||
| } |
There was a problem hiding this comment.
It is possible to select a new cell/editor without changing the value or cursor position, in which case the inspector won't update. I think we should call onEditorChange() here as well to catch that case.
There was a problem hiding this comment.
Gotchu. Would that not trigger a editor.model.selections.changed? Is there another event that I should use?
There was a problem hiding this comment.
If the selection of the new cell doesn't move the cursor, it won't trigger a change signal (I was able to verify by clicking on the same cursor position in a cell repeatedly). But you needn't listen to another event for that, we can just to call the onEditorChange() function in this setter directly.
|
Also cc @saulshanabrook who has been doing some thinking about signal composition. |
Yeah, I agree, I think that would be tidy way to handle signals. |
Happy to keep this as is, however, and revisit it when we start implementing some of these signal-composing ideas down the line. |
|
Ok, this last commit should handle a cell change. |
|
Looks good to me, thanks @ntdef! |
lock
bot
added
the
status:resolved-locked
Resolves #5899