Double-click on Markdown cell to edit

[raulrpearson]

Right now, it takes two clicks to enter insert mode for a Markdown cell:

markdown-edit-requires-two-clicks.mp4

I agree that a single click should not achieve this, but think it'd be great if we made this accessible with double-click.

[jonatanklosko]

We did that in the past, but we removed in #1937:

Currently double-click on rendered Markdown cells enters insert mode. A common use case for double-click is to copy content, hence users enter insert mode unexpectedly. We decided to drop the current behaviour for now, especially since we already have multiple ways to enter insert mode (i, Enter and the edit icon).

Note i and Enter are both convenient ways to do it :)

[josevalim]

Should we have cmd+click or something to edit the cell?

[jonatanklosko]

I don't have anything against that, the only issue is discoverability.

[raulrpearson]

arguable, because usually there is also a triple click that highlights the whole paragraph

True, you're right, I had conveniently forgotten about that 😆

cmd+click or something to edit the cell?

Like Jonatan, I also don't feel "hell, yeah" about it.

Maybe revealing cell actions on hover without requiring cell focus could be a bigger win overall? We'd have 1-click access to all the other cell actions as well, avoiding the first click to focus, then click to accomplish what you wanted.

It might also feel more consistent, as right now, some bits of UI reveal on hover, while these cell actions require focus, what do you think:

reveals-on-hover.mp4

Is there a reason why these don't reveal on hover currently?

[jonatanklosko]

We intentionally avoid showing the icons on hover to avoid noise when the user just moves the cursor around or scrolls. These cell actions are very much secondary, the only one we show on hover is "Evaluate" on code cells, because that's inherently the most important action, even when just reading the notebook. The insert buttons we show on hover, because they are not tied to any cell.

[raulrpearson]

Visual noise

I think having these accessible should take precedence over avoiding the (small?) extra visual noise. Personally, I'd very happily make that bargain. Maybe visual noise can be solved in a way that doesn't sacrifice access to these actions, which I feel are not that uncommon. Maybe a read vs edit mode, maybe as part of the notebook display options modal? (although, yes, I get it's best to avoid option over-proliferation).

noise when the user just moves the cursor around or scrolls

It's also usually the case that I'm on a screen wide enough for me to keep the mouse at if I want to avoid hover reveals while scrolling. This, I've noticed, I already do to avoid my scroll being captured by long overflowed cell results when the mouse ends up on top of them.

Consistency

I didn't think of including in the previous short video, but section blocks do reveal these actions on hover, for example; revealing these for other block types would align with the consistency argument:

---

Ultimately up to you, I don't think I have any more arguments to make.

In summary, my position would be that it'd be best to reveal on hover. Second best could be to test how cmd+click feels, like Jose suggested. Lastly, maybe there's good enough reasons against these options and we just accept the small two-click friction unless we come up with some better solution.

Thanks for taking the time to engage with my suggestions 🙏🏻