[IPython-dev] Playing with cells in the notebook... and some problems.

Gabriel Becker gmbecker at ucdavis.edu
Thu Aug 8 05:17:45 EDT 2013


I happen to be familiar with this issue for reasons that dovetail with your
desired usecase (though they aren't identical). More on that near the end
of this email.

The issue you're running into is that the javascript in the IPython
notebook assumes that all cells are direct children of the container
element representing the entire notebook.

You can see the assumption here (from

* Get all cell elements in the notebook.
* @method get_cell_elements
* @return {jQuery} A selector of all cell elements
    Notebook.prototype.get_cell_elements = function () {
        return this.container.children("div.cell");

Note the use of the children() method. That is what is killing you. All of
the indexing, etc in notebook.js is based off of what is returned from

Matthias is of course correct that the cell still exists, and all the
cell-level machinery will still work (thus ccell.execute() working fine).

The issue is that NONE of the notebook-level machinery is going to work.
This means many of the things you probably think of as core behaviors of
the notebook (selecting the next cell when a cell is executed, deleting or
moving cells, running the entire notebook from start to finish, the
notebook understanding that that cell is selected, etc) will fail with
respect to that particular cell, because as far as the notebook-level js is
concerned, the cell *isn't in the notebook at all*.

I have a research-stage fork of ipython at
https://github.com/gmbecker/ipython which allows cells to be contained
within other cells. This required me to change the indexing strategy, which
is why I'm familiar with this bit of the codebase.

Nested cells would remove the need for the extra container div, because the
grouping would be happening within the cells themselves. You would
assumedly be able to just attach the css/js slide machinery to the parent
grouping cells themselves.

There was a very lengthy discussion about the concept of these nesting type
cells, their benefits and their drawbacks, and whether they should be
pursued here<http://python.6.x6.nabble.com/Some-new-cell-types-for-describing-data-analyses-in-IPy-Notebook-td5023238.html>.
The long and short (AFAIK) of it is that the IPython core team is not yet
convinced that the idea is mature enough to pursue. Furthermore, the fact
that it requires modification of a core assumption of the notebook
machinery makes such pursuit unlikely in at least the short and medium
terms, if ever.

The team is, of course, also very busy doing all sorts of other awesome
stuff as detailed on their roadmap.

Anyway, all that doesn't really help you now. Here is something that might:

If custom js/extensions are able to clobber core machinery on the IPython
object then replacing IPython.Notebook.prototype.get_cell_elements with

** Version of get_cell_elements that will see cell divs at any depth in the
HTML tree, allowing container divs, etc to be used without breaking
notebook machinery.
** You'll need to make sure the cells are getting detected in the right
order, but I think they will
    Notebook.prototype.get_cell_elements = function () {
        return this.container.*find*("div.cell");

Will get your cell noticed again. Or, if extensions get loaded after the
notebook object exists, you might have to modify the actual notebook
instead of its prototype. That is stored in IPython.notebook if I'm not

Figuring out how to get the notebook to store (in ipynb form), remember,
and restore the fact that you grouped your cells into slides is possible in
principle using the metadata facilities already in place. Because the
metadata is at the individual cell level, however, prepare for some "fun"
hackrobatics implementing the ability to track the groupings in a
non-fragile way (e.g. able to handle regrouping or inserting new slides).

If the core machinery is protected from modification by js in the
extensions somehow I think it would take a *lot* of wheel reinvention on
your part or intervention from the core devs to get the functionality you


... Someday I will write a message to this list that isn't a novel. But not

On Wed, Aug 7, 2013 at 11:53 PM, Damián Avila <damianavila at gmail.com> wrote:

>  El 08/08/13 03:26, Matthias BUSSONNIER escribió:
>  Le 8 août 2013 à 08:01, Damián Avila a écrit :
> In this way, I get the a copy of the cell but it is not executable…
>  Yes it is, Shift-Enter is just not bound to it.
> Shift-Enter is handled by IPython.notebook and is bound to execute
> selected cell
>  As notebook object does nt know of your cell, you are just sending the
> execute request to the wrong cell.
>  adding this :
>  window.ccell = cell;
>  and then ccell.execute() in JSconsole works.
>  --
> M
> _______________________________________________
> IPython-dev mailing listIPython-dev at scipy.orghttp://mail.scipy.org/mailman/listinfo/ipython-dev
> Thanks! I will test it tomorrow... going to bed now... thanks!
> One step closer to "live" reveal ;-)
> Cheers.
> Damián.
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20130808/789fb675/attachment.html>

More information about the IPython-dev mailing list