[IPython-dev] javascript linting in the notebook

Nicholas Bollweg nick.bollweg at gmail.com
Fri Apr 11 08:22:11 EDT 2014

tl; dr: linting, dark theme, 2 space indent. snippet here:


or hot-load it:

    require(["http://goo.gl/5OdkGb"], Object);

i love the new notebook features! great job on 2.0, everyone! one
observation is that the notebook really is the best place, from a workflow
point of view, to prototype widgets FOR the notebook, so i end up writing a
lot of javascript there.

however,  the environment is pretty unforgiving. the "syntax error
someplace, go look at the log" error is not great, especially when it gets
swallowed by the comms layer.

also, as anticipated in the ipep, it is somewhat confusing to be
context-switching back and forth between python and javascript.

finally, given that you *start* at pretty deep callback nesting (`require`,
`extend(`, `update`), and libraries like d3 make nesting even more
inevitable, I wanted less whitespace.

here is a little script I have been dinking around with to get a more
supportive javascript editing environment for hacking on widgets:


feedback welcome!

- per-keystroke linting (async and throttled, though, so it doesn't seem to
cause any issues)
- different theme
- indent (2 spaces)

- it isn't smart enough to switch the options back if you change out of
javascript mode, but switching to, say, markdown mode and back to code
takes care of it.
- it "leaves no trace" which means it can't tell if it has already been
installed.. so running it multiple times is probably bad (but codemirror is
pretty good about it)

next steps
- a toggle button to enable this mode
- switches for jshint options: semicolons, strict mode, etc.
- theme switch

looking through the codemirror demos, the `tern` stuff is also interesting:
but i didn't want to wade into more keyboard mapping issues just yet.
however, maybe even the baseline javascript hinter that looks at the
running environment would be pretty great.

`jshint` is great for the basics: broken syntax, missing semicolons, strict
enforcement, etc, but it kind of does what it does. `eslint` looks very
nice: perhaps the "widget best practices" could be codified into some
design rules like
  "warn on change of `this.model` in `update`"
i don't know if it's 1:1 compatible with codemirror's jshint plugin,
though, so it make take some rework.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20140411/b4a3c8d1/attachment.html>

More information about the IPython-dev mailing list