<br><br><div class="gmail_quote">On Tue, Jun 19, 2012 at 1:05 PM, Brian Granger <span dir="ltr"><<a href="mailto:ellisonbg@gmail.com" target="_blank">ellisonbg@gmail.com</a>></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 <<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>> wrote:<br>
><br>
><br>
> On Tue, Jun 19, 2012 at 12:05 PM, Jonathan Taylor<br>
> <<a href="mailto:jonathan.taylor@stanford.edu">jonathan.taylor@stanford.edu</a>> wrote:<br>
>><br>
>> That's the sort of use case I imagine as well, where a cell magic wants<br>
>> to about something to the frontend a little more information about what<br>
>> kind of cell it is (in your %%bash example, it would be a code cell for<br>
>> which the code_mirror might use bash highlighting instead of python). This<br>
>> seems like it could be accomplished with something parallel to<br>
>> "publish_display_data" for cell metadata which different frontends can<br>
>> handle differently.<br>
><br>
><br>
> publish_display_data already takes a metadata arg.  This has always been the<br>
> case, but so far it's totally unused.<br>
><br>
> I just noticed, this metadata is *not* included in the added fields<br>
> 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'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>
> -MinRK<br>
><br>
>><br>
>><br>
>> On Tue, Jun 19, 2012 at 8:49 AM, Thomas Kluyver <<a href="mailto:takowl@gmail.com">takowl@gmail.com</a>> wrote:<br>
>>><br>
>>> On 19 June 2012 16:08, Jonathan Taylor <<a href="mailto:jonathan.taylor@stanford.edu">jonathan.taylor@stanford.edu</a>><br>
>>> wrote:<br>
>>> > Yes, it would not be good to have the API of cell magics be notebook<br>
>>> > specific. What about providing a reference to the current cell metadata<br>
>>> > in<br>
>>> > the Magics class that can be used to update the NotebookNode after<br>
>>> > executing<br>
>>> > cell.input? So, cell_magics would not have access to the metadata on<br>
>>> > execution but could pass any metadata it wanted to back to the<br>
>>> > notebook.<br>
>>><br>
>>> Before we get too far into the mechanism, let's try to think about<br>
>>> actual use cases, so we can figure out how things need to work.<br>
>>><br>
>>> We can also see cell magics themselves as a sort of within-cell<br>
>>> metadata. For example, the frontend might one day be aware that if a<br>
>>> cell starts with %%bash, different syntax highlighting and tab<br>
>>> completion rules apply to it. I think this would need to be within the<br>
>>> frontend, rather than going through the kernel, because we want to use<br>
>>> the new highlighting & completion before the cell is executed.<br>
>>><br>
>>> Thomas<br>
>>> _______________________________________________<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>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Jonathan Taylor<br>
>> Dept. of Statistics<br>
>> Sequoia Hall, 137<br>
>> 390 Serra Mall<br>
>> Stanford, CA 94305<br>
>> Tel:   <a href="tel:650.723.9230" value="+16507239230">650.723.9230</a><br>
>> Fax:   <a href="tel:650.725.8977" value="+16507258977">650.725.8977</a><br>
>> Web: <a href="http://www-stat.stanford.edu/~jtaylo" target="_blank">http://www-stat.stanford.edu/~jtaylo</a><br>
>><br>
>> _______________________________________________<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>
>><br>
><br>
><br>
> _______________________________________________<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>
><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>