-
Notifications
You must be signed in to change notification settings - Fork 129
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
Hidden cells with hide_input argument #65
Comments
This is a duplicate of #15, see also #17. This could be implemented in Apparently, the It looks like this is supported with a Notebook extension: https://github.com/ipython-contrib/jupyter_contrib_nbextensions/tree/master/src/jupyter_contrib_nbextensions/nbextensions/hide_input. Should there be a possibility to toggle the visibility of the input cell in HTML output or should it be completely inaccessible? I'm reluctant to implement this before it's implemented in the Notebook itself and in |
Btw, per comments at the Fall 2016 dev meeting we added a Is there an equivalent of the distinction between Also, tags are supposed to be included in a list of strings in under the
so |
@michaelpacer Can you please point me to the documentation of the "tag" feature and the available official tags? I'm not sure if a tag with a binary value (on/off) is the most meaningful way to describe the hiding mechanism, since this involves multiple mutually exclusive states.
Not yet. Currently, One reason for not having it toggleable in HTML was that nobody made a PR with the HTML/CSS code. Remember: "Explicit is better than implicit". If the code needs to be hidden, I think Jupyter Dashboards might be a better solution, right?
Sure. When I introduced it, the concept of tags didn't exist yet. And as I alluded to above, binary "tags" or "flags" might not be the best tool anyway. Anyway, whatever gets implemented in the Notebook and in |
I don't think this was a good idea. Are those things already fixed or is there still a chance for a saner and more user-friendly solution? |
Sorry for not responding sooner, I only just saw it today. As you can see, I have plenty of answers :).
http://nbformat.readthedocs.io/en/latest/format_description.html#cell-metadata There were some metadata values that were being assigned automatically for some time, but I do not believe there are any official tags more official than what I've been doing. @minrk is there anywhere that lists that?
@mgeier This is probably the "most" active issue right now…but I haven't gotten many responses: jupyter/nbconvert#445 Here's where the work-to-date lives: https://github.com/michaelpacer/hiding_tags_nbconvert but no one's talked to me on that at all. TBH, I've been waiting on hearing (on the nbconvert issue) how other people were imagining this being implemented beyond what I've done & how they'd like it to be implemented for Jupyter. I agree that the However, I agree this should be a broader conversation. @fperez, is there a better location to have this discussion than on the nbconvert issue? It seems like this would be a bigger issue than just nbconvert, but I'm not sure where that discussion should happen?
Yes and no. First, tags like this aren't only binary, they're purely additive. In contrast Additive features work from the assumption of a null space, and so we may be able to use heuristics about how the "null" case works which allows us to avoid making explicit decisions about the full For example, this allows applying a fairly straightforward hierarchy simply by instituting a sequence of Additionally, additive features are good data structures for a tagging like interface for applying metadata to cells without needing to jump into the metadata editing view. This has a number of UI consequences, some of which include an easy "click"-able interface and tag suggestions. To illustrate, designing a tag suggestion system based on substitutive features would require deciding whether to make suggestions on the basis of the number of times a tag is invoked (regardless of it's value) in addition to deciding whether to suggest a value as well.
NB: Technically there could be a case in which you separately wish to toggle the output and input which would make the
That's one of the beauties of additive features! You don't toggle their state, they all default to "not present", because that's the null state(i.e., you never really have a feature that is "off"). From a data structure point of view this is doubly simpler because if you have only substitutive features you will have to make sure that they are always defined, with a default value, clogging up the metadata. Note, that if you had a substitutive feature that you did not include, you actually have now created a tiered feature space, one in which there are binary additive features (present/not present) and one that assigns the values to those features. In this conceptual scheme: the notion of a tag that defaults to "on" would be a little odd. Such a feature (which should be selectively turned off by manual decisions) is effectively just a feature that is integrated into the notebook and nbconvert machinery directly. Then there would be a tag to turn "off" this behaviour. In fact, you could see the There are plenty of examples that are harder to fit within this scheme, but those can be dealt with using full metadata attributes rather than tags. This isn't reducing expressivity of the entire system, it's just tailoring the expressive capacity of this one data structure to be useful in the particular cases in which we want to use it.
Fair enough!
Yes, that's why in my repo I only have a
I couldn't disagree more, but not because I think it is necessarily a good idea in the first place, but rather that I cannot evaluate whether it is a good idea for all of the cases in which people would want to use it. There are tonnes of people who have been requesting this feature for an extremely long time. I'm not one to suggest that every one of them was making the right call, but I'm also not one to suggest that everyone one of them was making the wrong call. I'm confident that at least one person could write better documentation for their software using toggleable cells/inputs/outputs than they could without. Even so, I can think of plenty of reasons in pedagogical contexts that have nothing to do with software documentation where encapsulation and abstraction may not make sense as conceptual primitives around which to organise material. In those cases, having this in |
Thanks for the detailed response, that's really interesting stuff! Regarding http://nbformat.readthedocs.io/en/latest/format_description.html#cell-metadata: What about the
I think (part of) the problem is that you are approaching this from the
This would be even worse than
Yes, that sounds reasonable for a tagging system.
I wouldn't see it this way. E.g. in
You are right, my statement was too general.
I'm aware of this. I've gotten those requests myself. I think most of the times, they would be better off not hiding their code.
That's indeed quite likely. But I haven't seen such a case yet. I'm looking forward to seeing one! Anyway, I'm not saying that such a feature should never be implemented, I just wanted to tell you why I haven't implemented it. |
Quick comments on my phone, sorry for non quotes, any comments appearing out-of-order and a lack of formatting. This doesn't need an enhancement proposal it's already in nbformat and on the development path. One of the mandates in the jupyter grant is to make hiding elements in outputs based on tags happen. I have developed my thoughts on this not only from the perspective of nbconvert but in collaboration with @Carreau and @fperez. My words are just my attempt at crystallizing this line of reasoning. Collapsed is a metadata attribute, at the same level as tags. The additive format of tags was designed with the UI question specifically in mind. In particular, it was partially designed with tasks such as quickly marking cells to be hidden on output as one use case (or so I have surmised). All having the default value as you do does is map the 3 value (2 feature) state system back to a 2 value system. You could make the presence of the default argument have a different value altogether. Look at the implementation of alt text for HTML image tags for an example of a useful version of such a system (no alt tag is different from alt=""). Applying the hide_cell tag does not hide it from view in the notebook, only in the converted document, thus there is no conflict with it being hidden or not. This is why it is appropriate to discuss this from the perspective of nbconvert. Collapsible or hideable live input areas are another feature idea but to the best of my knowledge there is no effort currently being pursued to implement that. If that were the case I imagine there would be discussion about whether there should be a separate UI for that. You would either have allow errors or disallow errors be the default. You could have the exact same syntax for setting it but change the mechanism to put nothing there if it's false and something there if it's true. But you're also creating that as an intermediate metadata representation for your computations. This means that even if it does become cluttered that's less of an issue than it is for a file format's metadata. All the tags need to appear as strings in a flat list in the current nbformat so there is no way to have sets of tags. You can have other metadata attributes that have other kinds of structure but they would not be tags as described in the format. That's fine! You could have just not implemented it because you also have higher priority tasks. So knowing why you chose not to do so is helpful. I greatly appreciate you taking the time to explain your reasoning. It has helped me think about this problem! |
Thanks for the additional info, that's really enlightening!
I wasn't aware of that! This is good and bad news to me: With all this cleared up, there is one question left: I don't like the idea of a prefix anyway (as mentioned above), but doesn't the prefix |
subscribing... |
For the record I am in favor of the |
Just to quickly weigh in: I agree with @ellisonbg about the project wide namespace with project specific semantics (i.e., even if eventually there is a way to hide an input cell in the notebook itself, that should different from I believe the goal is to have a dedicated UI for assigning tags in the notebook (if not in the classic notebook, at least in jupyter-lab). It's just that the meaning of |
Agreed that a prefix is needed. Neutral for |
As user I'd like to show the output, not hide the input (it is not the same thing). It would be nice to show some variables calculated in one or more hidden cells at the top of the notebook in a markdown cell. This is already possible in the jupyter notebook thanks to this extension python-markdown. PROs: no "orphan" cell with only the output, easy to implement (I guess) since no modifications are required upstream in the notebook code, all handled within |
Hi @gpagliuca I think that we are using slightly different meanings of "output". When we are saying "hide_output" for a cell, what we're referring to is not the python state due to the cell, but rather the output prompt area that is displayed below the input prompt area. What it sounds like you want is the ability to reference objects in the python namespace within markdown cells and have their
If you want this in nbsphinx output, I think it should work today as long as you have the configuration change required available to the Exporter: c = get_config()
c.Exporter.preprocessors = ['pre_pymarkdown.PyMarkdownPreprocessor'] I'm surprised it poses a problem with LaTeX exporting though, because it's acting as a preprocessor which should change the notebook before jinja touches anything, meaning that the curly braces in the edit: Ah — it doesn't have a problem with conversion to LaTeX, it has a problem with its activation within a LaTeX maths environment as indicated via |
@jgosmann The metadata keys that you linked to indicate the current state of the in-browser visualisation of the notebook. These fields are not to be interpreted to mean hidden for export and will not be supported in nbconvert for that purpose. We are working on other ways to remove/hide elements from notebooks see jupyter/nbconvert#640 and jupyter/nbconvert#643 for an example of how to do this based on tags. |
Hello,
Jupyter notebooks do have the ability to hide a cell with
"hide_input": true
metadata. I think, this should be handled by nbsphinx in the same way as"nbsphinx": "hidden"
.My suggestion:
Extend
with
Bye, Jonathan
The text was updated successfully, but these errors were encountered: