Support multiple source blocks being tangled to one file

[matthew-piziak]

I have an Emacs configuration file written in an literate Org config. It has multiple source blocks all tangling to main.el. Running tanglesync will pull the whole main.el file into the first source block.

Of course this is nontrivial because the block boundaries are erased in the tangled file, but I figured that I should mention the use case.

[mtekman]

I think of this from time to time, but have no idea how to resolve it.

Maybe when the file is opened, it checks the conf file for the contents of each block with the same tangle target, and makes an educated guess which lines it should resolve to?

As you say, it's non-trivial. I would actually say damn near impossible without the link comments that blocks sometimes have.

I thinks for now I will:

• Assign this as a wontfix (unless someone can come up with a solution?)
• Write a disclaimer in the readme

Would that work?

[matthew-piziak]

Could we alter the tangling behavior to delimit blocks in the tangled files? Not ideal, but I'm just spitballing here.

…

On Wed, Jan 15, 2020, 4:37 PM Mehmet Tekman ***@***.***> wrote: I think of this from time to time, but have no idea how to resolve it. Maybe when the file is opened, it checks the conf file for the contents of each block with the same tangle target, and makes an educated guess which lines it should resolve to? As you say, it's non-trivial. I would actually say damn near impossible without the link comments that blocks sometimes have. I thinks for now I will: - Assign this as a wontfix (unless someone can come up with a solution?) - Write a disclaimer in the readme Would that work? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#13?email_source=notifications&email_token=ABT4M2I26QPHW3ALXIQIDVLQ556YVA5CNFSM4KHI7ACKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJB4SAY#issuecomment-574867715>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABT4M2OEK55TEUQQ6YKGYF3Q556YVANCNFSM4KHI7ACA> .

[mtekman]

this is essentially what :comment link does according to the spec though I have not tested this myself.

Hmmm I guess I could adapt org-tanglesync to read these link comments, that could be a win here.

[matthew-piziak]

Good idea!

untangled

#+PROPERTY:header-args :tangle test.el :comments link

* Header

#+SOURCE: first
#+BEGIN_SRC emacs-lisp
(message "alpha")
#+END_SRC

#+BEGIN_SRC emacs-lisp
(message "bravo")
#+END_SRC

tangled

;; [[file:~/log/plot/test.org::first][first]]
(message "alpha")
;; first ends here

;; [[file:~/log/plot/test.org::*Header][Header:2]]
(message "bravo")
;; Header:2 ends here

[mtekman]

So the real trick will be defining functions that:

• Upon saving a file F, made up of B external parts, derived from S source blocks in org file O (where len(S) == len(B)):
  • Locate the external part n for which the cursor is currently within
    • Search line-by-line upwards until a link comment is found
  • Locate the org src block s that defines n in O
    • Either adapt the alist generation function so that it's (O.(F.(s1 s2))), or allow the same F to appear multiple times in the alist. (O.(F F F F))
  • Sync n → s
    • Optionally check :diff status for how to resolve
  • Optionally sync all n in N to s in S
    • Maybe set this is a custom flag, otherwise could be costly

This is not blocked by #12, so if the org framework is used, it would still benefit to set the overlay bounds for each detected block.

Optionally:

• Parses #+SOURCE: blocks
  • Maybe? It could help in making the alist more unique

[matthew-piziak]

Flycheck finally supports buffers without filenames: flycheck/flycheck#1695

Unfortunately it's not yet useful for literate init files, because you would have to fill each source block with require invocations, since none of them know that they are being tangled to one file. That reminded me of tanglesync.

[mtekman]

Its a hard problem 😬

[matthew-piziak]

It certainly looks that way. 😬

[elviejo79]

The :comments link seems to be the common approach.
It is also used in: Entangled
Entangled:

• Is written using Markdown (not org files, but nobody is perfect ;-) )
• supports bidirectional code updates.
• It supports them with comments in the code fragments.

Now the downsides:

• It has lot's of dependencies. (python, node, etc, etc)
• Is not integrated with Emacs :'(

[mtekman]

tanglesync is bidirectional too - if you edit the org src block, it checks for external changes first and if found, asks how you wish to proceed.

As for the :comments link okay I will proceed to implement this under the assumption that people tangling multiple blocks to the same file must be using the comments link method.

I likely will not be able to work on this until September though...