Re: [ANN] lisp/ob-tangle-sync.el

[Mehmet Tekman <mtekman89@gmail.com>]

Hello!

João Pedro <jpedrodeamorim@gmail.com> writes:

> So, if I understand correctly, =header-reform= is where we're at right
> now and after we're done with this overhauling of the parsing of
> (mutually exclusive) header params, we'll get back to the actual syncing
> logic, which should be mostly done.

Exactly -- reform the headers first (branch: header-reform) and then
add the sync stuff later (branch: ob-tangle-sync-2023).

> Ok I'll start here as I think writing tests could give me some more
> insights on the core problems that still need solution.

Yeah, at least from my side I got really confused with what the expected
actions of some :tangle parameters were. Let me know if you find any
ambiguous cases too.

> 1. So the idea is to continue parsing multi-option header arguments into
>    their separate components, but have a common place to, after parsing
>    it into their components, handle them all in a single place? I mean,
>    what does "handle" mean in this context?

Hah, good question. I think by "handle" I mean three things:

1. Ensure that :tangle remains as the raw string :tangle so that other
  parts of Org can use it without needing to guess if there is a sync
  action in there or not. I quite like Ihor's suggestion:

  Ihor Radchenko <yantar92@posteo.net> writes:
  
  > we need something like
  >
  >   (org-babel-get-header-arg :results params) ; get parsed parameter
  >   (org-babel-get-header-arg :results params 'raw) ; get raw parameter
  >
  > Then, babel backends will not need to know the internal details about
  > :results parameter being represented in its two forms stored as :results
  > and as :result-params.

2. Ensure that :tangle or :tangle-params can merge both filenames and
  sync-actions down the hierarchy.

  In my last email I talk about "process-params" (splitting the filename
  and sync-action) and "merge-params" (resolve hierarchy) as two
  separate entities, where a :tangle header is first "merged" down to a
  header, then "merged" down to a subheading, then "merged" down to a
  source block, and then finally "processed"...

  ... but now that I think about it, it's quite likely that "merge" and
  "process" are interlinked, and we will need something that is aware of
  what the "filename sync-action" pair is, at EVERY level of the
  hierarchy. As in, it processes a header first, then merges it down, then
  processes the next header, and then merges that down, and so forth.

  Right now, process-params and merge-params are two independent code
  blocks, but I think one might need to start calling the other.

3. Do this in such a way that :results can also benefit from this
  process/merge strategy.

> 2. Isn't that the same as the previous point? If we can handle any
>    *-params doesn't that solve the problem of handling mutually
>    exclusive groups?

Yes, it's the same point :-)

Creating a unified *-params handler for mutually exclusive groups would
probably fix all 3 problems. 

> We can just define a pattern of parsing them into individual *-params
> and handling that in a unified manner.

If I'm understanding you correctly, do you mean we leave the normal
header merging and processing alone, and we just treat :tangle-params
and :result-params as their own special group, and handle them
independently of :tangle and :results?

If so, I'm not so sure how easy it is due to my second point above.

> Are these patches also on the branch (apart from the WIP one)?

Yep, those patches as well as the WIP one are also on that branch. My
coding strategy right now is to develop chaotically on =header-reform=
and then do cherry picking/rebasing afterwards.

If you want I can give you push privileges to that branch, or you can
clone it and work in your own tidier manner, or do you prefer working
with email patches?

Best,
Mehmet