add raw_mimetype metadata to raw cells by minrk · Pull Request #4306 · ipython/ipython

minrk · 2013-09-30T03:13:38Z

allows exclusion in nbconvert based on format. If no format is specified, a raw cell is included by default (matches current master behavior).

and adds Raw Cell cell toolbar

damianavila · 2013-09-30T13:24:33Z

Great, at the time of writing this, I did not notice to write it inherited from HTMLExporter instead of a more basic one... less code to maintain 👍

damianavila · 2013-09-30T13:41:31Z

@minrk a general question... do we have plans to make the metadata of raw cells available to the user in a simpler way? Currently it is exposed through the CellToolBar, but not easy to modified for final user... or this PR is related to the change of the notebook format (I did not read yet)? Or, I am missing some things, which is the most probably ;-)

minrk · 2013-09-30T16:50:12Z

@damianavila I think raw cells should get their own toolbar for setting the raw format type, I will be looking into that today.

damianavila · 2013-09-30T17:05:27Z

ok, thanks for the info!

Carreau · 2013-10-03T12:00:01Z

+1

Carreau · 2013-10-04T10:04:11Z

As discussed yesterday, do you want to use mimetype instead of 'html','python',... ?

minrk · 2013-10-04T17:25:09Z

As discussed yesterday, do you want to use mimetype instead of 'html','python',... ?

I'm not entirely sure - mimetype is better for machines, but humans don't really want to type them, and the only way to specify format right now is to edit raw metadata, which means typing it all out. I'll look into a toolbar for raw cells that might alleviate that.

Carreau · 2013-10-06T09:21:57Z

isn't the raw_format/raw_formats a little too much ? I guess it's for convenience, but I'm worried it willl be too complicated for user. why not just stick with raw_formats ?

minrk · 2013-10-06T19:37:06Z

raw_format is used for the default value. I guess I could replace that with raw_formats[0], but that would raise if anyone does raw_formats = [] to exclude any raw format. I'll see if I can remove it cleanly.

ellisonbg · 2013-10-09T20:07:30Z

Given the strong connotation of the work "output" in the context of the notebook (to mean the output of running code), I don't think this word change makes sense. What is the problem with "Raw Text"?

We have proof that "Raw Text" is confusing to people, perhaps because it is simply not accurate.
A raw cell is always raw nbconvert output (html, rst, latex, etc. - it is never plain text).

Many people interpret 'Raw Text' as 'Unformatted Text', aka <pre>, which is totally sensible based on the label. But this is not what Raw Cells are. Raw Cells are, by definition, raw nbconvert output.

Obviously, there is some ambiguity between Code Cell output and nbconvert output, but I think Raw Output is less confusing than Raw Text. Do you have a better alternative? Should we be extremely explicit and label them raw nbconvert output, since that is what they are?

I agree that "Raw Text" is confusing.

A good fraction of notebook users never touch nbconvert. For those users,
the phrase "nbconvert output" means little, if anything. Even in the
context of nbconvert, calling this output is confusing. It is really input
from a user that nbconvert passes through unmodified to its output.

In the notebook UI, it is in fact plain, unformatted, unrendered text.

What about the following. In the Notebook UI, we refer to these in a way
that reflects their usage in the Notebook UI - maybe Unrendered Text? If
we want to stick with the output idea, I do think that "Raw nbconvert
output" is better though.

This also makes me think that one of the metadata values for these cells,
in addition to html, rst, latex, should be verbatim/pre. In that case it
would simply dump the content of the cell into a pre if html or verbatim if
latex. But maybe that violates the pass-through aspect of these cells.

On Wed, Oct 9, 2013 at 3:07 PM, Min RK notifications@github.com wrote:

In IPython/html/templates/notebook.html:

@@ -126,7 +126,7 @@

Code

Markdown

<li id="to_raw"><a href="#">Raw Text</a></li>

<li id="to_raw"><a href="#">Raw Output</a></li>

We have proof that "Raw Text" is confusing to people, perhaps because it
is simply not accurate.
A raw cell is always raw nbconvert output (html, rst, latex, etc. - it
is never plain text).

Many people interpret 'Raw Text' as 'Unformatted Text', aka
, which
is totally sensible based on the label. But this is not what Raw Cells are.
Raw Cells are, by definition, raw nbconvert output.

Obviously, there is some ambiguity between Code Cell output and nbconvert
output, but I think Raw Output is less confusing than Raw Text. Do you have
a better alternative? Should we be extremely explicit and label them raw
nbconvert output, since that is what they are?

—
Reply to this email directly or view it on GitHubhttps://github.com/ipython/ipython/pull/4306/files#r6872554
.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

What about something like 'raw inclusion'?

What about something like 'raw inclusion'?

I like that...

Or "nbconvert passthrough"

I prefer raw inclusion, but at the end, any of the last ones will work, I think...

I would like us to find a name that reflects how these are handled in the
notebook UI, not just nbconvert.

On Fri, Oct 11, 2013 at 8:43 AM, Damián Avila notifications@github.comwrote:

In IPython/html/templates/notebook.html:

@@ -126,7 +126,7 @@

Code

Markdown

<li id="to_raw"><a href="#">Raw Text</a></li>

<li id="to_raw"><a href="#">Raw Output</a></li>

I prefer raw inclusion, but at the end, any of the last one will work, I
think...

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/4306/files#r6918597
.

Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

That seems odd to me. Their role in the notebook UI doesn't seem important, given that the entire point of the cell is a place to dump nbconvert output. For instance, totally hidden (maybe toggle on/off) raw cells makes perfect sense from a UI perspective, since they are guaranteed to not have any function in the live notebook.

Carreau · 2013-11-05T17:06:10Z

FYI, need rebase.

minrk · 2013-11-05T18:53:33Z

Yes, and I need to cleanup the cell toolbar code, so I can get a toolbar on just one type of cell.

minrk · 2013-11-06T20:13:51Z

inching closer on this one. I have the raw format cell toolbar mostly working.

Carreau · 2013-11-11T10:44:34Z

empty branch in one condition ?

haven't written the dialog yet, still need to do that.

Carreau · 2013-11-11T10:51:01Z

Except one comment the js/css part seem ok. haven't read the rest though.
This will conflict with css-cleaning, but I can rebase.
This can also have small conflict with Brian modal UI I think.

Carreau · 2013-11-13T10:51:24Z

This need a rebase ... Sorry.

select based on raw_format metadata key if defined. Default behavior is to include raw cells of unspecified format (consistent with existing behavior).

sets their values in resources

make hierarchical rather than either/or. Also, don't use the same class name for the outer and inner css classes.

and make sure cell_type is defined *before* calling TextCell.apply

- in toJSON - don't clobber existing value in Cell constructor

minrk · 2013-11-21T00:29:35Z

rebased, and the toolbar now only displays on the raw cells. The metadata key is raw_mimetype, and the values are mime types ('text/latex', 'application/x-python', etc.).

damianavila · 2013-11-26T18:13:11Z

Instead of "restructuredText" I would use "reST"... so the dropdown menu would be narrowed.

damianavila · 2013-11-26T18:38:50Z

I tested a little bit and I like... again 👍

I just added some minor comments.

Carreau · 2013-12-05T09:38:54Z

@minrk would you like to respond to @damianavila comment ? Or should we modify that in later PRs ?

minrk · 2013-12-05T17:33:18Z

I'll tweak it to be more generic. The way the code works, I don't think it would be worth the effort to make placeholder support variation.

minrk · 2013-12-05T18:41:37Z

restructuredtext->rST in selector so it can be narrower.

damianavila · 2013-12-05T19:37:15Z

Great! Thanks for addressing the comments

reduces width

add raw_mimetype metadata to raw cells

Carreau · 2013-12-07T15:48:31Z

Great ! Thanks !

add raw_mimetype metadata to raw cells

damianavila reviewed Sep 30, 2013
View reviewed changes

ellisonbg reviewed Oct 9, 2013
View reviewed changes

Carreau reviewed Nov 11, 2013
View reviewed changes

ghost assigned minrk Nov 13, 2013

minrk mentioned this pull request Nov 20, 2013

Fixing cell_type in CodeCell constructor. #4566

Merged

minrk added 12 commits November 20, 2013 14:47

move raw cell inclusion to null.tpl

326a296

select based on raw_format metadata key if defined. Default behavior is to include raw cells of unspecified format (consistent with existing behavior).

add raw_format to Exporter classes

3227d92

sets their values in resources

test raw cell inclusion based on raw_format metadata

bf0f48b

rename Raw Text to Raw NBConvert in menu

43fdbfa

tweak global hide/show

8cda9a7

make hierarchical rather than either/or. Also, don't use the same class name for the outer and inner css classes.

give Raw Cells a placeholder

9591088

and make sure cell_type is defined *before* calling TextCell.apply

clarify name of 'default' cell toolbar

16b4d48

allow cell toolbar presets to apply only to specific cell types

1be9a3f

add raw cell toolbar preset

c232f58

add dialog to raw cell toolbar

5be8d3e

set cell_type properly first-class in the Cell object

e5d41b3

- in toJSON - don't clobber existing value in Cell constructor

fix Python mime-type

7bff4b3

propagate raw_mimetype to nbconvert

4e36d7f

damianavila mentioned this pull request Nov 26, 2013

reST cell type (render in server-side as a whole document) #4301

Closed

damianavila reviewed Nov 26, 2013
View reviewed changes

tweak raw placeholder

91c37c1

use reST in raw cell toolbar

74a45bf

reduces width

Carreau added a commit that referenced this pull request Dec 7, 2013

Merge pull request #4306 from minrk/raw-cell-metadata

8c37384

add raw_mimetype metadata to raw cells

Carreau merged commit 8c37384 into ipython:master Dec 7, 2013

minrk deleted the raw-cell-metadata branch March 31, 2014 23:36

mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this pull request Nov 3, 2014

Merge pull request ipython#4306 from minrk/raw-cell-metadata

801c90f

add raw_mimetype metadata to raw cells

Uh oh!

Conversation

minrk commented Sep 30, 2013

Uh oh!

Choose a reason for hiding this comment

Uh oh!

damianavila commented Sep 30, 2013

Uh oh!

minrk commented Sep 30, 2013

Uh oh!

damianavila commented Sep 30, 2013

Uh oh!

Carreau commented Oct 3, 2013

Uh oh!

Carreau commented Oct 4, 2013

Uh oh!

minrk commented Oct 4, 2013

Uh oh!

Carreau commented Oct 6, 2013

Uh oh!

minrk commented Oct 6, 2013

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Carreau commented Nov 5, 2013

Uh oh!

minrk commented Nov 5, 2013

Uh oh!

minrk commented Nov 6, 2013

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Carreau commented Nov 11, 2013

Uh oh!

Carreau commented Nov 13, 2013

Uh oh!

minrk commented Nov 21, 2013

Uh oh!

Choose a reason for hiding this comment

Uh oh!

damianavila commented Nov 26, 2013

Uh oh!

Carreau commented Dec 5, 2013

Uh oh!

minrk commented Dec 5, 2013

Uh oh!

minrk commented Dec 5, 2013

Uh oh!

damianavila commented Dec 5, 2013

Uh oh!

Carreau commented Dec 7, 2013

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants