|
From: | indieterminacy |
Subject: | Re: Org and Hyperbole |
Date: | Fri, 24 Jun 2022 12:55:47 +0200 |
Hi Robert, On 24-06-2022 07:34, Robert Weiner wrote:
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.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
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.elThey 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#examplesI 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
[Prev in Thread] | Current Thread | [Next in Thread] |