Hi Jonathan:

Yes, the backlink issue is one of the reasons we have not focused on moving kcells with permanent hyperlink anchors from one file to another.  We generally feel that the context of kcells within an outline is important and thus should stay as a unit.  You obviously can and do link to any kcell from outside the outline by combining the file path with the cell's permanent id and thus could have a grep-like search across any number of Koutlines.

But I agree a cross-file permanent ID structure could be useful and that there are times where you want to move or copy outline structure between files (we already support exporting the text of koutlines to other buffers or to HTML), so this is a future use case to consider.

-- rsw

On Fri, Jun 24, 2022 at 6:55 AM indieterminacy <indieterminacy@libre.brussels> wrote:

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