Skip to content
Jeffrey Benjamin Brown edited this page Jul 17, 2017 · 12 revisions

This is a stream-of-consciousness list of things we would like to see in upcoming releases. Comments and contributions are welcome. They do not need to refer to any specific component or existing feature.

Bury yourself: A VR task manager environment

Attach reminders like "start the dishwasher before going to bed" to items like your bed. Seems more cognitively efficient than a time-based scheduler: No artificial sense of hurry, you'll get there when you get there.

Application shortcuts

When you have a thought, or want to do a search, it takes valuable time to locate Emacs, open it up, and then enter your SmSn command. Let's add OS-specific shortcuts which will allow you to enter the command from anywhere... start typing instantly, without the use of the mouse.

Smarter browser plugin

Similar to the above, the Chrome plugin should, ideally, open Emacs in addition to copying a new note to the clipboard. When you visit a web page which is present in your graph, the plugin should respond in some way.

Faster graph sync

Graph synchronization via Git is a great feature, but it is still pretty slow. I often run SmSn on two computers concurrently, and would like to be able to quickly switch between them. It should be possible to sync a small graph (< 100k notes) in just a few seconds, and it would be nice if the entire process were triggered by a single command.

General-purpose markdown views

Very often, we put information in the graph which is of interest to individuals or groups other than the repository committers. It would be nice to have an HTML-via-Markdown view of any publicly-visible note which is automatically published on the Web, e.g. via a version-controlled wiki. A gist-like service would be useful, as well.

Fast multi-parenting

Often I'll add a note N that is about X, Y and Z. I want it to be a child of all of them. Currently I have to search for X, put N there; search for Y, put N there; etc. I'd like to be able to write something like "(X & Y & Z) / N" and eschew the searching and copying.

Search within vs. outside of a branch

The "comedy" branch for me contains the word "comedy" within it many times. If I want to collect all the comedy notes I've written into it, when I run a search for "comedy", I get a bunch of stuff that's already in there. It would be nice to be able to exclude that.

The reverse: I might have something labeled "goal" under "smsn". I can't search for "smsn AND goal" and find it, because both words aren't in the same note.

Tree views for nested, high-arity relationships

Once we can make relationships members of other relationships, we will want to be able to focus a view on a relationship or family of relationships, and unfold recursively from the focus. I sketched some ways to do that here.

Support conflicting ontologies

Currently, luckily, the authors of the shared graph at synchrony/data-public and synchrony/data-universal trust each other enough to not be too concerned about filing disagreements. At larger scales, though, it will become tricky. If Author1 wants to file X under Y, and Author2 wants it under Z, we might want a way to allow those two preferences to coexist. A reader could subscribe to one or the other, or program a way to view both when they conflict (e.g. "show both but put mine first and with an asterisk indicating another exists"). A reader might even want to invent their own categories of authors, and rank those author categories, so they don't have to handle each author individually. And we will surely want to handle some kinds of relationships differently than others, even if they were authored by the same person.

I haven't tried to flatten these kinds of relationships; it's probably possible, but I am guessing a high-arity, nested relationships system, ala the RSLT, would make it easier to deal with.

Local full-text search

Something that would be powerful: Mixed branch + text search. If you could say "show me (both sides of) any instance of Python within two hops of an instance of the word "file".