<br><br><div class="gmail_quote">On Tue, Jun 19, 2012 at 1:05 PM, Brian Granger <span dir="ltr">&lt;<a href="mailto:ellisonbg@gmail.com" target="_blank">ellisonbg@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Tue, Jun 19, 2012 at 12:21 PM, MinRK &lt;<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Jun 19, 2012 at 12:05 PM, Jonathan Taylor<br>
&gt; &lt;<a href="mailto:jonathan.taylor@stanford.edu">jonathan.taylor@stanford.edu</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; That&#39;s the sort of use case I imagine as well, where a cell magic wants<br>
&gt;&gt; to about something to the frontend a little more information about what<br>
&gt;&gt; kind of cell it is (in your %%bash example, it would be a code cell for<br>
&gt;&gt; which the code_mirror might use bash highlighting instead of python). This<br>
&gt;&gt; seems like it could be accomplished with something parallel to<br>
&gt;&gt; &quot;publish_display_data&quot; for cell metadata which different frontends can<br>
&gt;&gt; handle differently.<br>
&gt;<br>
&gt;<br>
&gt; publish_display_data already takes a metadata arg.  This has always been the<br>
&gt; case, but so far it&#39;s totally unused.<br>
&gt;<br>
&gt; I just noticed, this metadata is *not* included in the added fields<br>
&gt; preserved in the notebook, but I will get on that.<br>
<br>
</div>But I think the publish_display_data metadata is separate from the<br>
cell metadata.  Are you thinking we should save another set of<br>
metadata with the display data output?<br></blockquote><div><br></div><div>Yes - we put metadata on outputs for a reason, presumably.  If this shouldn&#39;t be saved, it should probably be removed from the API.</div><div>

 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5"><br>
&gt; -MinRK<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Tue, Jun 19, 2012 at 8:49 AM, Thomas Kluyver &lt;<a href="mailto:takowl@gmail.com">takowl@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On 19 June 2012 16:08, Jonathan Taylor &lt;<a href="mailto:jonathan.taylor@stanford.edu">jonathan.taylor@stanford.edu</a>&gt;<br>
&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt; &gt; Yes, it would not be good to have the API of cell magics be notebook<br>
&gt;&gt;&gt; &gt; specific. What about providing a reference to the current cell metadata<br>
&gt;&gt;&gt; &gt; in<br>
&gt;&gt;&gt; &gt; the Magics class that can be used to update the NotebookNode after<br>
&gt;&gt;&gt; &gt; executing<br>
&gt;&gt;&gt; &gt; cell.input? So, cell_magics would not have access to the metadata on<br>
&gt;&gt;&gt; &gt; execution but could pass any metadata it wanted to back to the<br>
&gt;&gt;&gt; &gt; notebook.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Before we get too far into the mechanism, let&#39;s try to think about<br>
&gt;&gt;&gt; actual use cases, so we can figure out how things need to work.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; We can also see cell magics themselves as a sort of within-cell<br>
&gt;&gt;&gt; metadata. For example, the frontend might one day be aware that if a<br>
&gt;&gt;&gt; cell starts with %%bash, different syntax highlighting and tab<br>
&gt;&gt;&gt; completion rules apply to it. I think this would need to be within the<br>
&gt;&gt;&gt; frontend, rather than going through the kernel, because we want to use<br>
&gt;&gt;&gt; the new highlighting &amp; completion before the cell is executed.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Thomas<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; IPython-dev mailing list<br>
&gt;&gt;&gt; <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
&gt;&gt;&gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Jonathan Taylor<br>
&gt;&gt; Dept. of Statistics<br>
&gt;&gt; Sequoia Hall, 137<br>
&gt;&gt; 390 Serra Mall<br>
&gt;&gt; Stanford, CA 94305<br>
&gt;&gt; Tel:   <a href="tel:650.723.9230" value="+16507239230">650.723.9230</a><br>
&gt;&gt; Fax:   <a href="tel:650.725.8977" value="+16507258977">650.725.8977</a><br>
&gt;&gt; Web: <a href="http://www-stat.stanford.edu/~jtaylo" target="_blank">http://www-stat.stanford.edu/~jtaylo</a><br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; IPython-dev mailing list<br>
&gt;&gt; <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
&gt;&gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; IPython-dev mailing list<br>
&gt; <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
&gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
&gt;<br>
<br>
<br>
<br>
--<br>
</div></div>Brian E. Granger<br>
Cal Poly State University, San Luis Obispo<br>
<a href="mailto:bgranger@calpoly.edu">bgranger@calpoly.edu</a> and <a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br>