Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interaction between keyboard navigation and collapsed cells #3233

Closed
akhmerov opened this issue Nov 12, 2017 · 10 comments · Fixed by #6356
Closed

Interaction between keyboard navigation and collapsed cells #3233

akhmerov opened this issue Nov 12, 2017 · 10 comments · Fixed by #6356

Comments

@akhmerov
Copy link
Member

jupyterlab: v0.29.1

To reproduce:

  1. Create two cells with some input. Switch to edit mode, and verify that pressing downarrow moves the cursor from one cell to another and moves the current cell indicator on the left margin.
  2. Collapse the lower cell, try to navigate from the uncollapsed cell to the collapsed one using downarrow. Observe that the current cell indicator moves to the collapsed cell, but the cursor stays in the uncollapsed cell. Observe that further arrow navigation and further edits modify the first cell, and not the collapsed one.

I'm unsure what the correct behavior should be here, but the current behavior seems inconsistent.

@blink1073 blink1073 added this to the 1.0 milestone Nov 20, 2017
@jasongrout jasongrout removed this from the 1.0 milestone Sep 5, 2018
@jasongrout
Copy link
Contributor

I reproduced this with 0.34.

@jasongrout jasongrout added this to the 1.0 milestone Sep 10, 2018
@tgeorgeux
Copy link
Contributor

@jasongrout I had a chance to play around with this a bit. I wanted to flag a couple of things:

  • If you have multiple cells collapsed in a row, the cursor will stay in the last uncollapsed cell, but the blue 'cell selected' indicator cycles through collapsed cells.
  • Indicator and cursor both advance past a 'group' of collapsed cells.

I think we can go with one of two options.

  1. Collapsed cells are ignored when navigating with arrow keys.
  2. Collapsed cells can be focussed when navigating with arrow keys, but cell input is disabled until an expanded cell is focussed. I don't like this option as much unless we have a keyboard shortcut to expand/collapse cells (which to my knowledge we don't).

For simplicity's sake I suggest option 1 for now.

@vidartf
Copy link
Member

vidartf commented Sep 13, 2018

My 2 cents: Option 2, but where a focused, collapsed cell is expanded by hitting space/enter (maybe space keeps you in command mode and enter puts you in edit mode?).

@jasongrout
Copy link
Contributor

I like option 1. If you have a lot of collapsed cells in a row, but no way to execute them, I think just skipping them may be a better ux (i.e., option 1) (so shift-enter also just skips them, etc.).

@jasongrout
Copy link
Contributor

On the other hand, if I select a bunch of cells including collapsed cells, and then execute selected cells, should those collapsed cells be executed?

@tgeorgeux
Copy link
Contributor

I know we're looking at the concept of 'hiding' versus 'collapsing' with regard to cells. This context comes up from the new new controls associated with the ToC extension.

I think #1 has the least implications for future design decisions.

@tgeorgeux
Copy link
Contributor

I think we should move forward with skipping collapsed cells when scrolling with the keyboard for now. We can always address this further if that's causing trouble.

@saulshanabrook
Copy link
Member

I will have a go at this. My understanding is that if I am in this state here:

Screen Shot 2019-05-15 at 12 58 08 PM

And I press the down arrow, it should focus on cell [6] with the content B and when I type after hitting down, it should end up in that cell. Is that right?

@akhmerov
Copy link
Member Author

Either that, or nothing happens, or cell expands—not sure what's the best here.

@lock
Copy link

lock bot commented Aug 6, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related discussion.

@lock lock bot locked as resolved and limited conversation to collaborators Aug 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants