"Ben H. W." via "General discussions about Org-mode." <[email protected]> writes:
Confirmed > > To delimit the block, `org-babel-tangle-jump-to-org’ searches backward for the > enclosing `[[file:...][Name:N]]' comment. Its inner check discards the result > of the “… ends here” search and sets END unconditionally: > > ┌──── > │ (save-excursion > │ (save-match-data > │ (re-search-forward > │ (concat " " (regexp-quote block-name) " ends here") nil t) > │ (setq end (line-beginning-position)))) ; runs even when the search > fails > └──── > > So the in-body link `[[file:foo.org][foo]]' is accepted as the block > delimiter, > END collapses onto that line, and the subsequent guard > > (unless (and start (< start mid) (< mid end)) > (error “Not in tangled code”)) > > fails because mid is no longer < end. I think the problem isn't to do with the end marker so much, as that if the regex search fails, that block of code should return nil. But instead, as you point out the (setq end ...) line is executed even when the search fails, and returns non-nil. What should happen is that the regex search should return nil, and the search is widened (in the surrounding (while...)). In any event, in whichever interpretation of the problem, the fix addresses it. > Suggested fix > ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― > > Only set END when the “ends here” marker is actually found, so a stray in-body > link is rejected and the backward search widens to the real delimiter: > > ┌──── > │ (and (re-search-forward > │ (concat " " (regexp-quote block-name) " ends here") nil t) > │ (setq end (line-beginning-position))) > └──── > > With this change the backward search skips the in-body link and detangle/sync > round-trips correctly. Should this be submitted as a patch, or is it a small enough change not to need one here? If a patch is needed, Ben do you want to submit it? If not, I'll do it. Cheers, Paul.
