Doesn't seem to respect broken-links option

[dcherian]

I have #+OPTIONS: broken-links:mark in my header but ox-ipynb doesn't seem to respect that.

I get an error saying "link xxx could not be resolved"

[jkitchin]

can you post a small example that fails?

[dcherian]

#+TITLE: asdsa
#+AUTHOR: O.R.G

#+OPTIONS: broken-links:mark

* a
This is a link that works: [[a]]
This is a link that fails: [[abc]]

HTML export (for example) yields

<p>
This is a link that works: <a href="#org856f6d2">1</a>
This is a link that fails: [BROKEN LINK: abc]
</p>

[dcherian]

This is org-9.0.9

[jkitchin]

I can confirm that. The problem here is in ox-ipynb-export-markdown-cell, specifically in

(org-export-string-as s 'md t '(:with-toc nil :with-tags nil))

you can get what you want with (setq org-export-with-broken-links 'mark).

We could make that a default by adding :with-broken-links mark to the export above. I am not sure how to get the value from an OPTIONS line though during the export.

[dcherian]

Shouldn't the export infrastructure populate the options plist with the values?

(i don't know anything about this, but a quick reading of the code for HTML export shows options being passed around)

[jkitchin]

It does pass them around as info, but this isn't like a regular exporter; the cells are individually constructed and are somewhat isolated. In the example in this repo, internal links render but point to the wrong thing in my experience. E.g. if you use an ID to link to, you get a link, but it does not point to the right anchor. In your case, [[a]] doesn't seem to render to anything in the notebook for some reason.

There isn't an easy way to get internal links to work without multiple passes over the cells to resolve them, or a rewrite of how the md is generated. I think you might have to generate the whole md document, and then split it into cells at the right places to insert the code cells. That actually sounds simpler than what I did in this repo so far! Unfortunately, I won't have time to try that for a few months probably. I am starting a sabbatical tomorrow and it will be a few weeks until I get settled at least!

[methuselah-0]

I have similar issue with #+OPTIONS: ^:{} not being interpreted. It would be great to have at least some of the more commonly used options interpreted by an ad-hoc solution (unless it's possible to somehow use the regular export infrastructure).

[jkitchin]

Sometimes you can get the regular export infrastructure to work, e.g. by exporting your org file to org, and then exporting to ipynb. However, you can lose some features this way too, eg #+IPYNB_* keywords will be gone in the new export. I can't remember if there are some other losses. there was a time when we did do an org to org export but I don't think that is done now. I don't have time to work on this now, but would certainly consider pull requests. I don't have a sense for how easy it would be to get this generally working.