utilities/file_location_listing#37: Markdown Specific Indexing (was Markdown rendering)

Of course, the issue with rendering is that it does potentially present a small security risk: we'll be passing arbitrary content into a parser - whilst the risk of that should be small, it is not 0.

But, to a certain extent, that same risk exists when we pass a HTML file into BeautifulSoup.

Although importing markdown to render is pretty straightforward, if we do this it'll break the markdown tagging support introduced in #10

A lot of my notes (probably the main thing I'm interested in location) use the Obsidian tagging layout:

----
### Tags

#foo #bar #sed
----

If we process the file as if it's HTML we'll lose the ability to (reliably) extract those.

So, I think it might be better, after all, to look at teaching the markdown logic to be able to parse something like

![This is some alt text](http://example.com/foo.jpg)

so that the alt-text and/or the document title gets associated

The feature branch has the basic functionality in now, it can read a markdown file and extract links and image anchors.

I'll play around with it a bit before merging tomorrow

As we've got things cordoned off in a branch anyway, I sort of wonder whether it isn't worth taking the time to also get relative links (as opposed to images) working.

At the moment, if we had the following markdown

# Some doc

----
### Tags

#foo #bar #sed

----

![Intro image](../image.png)

This is a random document mentioning https://www.example.com

It also has a [link](../foo/bar.md) to another doc

We would extract

• The title
• The tags
• The image (and its alt-text)
• A link to https://www.example.com

Which, on reflection is actually a little weird - we haven't actually linked to example.com at all (although some renderers might auto-link it), but we've extracted that and not an actual link.

Although normally (and certainly in my notes) we'd end up finding bar.md during directory traversal, that might not always be the case: if MD is served without directory indexing enabled for example.

So, yeah, I think it's probably worth spending a little bit of time implementing support for that too.

This turned out simpler to do than expected.

I changed the regex used for the image extraction to collect the first char, going from !\[([^\]]+)?\]\(([^\)]+)\) to (.)?\[([^\]]+)?\]\(([^\)]+)\). The code can then check the 1st group to see whether we're processing an image or a link.

Preparing to merge now.