Hide Cell

[blankjul]

Hey,

For me hiding the cell's input but not the output did not work.

nbconvert 5.5.0
nbformat 4.4.0
nbsphinx 0.4.2

Always the input AND the output was hidden. When I move the
{%- if cell.metadata.nbsphinx != 'hidden' %}
line into the {% block input -%} it works.

However, in some cases it might make sense to hide both.

Is it possible to introduce a tag like "hide_input", "hide_output" and "hide"?

Please let me know if you are not able to reproduce the hide behaviour I had.

Julian

[mgeier]

Is it possible to introduce a tag like "hide_input", "hide_output" and "hide"?

Sure, it's possible and it has been requested before, see e.g. #65.

There are even some unfinished pull requests: #86, #185.

Feel free to work on either one of them or to create a new one!

[psychemedia]

Would it make sense for any PR relating to this to use a similar tags to those used for similar effect in Jupyter Book [ hiding cells docs and removing cells docs] to allow some element of portability between publishing workflows?

The following tags are used by Jupyter Book as the basis of cell level filtering:

• to hide a markdown cell or the inputs of a code cell: { "tags": [ "hide_input" ] }
• to hide the outputs of a code cell: { "tags": [ "hide_output", ]}
• to hide the whole of a code cell: { "tags": ["hide_input", "hide_output" ] }
• to remove the inputs of a code cell: { "tags": [ "remove_input" ] }
• to remove the outputs of a code cell: { "tags": [ "remove_output", ]}
• to remove a markdown cell or an entire code cell: { "tags": ["remove_cell", ]}

Tag based filtering in nbconvert is possible [docs] using the TagRemovePreprocessor and commands of the form jupyter nbconvert my.ipynb --TagRemovePreprocessor.remove_cell_tags='{"my_removetag"}' with the following traitlets:

• remove_cell_tags: removes cells
• remove_input_tags: removes inputs
• remove_all_outputs_tag: removes all outputs
• remove_single_output_tag: removes individual outputs

[mgeier]

@psychemedia Sure, it would make sense to be consistent with existing tools.

I guess we could define options like nbsphinx_remove_cell_tags (which would have a default value of ['remove_cell']).

But probably we can manage to come up with a bit more consistent names.

I'm very much open for a PR that does "hiding" similar to Jupyter Book for HTML output (with the possibility of un-hiding by clicking on a little symbol).

This would of course not work in LaTeX, but I guess this is OK since we already have quite a few features that only work in HTML output.

I'm not a fan of the "removing" feature, but if somebody makes a convincing PR, I might merge it nevertheless.

I will not accept the "removing" feature before the "hiding" feature is working.

[psychemedia]

Re: the names, for sure they need to be consistent with nbsphinx naming conventions but I think it would be handy if there was an obvious mapping onto either the Jupyter Book or nbconvert terms too. The Jupyter Book terms cover hiding as well as removing, so it makes more sense to try to map onto those?

On the other hand, ipypublish (which builds on nbsphinx, I think?) takes a different approach and tries to define different sorts of behaviour for cells depending on metadating describing what sort of content the cell is associated with. Whilst low level control is provided using an ignore flag (meta-celllevel-schema), as well as interactive controls for hiding / revealing code cells in interactive HTML displays, there is also a range of "cell behaviours" depending on cell type metadata. For example, when rendering latex_ipypublish_main/html_ipypublish_main the following display conditions are applied:

• all cells: bypass “ignore” and “slideonly” tags
• markdown cells: include all
• code cells (input): only include if the “code” tag is present
• code cells (output): only include if the following tags are present
  • “figure” for png/svg/pdf/jpeg or html (html only)
  • “table” or “equation” for latex or html (html only)
  • “mkdown” for markdown text
  • “text” for plain text

(In passing, I note that ipypublish also has document level metadata.)

In the R world, Bookdown uses cell level controls in source documents. For example, all or nothing display (eval and include; hide-all) or finer grained control (echo (code), results (output), fig,show (charts) hide-one).

I think these different approaches all need pulling into some sort of table to clarify what each does; they all seem to offer control over similar things but offer that control in different ways:-(

[mgeier]

The Jupyter Book terms cover hiding as well as removing, so it makes more sense to try to map onto those?

According to your list above (#303 (comment)) the terms are horribly inconsistent within themselves.
But anyway, I think I wouldn't use fixed tag names, but users should be able to specify whatever tag names they want to use.
We could (but don't have to) provide a default set of tags, which can be then overridden by the user.

On the other hand, ipypublish (which builds on nbsphinx, I think?)

I think originally it had nothing to do with nbsphinx, but quite recently they seem to have taken a lot of parts from nbsphinx and adapted them for ipypublish.
AFAICT, they are not actually building on nbsphinx in the sense that they are using it as dependency (they only have it in their test dependencies).

But they seem to have some kind of the "interactive hiding" feature already implemented.
Why are you not using ipypublish instead of nbsphinx?

I don't see a reason why nbsphinx couldn't implement a strategy like ipypublish as well.
They just seem to have an "inverted" set of tags on top of a "normal" set.

I think these different approaches all need pulling into some sort of table to clarify what each does; they all seem to offer control over similar things but offer that control in different ways:-(

Yes, it is quite confusing indeed!

[choldgraf]

Hey folks - just a note that I am happy to have discussions around standardizing metadata for cell-level behavior. My reasoning for using tags was precisely to have configuration that was not strictly unique to Jupyter Book (and to leverage a cell-level metadata mechanism that was already natively supported more easily in Jupyter interfaces).

[mgeier]

I'm currently not in a hurry to decide about tag names, because I'm still waiting for a reasonable implementation for hiding cells in HTML pages (with the ability to interactively toggle visibility).

But once that happens, it would be nice to have a consistent default set of tags that can be re-used between multiple projects.

[chrisjsewell]

implementation for hiding cells in HTML pages (with the ability to interactively toggle visibility)

FYI I've implemented this in ipypublish (see here), via selective injection of this JavaScript into documents, using the html-page-context sphinx event here.

[choldgraf]

This is also possible in Jupyter Book (see here for example: https://jupyterbook.org/features/hiding.html#Hiding-page-elements-and-displaying-a-button-to-show-them)

I've also got a little sphinx extension that collapses admonitions, the javascript to do so is here:

https://github.com/choldgraf/sphinx-collapse-admonitions/blob/master/sphinx_collapse_admonitions/_static/collapse_admonitions.js

and is basically also what you'd need to make cells collapsible

[mgeier]

Thanks @chrisjsewell and @choldgraf for the pointers!

To be perfectly blunt, I like the appearance of Jupyter Book much more, but it is of course missing the prompt numbers, which might make things a bit more complicated.

Anyway, I'm not planning on implementing any of this myself, I'm looking for volunteers!

[choldgraf]

Check out this in case it's helpful:

https://github.com/choldgraf/sphinx-togglebutton

I made it to try and replicate the Jupyter Book "collapse cell" behavior in an extensible way in Sphinx. Maybe that could do the trick w/ nbsphinx?

[mgeier]

Wow, this looks promising!

It should be straightforward to generate the appropriate CSS class names in nbsphinx.

The task just got much simpler ... are there any volunteers now?

[machow]

@mgeier I'm happy to take this up. Are you thinking that it would follow a similar format to jupyterbook?

Would this work for getting the ball rolling?

• respond to metadata tags, "hide_input", "hide_output"
• alter the rst template to use the sphinx-togglebutton's classes when appropriate ("toggle", "toggle-hidden").