-
Notifications
You must be signed in to change notification settings - Fork 34
Roadmap and wishlist
It would be nice to add some features to interval cells:
- bind some dynamic variables in the interval fn, like
*mouse-x*and*mouse-y*(adjusted so the card's top/left is 0/0) - keep a counter for each
interval'd expression from when it started running,incing it at each callback. Maybe*tick*? This would make for a nicer Processing-like experience for animations. Currently we rely on temporal recursion, which serves a similar purpose.
A publishing mechanism not just for the source code of a buffer (i.e. similar to our current gists), but rather for the "card view" of a project, which is then like a micro-webapp.
It would be nice if selecting and copying a shape (and similarly with other special output) from the output pane copied the source code to produce it.
An override of built-in docstrings with beginner-friendly examples would be nice. There have been some efforts in this direction (eg. https://github.com/ericnormand/ultra-docstrings).
At some point we will likely move toward an editor which directly maps to a tree structure, rather than a flat file (but still (de)serializes to valid Clojure code). This will make many new improvements possible and/or easier.
zebra highlighting (https://github.com/mhuebert/maria/issues/40#issue-241504842):
Can we decorate with a class the depth of each expression modulo 2? I'd like to add subtle "zebra highlighting" by setting the background of each expression to an alternating set of very light grays -- like this, but prettier.
better highlighting (https://github.com/mhuebert/maria/issues/40#issuecomment-314022117):
determine the types of things in the code by interrogating the running VM rather than guessing from a lookup table.
The dir command lists all of the defs of a namespace, but we should probably have a more helpful namespace browser which also includes referred names, eg. everything in ns-map.
- The namespace browser could be a primary way for users to inspect the structure and state of an app
- Namespaces can be (de)serialized from/to different datastores (eg. gists, zip archive, database), and be the basis for version control
- Can port a bunch of stuff from here (not self-host friendly): https://github.com/franks42/cljs-info/blob/master/src/cljs_info/ns.clj
- Shorter term idea: create a fn to detect a leading ns form in a file. When present, use the namespace's name for current title instead of the filename.
Selections currently work only within cells. It would be nice to be able to select across cell boundaries, for copy/paste of larger sections of a namespace. It may not be practical to do this until we have our own tree-based editor implementations for both code and prose cells.
Just tabling a number of cross-cutting concerns to discuss in-person sometime.
- Prioritize messages & collapse most by default: we usually have a number of messages at once, coming from warnings & errors, which need to be prioritized and visualized appropriately. We don't necessarily want to show all of the errors at once - probably only show the top message, with a link to click for more. I started today by putting 'warnings' above 'errors' because they are often more informative about root-causes (issues that have been noticed before compile is finished).
- Names for warnings/errors: I modified
parse-warningand it now returns the :name and :doc(string) for a warning. I find that I don't want to have to read a whole paragraph for warnings/errors that I see often - I would rather scan & see the name of the error first, and then read the details if necessary. This would work well for the collapsed view - we could show a summary of all the errors/warnings by name, & click to see more. - Links in warnings/errors: it would be nice to be able to link to further documentation to help a user with their error message. Unsure if it would be more convenient to just parse error messages as markdown (with links) or store links as some kind of structured metadata (easier to format nicely).
- Stack visualization and expansion: we should parse the error message stack and allow the user to view source code (with location highlighted) for each item in the stack. Stack should not be expanded/shown by default.
- Design: I have made some add-hoc modifications (dividers, name display) to the error/warning views but they could use a more holistic revisit as it is not looking very pretty. (This would be a natural part of implementing summary/expandable views.)
- Code highlights: it should be possible for a message-handler to return instructions for which form(s) to highlight, given an error/warning + context.
So, in summary:
- Show only top message, click to view the rest
- Return a :name for each error for summary view
- Support linking to external resources from error messages
- Nicer overall design for errors/warnings
- Friendly display/navigation of the error stack
- Support specific form highlighting based on the particular error
- enable clojure.spec/instrument for runtime arg validation etc.
One possibility we would like to explore is the idea of modifying what aspects of Clojure functionality are exposed at different levels. This is of course inspired by How to Design Programs' Teaching Languages from the Racket branch of our lispy family tree.
We're still brainstorming what differences a beginner version of Clojure would have from normal Clojure. Some ideas--and they are ideas only!--include:
- coercing
mapintomapv(and so on for similar functions that return lazy lists, e.g.filter(v)), so that the syntax overload of parentheses for function calls and lists doesn't have to be introduced concurrently with HOFs - provide friendly docstrings at Level 0, and remove them (unless the user explicitly asks for the friendly version) at later levels when they should be integrating with Orthodox Clojure Docstring terminology
- ??? we need to find out what trips beginners up -- share your experience or ideas! We know there are some common Clojure gotchas, but it's not always clear how to patch them up.