From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id EB7wNk/dQWOv/AAAbAwnHQ (envelope-from ) for ; Sat, 08 Oct 2022 22:27:59 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id YEsJN0/dQWMvJQAA9RJhRA (envelope-from ) for ; Sat, 08 Oct 2022 22:27:59 +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 5D1AB4701C for ; Sat, 8 Oct 2022 22:27:59 +0200 (CEST) Received: from localhost ([::1]:47828 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ohGQQ-0001tl-4W for larch@yhetil.org; Sat, 08 Oct 2022 16:27:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58018) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohGPO-0001tW-6u for emacs-orgmode@gnu.org; Sat, 08 Oct 2022 16:26:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51784) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohGPN-0002P5-VT for emacs-orgmode@gnu.org; Sat, 08 Oct 2022 16:26:53 -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=Sm1Kk+nQPG1NPMa7RkBGVir/I0xUsJCTWkvsGTAeJlU=; b=dy1x4bcI/76b i5c1FjbQ31oXZ9R47MozdgwFsx3dKKINeCefyGr+A4L7oYurOt6CZPA95XkogO7bFyfH2j6zPvYcq uGXiGgbXuvUqKGFzcYqrH0GeoY7Geq+qIBVHbDujlx616RwXkTRdzq/kQNAxToo8VNZkMoqSI6IwI kCwtdWZCji5cN5HF7tZ/iMvXauMaVK/cmLlvUpnJYFJzNXT0LR6MB+mzT0Wd0NziOwY7K4ZqcjFOr dXCmeqrEi50Ch4Ptm7FI2TS2FsclWDgHLNyhxUlsfE8j/p3TKGDKtG+CZF9HEB2ptPqd4WVmAATSG N10d1hh1mOzcenmjcweKkw==; Received: from mail-vs1-f54.google.com ([209.85.217.54]:33526) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ohGPN-0001FN-Nb for emacs-orgmode@gnu.org; Sat, 08 Oct 2022 16:26:53 -0400 Received: by mail-vs1-f54.google.com with SMTP id k6so5890412vsp.0 for ; Sat, 08 Oct 2022 13:26:53 -0700 (PDT) X-Gm-Message-State: ACrzQf3SxxEYzZ03FlNF+c06pXq5IRwA7hkegvxE7WyjcHDpH62uTEtK icNmuuApEMEf4T0JLYemkrl6VFB1cH+1nMqC9fE= X-Google-Smtp-Source: AMsMyM53SrKjEGzgb4K6uJ3Y0uwb+DLXDTungOD7qvwDE9mvH+JgO4OJhVHYCaXHeSSAPx9LCFlPuFvx/2BCniSvx7E= X-Received: by 2002:a05:6102:3570:b0:3a6:f937:f110 with SMTP id bh16-20020a056102357000b003a6f937f110mr6131655vsb.22.1665260813232; Sat, 08 Oct 2022 13:26:53 -0700 (PDT) MIME-Version: 1.0 References: <813D3F10-3E3C-497F-9FD8-FE0DA13C2970@gmail.com> <7befc1b0378c484ad18e1d8103889ea7@libre.brussels> In-Reply-To: From: Robert Weiner Date: Sat, 8 Oct 2022 16:26:26 -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="0000000000003b32df05ea8bbfb9" 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-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1665260879; 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=Sm1Kk+nQPG1NPMa7RkBGVir/I0xUsJCTWkvsGTAeJlU=; b=mzedjT4qbidlPi0MKiXZ6n7eZEb54KhDE2XNodMyrxDbuDOxk1hK6Eor/nv7BLUjryBNe0 GNtv00dDAjdxTvrHNJwJgby9cQRhn06nxqY3/S9zrDExTtlDxhLesCIr1qYRoCjcUSzap+ 8UBDDYuDb9dasIYEIejPRhMe6GDL6IBhLJE9R1fbzNy82Ew4IcGAqzFgCcTHNWe4PNpORL ZpcBw6WWnYTGK32kDUoZk1Pc64MNstskkzATRkMnl7hgslsfAXwVxICYimV9V9cpSz+4RX uD+IuydK6c7z8UJpYcuI0R0opp4padatFdaLMvTZyTZ5kKoPpNbgLDpLj4pXng== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1665260879; a=rsa-sha256; cv=none; b=EHc0O445LcsS/2OPzPDaScCT31ham5EPRvjtTfAsFW0g9zKXMHI7dCrY8M+65+xAOaFj7K mJWRtMxj8KQJQJKspNoJUObRC+PzMf2RMQDoQAeJa0nyS7WPShl4GdPExl7eM+LrB6pubt bPMoSahj2iCf750X3Zg+wRsUMwuSepJA9sAV19wN2Po9AoZMWvW/eAQDkD78SsXOUSmNFx iVUnEHArZk+BfR4pwyObFePTY1UTKL3p+IkBH0HWaR1AmHfc9Ei/bcYYzpAt/3/IgANVhz WSM+QsKetihPku0bqaNM7Ep0qLc37Nciu36vhthFG6ebiOw3GCcoFfntGkhc4Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=dy1x4bcI; 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: -3.58 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=dy1x4bcI; 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: 5D1AB4701C X-Spam-Score: -3.58 X-Migadu-Scanner: scn1.migadu.com X-TUID: D9lv71L0XFhf --0000000000003b32df05ea8bbfb9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jonathan: I and I think others would love to understand what you are trying to achieve. I get that you want to use the Koutline format with external systems like GemText and the TXR parser generator/Lisp language but I would rather understand the purpose of what you are trying to build (problem(s) to solve) and what you can't do with the Koutliner as it now stands that you would like to do. Try to explain it without referencing any particular technologies, as I can't follow many of the things you write because of a lack of context. Thanks, -- rsw On Fri, Jun 24, 2022 at 8:51 AM Robert Weiner wrote: > 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 importa= nt > and thus should stay as a unit. You obviously can and do link to any kce= ll > 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 buffer= s > 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/mai= n/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 >> > --0000000000003b32df05ea8bbfb9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jonathan:

I and I think others woul= d love to understand what you are trying to achieve.=C2=A0 I get that you w= ant to use the Koutline format with external systems like GemText and the T= XR parser generator/Lisp language but I would rather understand the purpose= of what you are trying to build (problem(s) to solve) and what you can'= ;t do with the Koutliner as it now stands that you would like to do.=C2=A0 = Try to explain it without referencing any particular technologies, as I can= 't follow many of the things you write because of a lack of context.
<= br>
Thanks,

-- rsw

On Fri, Jun 24, 2022 at 8:51 AM Robert We= iner <rsw@gnu.org> wrote:
Hi Jonathan:

Yes, the backlink issue is one of the reasons we have not focus= ed on moving kcells=C2=A0with permanent hyperlink anchors from one file to = another.=C2=A0 We generally feel that the context of kcells within an outli= ne 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 combining the file path w= ith the cell's permanent id and thus could have a grep-like search acro= ss 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 t= his is a future use case to consider.

-- = rsw

On Fri, J= un 24, 2022 at 6:55 AM indieterminacy <indieterminacy@libre.brussels>= wrote:
Hi Rober= t,

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
--0000000000003b32df05ea8bbfb9--