Open matthew-piziak opened 4 years ago
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:
wontfix
(unless someone can come up with a solution?)
Would that work?
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 notifications@github.com 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 https://github.com/mtekman/org-tanglesync.el/issues/13?email_source=notifications&email_token=ABT4M2I26QPHW3ALXIQIDVLQ556YVA5CNFSM4KHI7ACKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJB4SAY#issuecomment-574867715, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABT4M2OEK55TEUQQ6YKGYF3Q556YVANCNFSM4KHI7ACA .
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.
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
So the real trick will be defining functions that:
(O.(F.(s1 s2)))
, or allow the same F
to appear multiple times in the alist. (O.(F F F F))
:diff
status for how to resolveThis 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:
#+SOURCE:
blocks
Flycheck finally supports buffers without filenames: https://github.com/flycheck/flycheck/pull/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
.
Its a hard problem :grimacing:
It certainly looks that way. :grimacing:
The :comments link
seems to be the common approach.
It is also used in: Entangled
Entangled:
Now the downsides:
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...
I have an Emacs configuration file written in an literate Org config. It has multiple source blocks all tangling to
main.el
. Runningtanglesync
will pull the wholemain.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.