campadrenalin / broco Goto Github PK

Not sure yet why this is a problem - possibly the wrong white-space CSS - but if you put multiple spaces into the prompt, it shows up as one, at most.

Pretty much every existing module already has documentation, it's just not exposed to the 'help' module. Let's fix that.

For the Github Pages demo and branding in general, it would be cool to have a logo at some point. I'm gonna design a logo at some point in Inkscape, in the form of broccoli. Eat your veggies, kids! This isn't a high-priority ticket, but on the other hand, it might make for a nice relaxing break from a day of writing code.

This won't be too useful for other projects until there's proper documentation on how to use it. Which should go in the README file.

There is a danger here of overspecifying, or even just jumping too quickly into public use, since the module APIs are subject to change and expansion right now. But release early, release often. As long as people are aware of how shaky the ground is, we should be fine.

This basically involves changing the way that fullscreen mode works - using a class instead of a CSS include. However, fullscreen support will still be a separate CSS file so that downstream consumers can omit fullscreen capability entirely, by serving neither the module nor the CSS.

This lets us condense demo*.html down into a single index.html file, which we can use in a gh-pages branch.

This would be a large project, and part of broco that would be considered optional. However, vi mode is cool, and I'm sure there are people who take advantage of emacs.

What we really need is a part of the "prefs" structure devoted to keyboard shortcut handling and, in the case of vi, doing so statefully.

This is really useful for quickly repeating previous commands, with variations as necessary.

Add the ability to have multiple broco tabs, sharing data but with distinct output logs. The primary use case is being able to grep through another tab's logs, without dirtying them up further.

The tricky part here is the protocol - tab completing a module name is easy, interacting with a module to provide tool-specific tab completion (in a way that third-parties will enjoy supporting) is another matter entirely.