Useful feature for demoing what errors look like

[mpacer]

Having a way to execute all cells and continuing after hitting an error can be useful for demoing what an error would look like in a presentation context. This would be a nice action to have in the notebook interface (especially once customised with a keyboard shortcut).

[takluyver]

This is another thing for which we had thought about using a cell tag.

[mpacer]

This seems like it should be more generally useful and shouldn't require having the established special semantics usually implied around cell tags. It could be implemented similarly to how we implement it in the nbconvert.preprocessor.ExecutePreprocessor, which doesn't require cell tags.

[mpacer]

Also that would seem to require either specifying a magic cell tag value (or) needing to include the mention of the tag with every invocation of the keyboard shortcut. This seems like it might have made sense when tags were thought differently than they were now (emphasising user-specific semantics and a policy of non-interference from official jupyter namespacing).

[takluyver]

In fact, the reason I think we talked about adding a tag for this is that we've already added a tag for this in #2549.

I don't understand what's wrong with a tag for this. This is precisely the kind of reason I wanted cell tags.

[mpacer]

@jasongrout @rgbkrk I thought at the last dev meeting we had decided that no tags were to exist that have special meanings. So, technically, we're in violation of that prescription due to the existence of this tag with special functionality and should talk about deprecating that feature.

Regardless, I don't see why having a way to run cells without worrying about errors regardless of tags (in analogy to the nbconvert functionality) wouldn't be in and of itself desirable? It could exist alongside the tag-based approach they're not mutually exclusive.

[takluyver]

I have nothing against that feature, but I don't see why the tag is such a problem. Again, this sort of use is what we were after when we designed the cell tagging system.

[mpacer]

@takluyver I think partially what's happened is that tags were originally proposed as an easier way to edit general metadata than having to manipulate JSON.

But the way I thought everyone (but especially @jasongrout, @ellisonbg and @rgbkrk) has been thinking of tags were as ways for users to tag stuff without any potential conflicts with Jupyter magic tags.

From that perspective the problem is that there is a magic tag value at all. I'm not strongly moved to use tags in either way, I just thought we had had consensus around this and had been assuming as much.

[takluyver]

So the reasons I wanted tags were basically all based around 'magic tags' having particular meanings. For instance, you can tag a cell with nbval-check-output to indicate that nbval should check the output. I also expected tags like nbconvert-hide-code to tell nbconvert to hide the input part of a cell.

For the most part, I think these should be prefixed with the name of the tool, but I also think it's fine for us to define some general purpose ones which different tools can use, e.g. raises-exception to mark a cell where an error is expected.

This is kind of like the environment variable namespace:

• You can use environment variables for any purpose,
• It's usually good practice to prefix variable names, e.g. PIP_DEFAULT_TIMEOUT
• Some names have a generally agreed meaning, e.g. PATH

Environment variables aren't conceptually beautiful, but they're easy to understand and you can get a lot done with them. That's what I'm after with tags.

[rgbkrk]

we had decided that no tags were to exist that have special meanings [to Jupyter frontends (including nbconvert)]

Correct!

[rgbkrk]

The main reason (for me) was that dealing with tags (an array of arbitrary strings) to influence behavior is more complex (cyclomatically) than dealing with key value pairs in objects.

[jzf2101]

Do we think this issue would be sprint-friendly?

[mpacer]

Re: sprint friendly, technically yes, but in practice probably not. It seems issues around how to use cell tags require a lot of context than can hard to communicate within a sprint.