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