Ihor Radchenko <yanta...@posteo.net> writes: > No. :result-params is not an actual header argument. It is > implementation detail - parsing :results header arg internally produces > (:results . "all the values concatenated") and _also_ (:result-params > "val 1" "val 2" ...).
Hmm... what is the benefit if they encode the same information? (e.g. :tangle "one two \"three and four\"" vs :tangle-params "one" "two "three and four"). Edit: Oh, I see -- Org parses the action from the `:tangle-params' and Users can extend tangle as much as they want via `:tangle' > > Why can't we just go back to that? > > We can. I did not expect that we would need to go this far into the > rabbit hole. Although, I still think that unifying header argument > parsing is something worth doing, even if I need to implement it myself. Hah, me either. At the same time, it doesn't make sense to have `:tangle-sync' present in one release of Org-mode and then deprecated in the next (after your header rewrite). It would just confuse users. I'm happy to have another go at a unified header approach, I will just need to explore the code base a bit more.