[IPython-dev] Questions on implementing some notebook frontend extensions
andrew.gibiansky at gmail.com
Sat Mar 7 16:23:17 EST 2015
Thanks Min! That's exactly the sort of feedback I was hoping to get.
To respond to your question about what I've found lacking, my main desires
for additions to IPython are for a better import and export story for
kernels. Specifically, right now IPython supports the following exports:
- PDF via latex
These are all well and good, but they're not enough. In my experience, the
formats used vary by technology and community, and thus need to be someone
more flexible. Specifically, in the Haskell world, we at least would want
- Import from literate Haskell (two different types of literate haskell)
- Export to literate Haskell (two different types)
- Export to a Haskell module (which would require some processing to
make the cells actually valid compilable Haskell code)
- Export to a cabal package (which would be like exporting to a Haskell
module, but with more postprocessing)
These are things that are pretty integral to the Haskell ecosystem, and so
it would make sense to ship them with the IHaskell kernel, and not as some
sort of extensions. That said I totally understand why these don't exist
(yet) -- there's tons of stuff going on in the IPython world and there's
not enough developer manpower to do *everything, *but I do hope that going
forward to 3.1 or 4 or whatever is next, there might be some design work
put into a more compelling configurable import/export story.
On Sat, Mar 7, 2015 at 12:17 PM, MinRK <benjaminrk at gmail.com> wrote:
> On Fri, Mar 6, 2015 at 11:50 PM, Andrew Gibiansky <
> andrew.gibiansky at gmail.com> wrote:
>> Hey all,
>> I have a few frontend modifications I'd like to make for the IHaskell
>> kernel, and I'd love to get some pointers on where to start and how
>> feasible these are. I have some ideas, but since you are much more familiar
>> with the client-side JS than I am, I'd like to hear if you think these are
>> possible and/or reasonable, and perhaps how you would approach them (no
>> detailed response required, maybe just something like "Use the CodeMirror
>> api" or "we have some undocumented capabilities for this in IPython" or
>> "wait until CodeMirror 5" or "impossible").
>> The extensions are:
>> 1. Get some info about an identifier from the kernel when I hover my
>> mouse over that identifier, and display it as a popup.
>> Idea: Use CodeMirror API and IPython comms to communicate with kernel.
> I think CM.coorsChar is the relevant API.
> You might not need to use comms for this one, if `inspect_request` is the
> right action. If the output should be distinguished from inspection via
> other means, then a custom comm would be appropriate.
>> 2. Add a keyboard shortcut to automatically reformat a cell, and have
>> this actually change the contents of whichever cell is currently selected,
>> provided it is a Haskell cell.
>> Idea: Use the IPython API to add a keyboard shortcut, use comms to
>> communicate with backend to do reformatting, use IPython API to get
>> currently selected cell and send contents to kernel via comm, and use
>> IPython APIs to change the contents of a cell.
> Sounds right to me.
>> If you have any suggestions for better routes, words of caution, I'd love
>> to hear them.
>> (As an aside, one reason I am asking like this rather than just going
>> ahead and trying it and seeing how far I get is that some of these may be
>> tackled by some other contributors to IHaskell; I would like to make sure I
>> am not sending them off on a wild goose chase with a method that is
>> overcomplicated or unlikely to work before giving them instructions.)
> I see no geese here to chase.
>> PS. IHaskell `master` now supports IPython 3.0. There's still a bit of
>> work to be done before I'm ready to make a Jupyter-ready *release*, but it
>> is no more than a week or two out. So far, I've really enjoyed working with
>> IPython 3; the interface is great, the kernel interface is well thought out
>> (if perhaps missing a few things I want, but there's always room for
>> extension, I hope :) ), and all in all it's been very good.
> Great to hear that 3.0 is working out for you. Can you describe the
> missing things? It may be a while before there's another revision, but it's
> good to keep track of what shortcomings kernel authors find, so we can make
> the right adjustments in the future.
>> IPython-dev mailing list
>> IPython-dev at scipy.org
> IPython-dev mailing list
> IPython-dev at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev