Re: Org and Hyperbole

[indieterminacy <indieterminacy@libre.brussels>]

Hi Robert,

On 24-06-2022 07:34, Robert Weiner wrote:
> Hi Samuel:
> 
>> On Jun 24, 2022, at 12:32 AM, Samuel Wales <samologist@gmail.com> 
>> wrote:
>> 
>> hi robert, welcome to the org list and thanks for your offer.
>> 
>> for starters, does hyperbole have any concept of links that are:
>> 
>> - unbreakable [like org-id]
> 
> This one is not so simple to answer.  Hyperbole only uses
> perma-hyperlink anchors in its Koutliner format.  But it would be
> straightforward to add a UUID-type id for use elsewhere.
>> 
>> - bidirectional [link a goes to link b; link b goes to link a], or,
>> reversible via command to say "what links here?" [by any mechanism.
>> if desired, please see "id markers" concept on this list for
>> unbreakable bidirectional links and more stuff]
> 
> Hyperbole does not have bi-directional links, only a history function
> to move back through followed node paths.  We have started thinking
> about this need recently.
> 
> — rsw
Improvements to the backend of Koutliner would be useful, especially as 
(if I recall from the documentation) the API aspects are not so clearly 
defined.

Bi-directionality would be a priority IMHO, especially to facilitate the 
updating of all links targeting a specific block should it move.

At the moment, each link self updates when it identifies a reference 
which needs to be updated but that comes across as an expediency (which 
I mitigate with direty look running through links to validate they are 
functional).

It would be great to achieve this with an 'eventual-consistency' type 
way, given that files could come in and out of a system or network.

Similarly, allowing the perma-hyperlink anchors to be transferred would 
really mature the format.

Here are some umble functions I use to facilitate moving blocks into 
other files:
https://git.sr.ht/~indieterminacy/1q20bwb_oq_transferring_emacs/tree/main/item/kqk_kq_blocks_koutliner.el

They at least avoid being descructive, as after moving the block becomes 
a pointer to where the moved block ended up in the other dcoument - but 
it feels like a fudge which could turn some documents into spaghetti.


While Im sure that you are planning on solving these problems within 
eLisp, I should point out that I shall have a Koutliner parser, written 
in TXR (soon to be finalised, Ive had some familial and health 
impedencies recently).

Here is a WIP
https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_glean

And a (rough) example
https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_glean#examples

I do need to add some facets (I suspect the linking for other blocks is 
in a seperate script).
I shall also be integrating the parser with GemText (Orgmode would be 
nice one day too).
https://git.sr.ht/~indieterminacy/1q20hqh_kq_parsing_gemtext/

I do quite like TXR's datalisp format but I havent gotten around to 
finding a way to slurping it up into eLisp. I feel like it should be 
easy to resolve but its not a query which is easy given SEO search.

The way Ill be approaching this interpreter is that it could search the 
aggregate or a journey from one document. Being able to have an overview 
of multiple documents is something I consider to be helpful, given the 
domain of cross-referencing.

and FYI, I will be working on outputting RDF from Koutliner and GemText 
analyses.

-- 
Jonathan McHugh
indieterminacy@libre.brussels