If I make an array in a cell like a = [1, 2, 3]
, and then I try to select the [1, 2, 3] in the visible cell output, observable toggles the view of the array to an extended version, making it impossible to copy/paste. A click should toggle, a drag that makes a text selection should not toggle.
You can work around this behavior by typing Command-C (or equivalent) before mouseup.
Thanks for this workaround, which is better than nothing. (Somehow I didnāt notice the response until a few weeks ago, or maybe forgot about it.)
I also have another workaround, which is to either (a) make my selection by dragging from a few pixels above the output view to a few pixels below, or (b) triple-click a few pixels above the view. But if I get the position of the mouse slightly wrong, the view ends up expanding on click/mouseup.
For what itās worth, this continues to be a frequent (minor) annoyance. Pretty often I end up going and changing the cell to wrap the content in html`<code>${JSON.stringify(...)}</code>`
or the like (how fancy this needs to get depends on the output; sometimes just returning a string as output works).
IMO ācorrectā behavior would be to distinguish between clicks vs. dragged selection. I would recommend playing around with a few existing browsersā console views for an example of how interaction for these views might work. But I understand if changing this isnāt a high priority.
FWIW this has been a (small but) persistent annoyance for me too. I wonder if thereās any way to solve it in userlandā¦
Iāve rolled out a tweaked behavior that lets you select collapsed values without uncollapsing them. The behavior tries to mirror Chromeās, though you may have to hit the āø Array
UI to expand a selected object. Weāll keep refining the inspector UI!
I agree, this click/select behavior is annoying. Google Chrome has a pretty subtle and good implementation of selectable & clickable values, which Iāll see if we can adapt from their open source code.
Just wanted to say thanks, this is great!