Hello, I only recently became aware of Hyperbole (through Bob's demo video available on Youtube), and came across this thread while googling to find more information about Hyperbole. I feel that some of the questions raised here about Hyperbole sound akin to the story of five blind men feeling the elephant, so I humbly offer my perspective on what I consider to be the key underlying ideas. Forgive me if I'm stating the obvious, and I also don't know whether Hyperbole as currently implemented does exactly all this :-)
I'd like to think of the key idea of Hyperbole as converting text in buffers into *objects* (aka "buttons") by attaching *behavior* to them. The two actions provided by convention could be thought of as akin to the left-click and right-click which one is familiar with in contemporary GUIs, in this case respectively bound to methods for "do (by default)" and "show metadata". Supporting more behaviors/methods/messages for user-invocation is an obvious next idea (if not already so). The above system would be of quite limited composability if it required objects to be defined explicitly -- because most buffers one operates on are generated without awareness of Hyperbole (imagine the pain of everything needing to conform to something like a Hyperbole framework/protocol!). The cleverness behind implicit buttons is that one can opportunistically use common conventions as "schemas" to "parse / deserialize" the contents which make up an object from any buffer (in this case via regexps) and attach corresponding (expected) behaviors to them! Because of the highly structured nature of such data, even if embedded in a stream of plain text, it can typically be parsed correctly without needing explicit type annotations. The behaviors could presumably depend not just the object, but also the active modes, environment variables, etc. Here are a few made-up example use cases (hand-waving over details): 1. I might embed phrases such as "bug:123" in my code / emails / org task management and have behaviors that respectively fetch the bug report / open some URL in a browser / or update the TODO status based on the bug status, as desired. This would help me interface conveniently with a bespoke bug-tracking tool. 2. On encountering Goodreads links in my reading list org file, I could have a behavior to parse the contents of the webpage and extract desired metadata to add to the item properties (or an entry to some org table). 3. Linking by immutable block identifiers (and fast lookup) of course enables a lot of PKM workflows that have recently become popular (with the addition of bidirectional links). Other aspects such as menus generated from button files seem like convenient affordances bolted on to make up the UI of the system. I still need to wrap my mind around these, but I wonder whether there might be opportunities to compose with other ecosystem tools which have pioneered some nice UI ideas eg. transient menus, hydras, interactive selection lists, etc. But that's a discussion for the Hyperbole mailing list. >From a first impression, I'm really impressed, and also surprised that Hyperbole is not more popular. Much gratitude to the contributors for a nifty tool, and a fascinating design perspective. Best regards, Siva http://sivark.me