Bugs involving merging of cells

[jhamrick]

The UI involving the merging of cells is broken. There are a few related issues:

First, you can choose to "undo delete cell", but it doesn't remove the source from the first cell that was merged in. That's annoying, but not super problematic if we decide we don't want to deal with that (I think it was handled properly before? I could be misremembering, though).

Next, the resulting merged cell is still marked. I think it should be unmarked after the merge operation is complete.

Finally, there's also a more serious issue. Steps to reproduce:

1. create notebook with two cells
2. select second cell
3. multi-select with first cell (shift+k)
4. merge (shift+m)
5. undo delete cell -- this will cause the deleted cell to appear above the merged cell (it should be below)
6. select the top cell (the one that should have been below) and delete it -- this will cause the second cell (the one that is not selected!) to be deleted. I think this is because that cell is marked, so having the merge unmark the cell it operated on would fix this.

[Carreau]

I agree that delete should act on selected cell, not marked.

We should have a separate delete marked.

[ellisonbg]

I am not sure about that. I don't see why delete is different from other
actions that do either selected or marked cells. We already make it tough
to delete by accident with the "d d" keyboard shortcut.

On Mon, Oct 26, 2015 at 2:40 PM, Matthias Bussonnier <
notifications@github.com> wrote:

I agree that delete should act on selected cell, not marked.

We should have a separate delete marked.

—
Reply to this email directly or view it on GitHub
#665 (comment).

Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

[Carreau]

Because in 4.0 d,d delete selected cell. Current behavior in 4.1 is actually different than 4.0.

[Carreau]

And/Or, we should alway have selected cell being considered as marked.

[jhamrick]

Yeah, I think the behavior should be the same (d,d deletes selected, not marked, cell) unless we somehow warn users that it is going to delete the marked cell instead. But I actually think that will lead to confusing behavior, e.g. what if nothing is marked? Then it will delete the selected cell. So users will still expect the selected cell to be deleted because that is what they are used to seeing.

[Carreau]

Seeing the issues with marked cell, I'm wondering if we should'nt have disabled/revert ed it for 4.1.

The contiguous selection was more than enough, and we push it too far.

It's a feature that will only be used efficiently only by 1% of the 1% of users using it.

[ellisonbg]

The introduction of marked cells was not to address discontinguous
selections. There were fundamental problems with the previous
implementation of cell selection that mixed cell focus with selection in a
nasty way.

We should just take our time and get the design right before shipping. But
we aren't far from that point.

Overall the cell marking is working extremely well - with only a few edge
cases we need to clean up. We have a clean way of distinguishing between
continguous and discontiguous selections and preventing actions on discont.
selections that don't make sense.

Can you clarify what the problem is?

On Mon, Oct 26, 2015 at 2:51 PM, Matthias Bussonnier <
notifications@github.com> wrote:

Seeing the issues with marked cell, I'm wondering if we should'nt have
disabled/revert ed it for 4.1.

The contiguous selection was more than enough, and we push it too far.

It's a feature that will only be used efficiently only by 1% of the 1% of
users using it.

—
Reply to this email directly or view it on GitHub
#665 (comment).

Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

[jhamrick]

For reference, here is a gif of the problems described above:

[Carreau]

We should just take our time and get the design right before shipping. But
we aren't far from that point.

Overall the cell marking is working extremely well - with only a few edge
cases we need to clean up. We have a clean way of distinguishing between
continguous and discontiguous selections and preventing actions on discont.
selections that don't make sense.

Can you clarify what the problem is?

I completely disagree with that point.

The marked cell introduce a completely new layer of abstraction that distinguish marked vs selected.

marked and selected where the same set of cells, and action where applied to this unique set.

The 2 sets are disjoined and it is completely unclear to which of this 2 sets of cells each action applies. Worse, the set to which these actions apply is state dependent.

If now I have to explain to someone what delete does, my answer need to start with: "It depends". Even worse if I look at a notebook I cannot tell what it will do.
I have to scroll through the all notebook to see wether cells are marked or not.
Example, see two gif attached. On which one will dd delete the selected cell ?

Both are on current master.

[Carreau]

Addendum:

this show that the problem is not only on merge.

• And description of above gifs: in the first one a off screen cell is selected and is deleted by DD (see scrollbar change of size)
• In the second one the selected cell is actually deleted.

[jhamrick]

Closed by #676 and #681.