[IPython-dev] Highlight lines of code in code cells?

[Eric Matthes]

For the record, here's what I ended up implementing. I realized that adding
comments before and after every line/s to be highlighted was ridiculous, so
I implemented the functionality I saw last time I used wordpress to write a
tutorial.

At the beginning of a code block, I write a comment in the following
format, specifying which lines will be highlighted:
###highlight=[1,2,7,8,9]

The raw notebook files do not end up with any highlighting, that's
something I can't implement right now. I run nbconvert, and then I wrote a
script [0]<https://github.com/ehmatthes/intro_programming/blob/master/scripts/highlight_code.py>that
parses these html files. Whenever it finds this ###highlight
directive, it removes the directive itself and then adds <div
class='highlight_code_line'>...</div> tags to the appropriate lines in that
code block.

I think the final result
[1]<http://introtopython.org/visualization_earthquakes.html>looks much
better than it did without highlighting, for the purposes of a
tutorial.

The raw notebook
[2]<http://nbviewer.ipython.org/urls/raw.github.com/ehmatthes/intro_programming/master/notebooks/visualization_earthquakes.ipynb>suffers
slightly in that it has these ###highlight= comments on the first
lines of many cells, but that's worthwhile to me in the short term, and it
would be easy to write a quick script to remove them if needed. (This
notebook might take a long time to render, because it's a bunch of Basemap
examples.)

Happy to hear feedback if there is a way to make my approach a little more
in line with how IPython does things.

Eric

[0] -
https://github.com/ehmatthes/intro_programming/blob/master/scripts/highlight_code.py

[1] - http://introtopython.org/visualization_earthquakes.html

[2] -
http://nbviewer.ipython.org/urls/raw.github.com/ehmatthes/intro_programming/master/notebooks/visualization_earthquakes.ipynb


On Mon, Dec 2, 2013 at 7:23 PM, Mark Voorhies <mark.voorhies at ucsf.edu>wrote:

> On 12/02/2013 05:41 PM, Gabriel Becker wrote:
> > Unless I completely miss my guess, shell.history_manager is going to look
> > at the code that has been executed. This is related to what is in the
> > cells, of course, but it isn't the same.
> >
> > Also, the concept of "cell number" if I am correct in assuming you are
> > referring to the numbers that appear next code cells after the run, is
> that
> > they are not persistently connected to current cell content and don't
> have
> > a 1-to-1 correspondence to the actual cells during non-headless
> execution.
> >
> > i.e. if a code cell is executed, then edited and executed again, but the
> > cell number targeted for diffing isn't changed, a magic using
> > shell.history_manager will grab the contents of the cell *when it was run
> > the first time*
>
> All of this is correct.
>
> > as opposed to what I think is conceptually intended, which
> > is what is in the cell now.
>
> It is true that my approach won't work for anything that the kernel hasn't
> seen,
> so it can't do live updates of the diff as cells are edited (and JS
> _would_ be
> the right approach for that sort of thing).  Outside of that, I think most
> behaviors can be achieved given the right interface.
>
> Here's what the current iteration (
> https://github.com/markvoorhies/ipython/commit/216ea233413a20061e6c77863798d449be6200c9
> )
> can handle:
>
> %diff 6 7
>
> --> gives diff of cells [6] and [7].  If [7] is edited (e.g., becoming
> [9]), the %diff output does not change,
>      even if re-run.  %diff 6 9 _does_ diff the new content.
>
> %diff 6
>
> --> gives diff of the last cell (e.g., [7]) with cell [6].  If cell [7] is
> edited and re-run (e.g., becoming [9]),
>      re-running the %diff _does_ diff [6] and [9].
>
> %diff
>
> --> gives diff of the last two cells (e.g. [6] and [7]).  This is not
> useful for re-running (because the %diff cell
>      itself becomes part of the history), but is a nice shorthand for the
> most common use case.
>
> %diff A B
>
> --> diffs the most recent cells with first lines "##label:A" and
> "##label:B" respectively.  If either cell is
>      edited and re-run, then re-running the %diff _does_ diff the latest
> content.
>      (This is a place-holder, pending an IPythonic mechanism for labeling
> cells)
>
> The last example allows this work flow:
>
> 1) Create cell "##label:A"
> 2) Create cell "##label:B" (via M-C,M-V in cell A and editing)
> 3) %diff A B
> 4) Fix up A and B with little edits as needed, re-running the edited cell
> and "%diff A B" with each edit.
> 5) Create cell "##label:C" (via M-C,M-V in cell B and editing)
> 6) %diff B C
> 7) Fix up C with little edits as needed, re-running the edited cell and
> "%diff B C" with each edit.
> 8) etc.
>
> For teaching, I would tend to skip the "little edits" steps, in which case
> (3) can become "%diff A"
> and (6) can become "%diff B".
>
> --Mark
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131204/d1cdfbe6/attachment.html>