Open dpsanders opened 11 years ago
This may happen far into the future. For now, one would normally write such docs by using nbconvert to transform to reST. Raw Cells can be used to write raw output that won't be transformed by nbconvert, so you can write raw reST (or latex or html) as well.
%%reST will never work like latex - note that the cell magics are for writing raw interactive output data. The notebook does not (and probably will not) support live rendered rest, so %%rest
won't make sense.
Sorry, I don't understand your point.
If I understand correctly, the %%latex
input cell gets replaced by
HTML-ish rendered output.
Why can't a %%rest cell get replaced by HTML-ish rendered output too?
On Sun, Jul 21, 2013 at 12:31 PM, Min RK notifications@github.com wrote:
%%reST will never work like latex - note that the cell magics are for writing raw interactive output data. The notebook does not (and probably will not) support live rendered rest, so %%rest won't make sense.
— Reply to this email directly or view it on GitHubhttps://github.com/ipython/ipython/issues/3714#issuecomment-21313577 .
Dr. David P. Sanders
Profesor Titular "A" / Associate Professor Departamento de Física, Facultad de Ciencias Universidad Nacional Autónoma de México (UNAM)
dpsanders@gmail.com http://sistemas.fciencias.unam.mx/~dsanders
Cubículo / office: #414, 4o. piso del Depto. de Física
Tel.: +52 55 5622 4965
The notebook knows how to render latex (mathjax). The notebook does not know how to render reST.
But the %%rest
magic can include the call to pandoc
to convert the reST to HTML which can be returned for the cell's _repr_html_
. If I understand the rich display mechanism correctly (doubtful).
That would make %%rest would be a purely kernel-side magic (unlike any other rich-output display magic). This might be okay, though there are serious issues with rendering rST one cell at a time (gist: it doesn't make sense). restructured text has lots of implicit document-wide formatting that can only be computed a whole document at a time.
For instance, let's say you have these two cells:
h1
==
some text
h2
--
more text
What would you expect the formatting of the text 'h2' to have? If you answered "exactly the same as h1", you would be right. But if you concatenate the two cells into one, it would change and "h2" would be a lower level than h1. It is this sort of thing that made us reject reST as a good fit for the notebook - rst just makes no sense without rendering an entire document (or multi-document environment) at a time.
Sure, but I just need local visual feedback around the current line that I'm editing, as a crux for my limited recall of obscure markup syntaxes (especially if I'm mixing Markdown with reST in different cells!); the global view with all the links can come later when everything is rendered fully.
+1 I would also like to see this feature
I know that new cell types are not "allowed", and that there was previously a reST cell type and it was removed.
However, this prevents IPython from being a Python documentation editor (as I discovered a couple of days ago to my chagrin!) There thus needs to be some way (whatever, really) of being able to edit and render reST in a markup cell.
But really what we need is a generic "markup" (not Markdown!) cell type, with some way of configuring what kind of markup is used. CodeMirror can do them all, I guess.
The %%latex magic is basically this, since LaTeX is just being used here as a markup language for maths.
It would be easy to write a %%reST magic I guess, as a stop-gap (or permanent) solution.