From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id +IGIG5GztWIvZAAAbAwnHQ (envelope-from ) for ; Fri, 24 Jun 2022 14:52:33 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id MKVQG5GztWIRDgEAauVa8A (envelope-from ) for ; Fri, 24 Jun 2022 14:52:33 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id DE9E9196C6 for ; Fri, 24 Jun 2022 14:52:32 +0200 (CEST) Received: from localhost ([::1]:39758 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4inX-0005yN-G4 for larch@yhetil.org; Fri, 24 Jun 2022 08:52:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55516) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4imd-0005vM-3Q for emacs-orgmode@gnu.org; Fri, 24 Jun 2022 08:51:35 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59222) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4imb-0004pf-E5 for emacs-orgmode@gnu.org; Fri, 24 Jun 2022 08:51:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=To:Subject:Date:From:In-Reply-To:References: MIME-Version; bh=AYQU53FoD694P+AKFe47FOJOaOk+HS0FXUrE7lCZRtI=; b=k4eQM990ShBp oSLORtROiGtC1y9ol3Ya2V0Pb31sAKhqphml/7PzGxj79pn4KxnHy2Ote1bFZA6I/Sp/jflYFH8Bf /M/wiARRIXWmgqCxhPM7+AdcGPvFPxBuUDgVM14yWIc3rzTwkMs4yJ7HyxIUBIsS8p9IOQbB3lAWs MmdvPMayW8fc2vti2MDj9vIdyEkKSKjgJLR+6RobWR/uPuof+eu0LJve2Kl8pQbD6j8ZZQ0+WZMgR gjaLLDm7957wIv9xSQbknvdQMCFB5fVyvWysZhWvRqcoOH0lEl4ZPjWBBMXvzDI4AqIkgsKe2zIjw B6QCHgEthrQXCDucbAYySQ==; Received: from mail-yw1-f180.google.com ([209.85.128.180]:41972) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o4imb-0001af-0z for emacs-orgmode@gnu.org; Fri, 24 Jun 2022 08:51:33 -0400 Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-31780ad7535so23636317b3.8 for ; Fri, 24 Jun 2022 05:51:33 -0700 (PDT) X-Gm-Message-State: AJIora+KgR2Zkt67vETu+dIxmV3JbCxVz1NcJszJI8/tvicqw9QrZrJq 7me2H27TlxR49u06+y3PvtEBbLBWDAUwmVy73eQ= X-Google-Smtp-Source: AGRyM1uWwqmnP1sJOMl/JdJFD/kdiVPRGmD8bXJoupKuy61KvInjEdkQMXB96WRxEeysr7FzJZP7d2YUkDwlohSwGSE= X-Received: by 2002:a81:ac07:0:b0:317:dd64:2ad5 with SMTP id k7-20020a81ac07000000b00317dd642ad5mr17201122ywh.105.1656075092488; Fri, 24 Jun 2022 05:51:32 -0700 (PDT) MIME-Version: 1.0 References: <813D3F10-3E3C-497F-9FD8-FE0DA13C2970@gmail.com> <7befc1b0378c484ad18e1d8103889ea7@libre.brussels> In-Reply-To: <7befc1b0378c484ad18e1d8103889ea7@libre.brussels> From: Robert Weiner Date: Fri, 24 Jun 2022 08:51:06 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Org and Hyperbole To: indieterminacy Cc: Samuel Wales , emacs-org list Content-Type: multipart/alternative; boundary="0000000000009bf69505e231072b" X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rswgnu@gmail.com Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1656075153; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=AYQU53FoD694P+AKFe47FOJOaOk+HS0FXUrE7lCZRtI=; b=N62EAjfeOszjmcntd/vwx2ebAvvMzfIkUi91Mq2vZ2bqAgPtpjbGi+R2Lq3qkml4ZQTj5S c8230z6BHLANinVUXxSlvF/7OqIPckOl7Pj54mpGiLFnzPLfUQrlZ9Sm/9t/AVTcG+Nfiw y1OhM4v28fiyqU5BMS2Hh24nBJwGPnONTAOpyRkRk05DGC+Vy81JgrDoVxu7l2neGW643H +VdHbi1muqGNXisLyUXCCf/XLGGr/sauI8vdbDgbkbfhOkBQdTwA47Qi8z50gOjP9ksuIW LE1K0/fv01XuC3m5PaZtpqQWKnZ4W2eeLwaOJeco4V6eFdbm5I1X4dE+e19YYw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1656075153; a=rsa-sha256; cv=none; b=lmNHaEz7qWgE2XBE8Tpp9rHQEH7wrxxU/8U6NgcnBSMfl16kNr0DH7cyUKyVS0oZYJUpYZ hLYiBaSCovdoC8gS0a3kNOCJfBCM0NdnrHJjDBTYxcOkeeHcASa73CRZl5gq9DLvVAkabF XAdVmU/6xHKh0hGgExAWLRsZFwe5h4146Q/G9SzGSd8Q1fAiHNODdo4jdgpse9er5e+hww UynXs0Uk+1x/NnDYtSBn+J0LBZnGtEc4536d4JbQwt5x2/Rk+q4/ietbInkn/UhkUS8d1P AP18zwRqwqMvUOPqsUlCz1urAYUAjskKWL57xDsS9TkGTzhLAh5o5vVMWddXHQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=k4eQM990; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -6.96 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=k4eQM990; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: DE9E9196C6 X-Spam-Score: -6.96 X-Migadu-Scanner: scn0.migadu.com X-TUID: 5SY2snjBy42t --0000000000009bf69505e231072b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > Hi Robert, > > On 24-06-2022 07:34, Robert Weiner wrote: > > Hi Samuel: > > > >> On Jun 24, 2022, at 12:32 AM, Samuel Wales > >> wrote: > >> > >> =EF=BB=BFhi 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. > > > > =E2=80=94 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 > --0000000000009bf69505e231072b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jonathan:

Yes, the backlink issue is one of the reas= ons we have not focused on moving kcells=C2=A0with permanent hyperlink anch= ors from one file to another.=C2=A0 We generally feel that the context of k= cells within an outline is important and thus should stay as a unit.=C2=A0 = You obviously can and do link to any kcell from outside the outline by comb= ining 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 suppo= rt 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, 20= 22 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:
>>
>> =EF=BB=BFhi robert, welcome to the org list and thanks for your of= fer.
>>
>> for starters, does hyperbole have any concept of links that are: >>
>> - unbreakable [like org-id]
>
> This one is not so simple to answer.=C2=A0 Hyperbole only uses
> perma-hyperlink anchors in its Koutliner format.=C2=A0 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<= br> > to move back through followed node paths.=C2=A0 We have started thinki= ng
> about this need recently.
>
> =E2=80=94 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' ty= pe
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/m= ain/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/~indieterminac= y/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/1q20h= qh_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
--0000000000009bf69505e231072b--