[IPython-dev] eco: a composed language editor

Nicholas Bollweg nick.bollweg at gmail.com
Sat Aug 23 13:52:55 EDT 2014

More of a thought exercise than a discussion of actual features: i recently
read about this editor for composed languages, eco:

   - site: http://soft-dev.org/src/eco/
   - paper:
   - repo: https://bitbucket.org/softdevteam/eco/

Just from their examples, I now have this picture in my mind of a
codemirror-based, eco-like editor in a cell that lets me prototype an
interactive GUI driven by a couple SPARQL queries with python interpolated
inside the querie, without any templating stuff in sight. I can mix in
Widgets wherever I like. Hell, throw in some coffeescript and LESS.

At first glance, it's a 90's PHP nightmare, but then I remember that I can
immediately tell if all of the layers are syntactically correct, since each
layer was interactively built against a grammar, augmented by what is known
about the current running environment.

Some things I thought about:

   - what is a composed kernel(s)?
      - they don't really cover how one might actually *execute *one of
      these files. for their example with HTML, Python, SQL, what's really
      happening? in my mind, this is really just a python kernel that
wraps HTML
      and SQL as strings, but a more involved example?
   - how would parser-driven editing in context work?
   - the completion available in a running kernel is already far beyond
      what a  grammar-only completion tool can do. what would a more
      parser-driven editing experience be like?
      - how would one store a tree of tokens?
   - presumably, storing serialized JSON in cells[].source, while ugly,
      would work. or metadata.
      - what are visual tokens
   - actually, in line with the jupyter iconography (i.e. galileo's moon),
      the inlining of visual tokens would be incredible. codemirror doesn't
      appear to support flowed widgets (yet?). their suggested "real" use, of a
      formula editor, is interesting. And, of course, matrices.
      - eco native format is gzipped JSON
      - i think this has been discussed before (ipynbz). i don't know what
      advantage this provides over just having the json out there, but i have
      created some pretty big notebooks before. also, notebook files are not
      really hand editable (though I have done so).

Interested in what other folks think...


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

More information about the IPython-dev mailing list