~indieterminacy/1q20hqh_kq-owo_interpreting_gemtext-glint

See the api: hqh_parsing.kotl

#Example

gawk -f hqh_parsing.awk twt-xw_icebreaker-space.gmi > uw_twt-xw_output_icebreaker-space.gmi

#Policy

Im electing to use an awk parser to do an earlier pass and divide (gemtext and koutliner) documents into chunks (according to headers or blocks). https://git.sr.ht/~indieterminacy/1q20hqh_kq-owo_interpreting_gemtext-glint

From the chunks hashes shall be made, including of:

canonical s-exps
datalisps (formed from Qiuynonical)
third party formats (orgmode; latex; scribillo

These chunks and interpretations shall form individual files, to be cross referenced using the token database, ldif

The value of having an interpreter for representing Qiuy annotations will be significant. This is because that database will be able to grep whitespace delimeters in used within queries for annotations or annotations. Otherwise, only full capture when using '-' or '_' delimeters.

I feel that Ive concluded what I want my interpreting output should be.

It should be Gemtext friendly but an inversion of the considered syntaxes:

> # @nw-ue_mq-te_sequence_any-header@;; iw-rw_heh-owo_found-during_parsing-involving-awk-too-glint 
=> ./mq-tet_raw/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@/\*#/@;; tet_mq-te_aggregate_body-with-header
=> ./mq-tet_raw/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@ \*/@;; tet_mq-te_constituent_body-without-header
=> ./mq-te_canonical-s-exp/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@/\*#/@;; tet_mq-te_aggregate_body-with-header
=> ./mq-te_canonical-s-exp/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@ \*/@;; tet_mq-te_constituent_body-without-header
@(maybe)
@(cases)
=> ./mq-mqm_qiuynonical/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@/\*#/@;; tet_mq-te_aggregate_body-with-header
=> ./mq-mqm_qiuynonical/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@ \*/@;; tet_mq-te_constituent_body-without-header
@(or)
=> ./mq-tet_raw/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@/\*##/@;; tet_mq-te_aggregate_body-with-header
=> ./mq-tet_raw/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@ \*/@;; tet_mq-te_constituent_body-without-header
=> ./mq-te_canonical-s-exp/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@/\*##/@;; tet_mq-te_aggregate_body-with-header
=> ./mq-te_canonical-s-exp/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@ \*/@;; tet_mq-te_constituent_body-without-header
=> ./mq-mqm_qiuynonical/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@/\*##/@;; tet_mq-te_aggregate_body-with-header
=> ./mq-mqm_qiuynonical/@xw-tet_mq-xw_w-te_hash-value-in-canonical-form@(os-2)@ \*/@;; tet_mq-te_constituent_body-without-header
@(maybe)
...
@(end)
@(or)
...
@(end)
@(end)

As a consequence all the content is chunked up into pieces; hashed; deduplicated; and arranged into a tree of hashes for each document. Given the different hashing is outputted these items as files they work implicitly with contextual tools such as emacs-hyperbole: for whatever required action or enquiry. Its a simple for-loop to identify and act upon the appropriate hashes in-relation-to a document or requirement. Im going to run these subfolders individually or collectively through the token database, ldif.

See Qiuynonical concerning the usage of TXR for generating sophisticated interpreters of Gemtext and Koutliner; https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_qiuynonical

Orgmode and equivalent Outline docments can similarly be chunked

Ill get around to incorporating the symlinking tool, stow - once Im satisfied. Similarly having and api approach as a Gemini CMS: combining the aforementioned into a queryable ecosystem of Gemtext compatible documents.

One win is that chunking and deduplication occurs prior to the more intense interpreter, qiuynonical - which should improve some scalability issues.

It shall be nice seeing how this interplay will function with respect to Git, given that commit messages can store metadata representative of state and environment. I reckon workflows which involve editing buffer representations of these hashes and creating files-like diff, would be interesting. The TXR description above is acceptable for outputting within a Gemtext document and then contatenating and further templating when compiled (by TXR) and outputted as an outputted document.