[IPython-dev] Just looking for feedback before PR

[Matthias BUSSONNIER]

Le 19 nov. 2012 à 01:21, Carl Smith a écrit :

>> Thus we went with markdown for cells, mainly because of how headings were
>> handled.  But as we began to use markdown, we realized that its approach to
>> headings was a bit too flexible.  We really wanted the ability for notebooks
>> to have formal structure (nested heading levels).  There are a number of
>> usage cases for this:
>> 
>> * Exporting to formats that also have nested heading levels (latex, html,
>> etc.)
>> * Enabling entire sections/subsections in a notebook to be moved, copied,
>> collapsed, etc.  That would be impossible to do with headings embedded
>> inside markdown cells that have other content.
>> * Heading cells are common enough that it is nice to be able to do them
>> without the markdown syntax.
> 

Hi Carl, 

The problem is not about extracting metadata by themself. 
It is more to manipulate notebook cell. 

The ideas is to be able to collapse everything under a cell level x to move it around. 
Which is difficult if this level is part of a MD cell that have a few things in it.
Basically you want each header section (whatever level) to always be at the top of a cell.
This would be doable without header cell, but as always it is still a subtile balance between complexity, 
support and feature. 

Hopefully time will come (hopefully before we'll  took over the world), where we'll have enough
resources to do better than that. But even if I would like to do without heading cell for now I'm fully supporting Brian. 

We've already thought of tags in md/code cell to add information. We don't believe it is the right solution, 
but don't prevent it to be implemented by other. 

My opinion is that inline metadata is really good for fast edit , but it diminish readability. 
A compromise would be a parser that read inline metadata and put them in hidden JSON metadata
and vice versa. 

I would also add that notebook format is not for html only (e.g emacs client). Markdown is readable as 
plaintext, and html in markdown start to be difficult to read. adding extra information as inline tag
would be extra noise (either from user, or from programmer to hide) whereas metadata field has just to be hidden.

We'll be really happy to be proven wrong and find a better way, but as until now Brian vision for notebook
always proven right.

So for now, I think we will keep heading cell (it does not harm). Hopefully with time, we will see what happened 
and can deprecate the header cell if we feel the need to do so , of we if find they are not necessary.

Thanks for your reflexion on it and the time you take to post your suggestion and your answer.
This help us to know what feature of the notebook are known and not known to better target what need to be done.
-- 
Matthias
  




> Hi Brian
> 
> Thanks for taking the time to explain this for me. So, the choice to
> use header cells over hidden markup, is just considered more
> convenient? If that's the case, to be honest, I'd still prefer to
> define every element in my notebooks using plain text, even if it
> meant just using some kind of pig XML.
> 
> We could easily define some unused, HTML element names as meaningful,
> then use them in Markdown cells, safe in the knowledge that the
> browser will just ignore them. There's no reason not to use a tag like
> <spam> in a Markdown cell for example.
> 
> The hidden tags could provide meta for converters or extensions or
> whatever else. These tags could have almost anything in them; you can
> get away with murder if it's between angle brackets. Stuff like <ipy
> cmd arg0 arg1> would work fine.
> 
> The tags used by HTML or core IPython features would be reserved, but
> users could use the rest of the namespace arbitrarily, so a converter
> might define a tag named <blogger>. You could also reserve all names
> that start with special strings like ipynb, so you could later define
> tags that do stuff like <ipynb_license
> src="http://site.com/license.html"> and <ipynb_author name="John Doe"
> mail="jd at site.com"> and so on.
> 
> Maybe I'm still missing something, but that's where my thinking has
> led me so far.
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev