Support regular Markdown links sans .md (or .org) extension

[kukimik]

Describe the bug
When I create a link of the form [some text](path/to/existing/markdown/file), but without including the .md extension in the path (e.g. try adding [neuron](guide/neuron) to docs/index.md), it is rendered as a broken link, with the backlinks link (in the live server mode) leading to the actual path/to/existing/markdown/file page:

<span class="font-mono align-top text-xs mr-1 tracking-tighter opacity-50 hover:opacity-100">
  <span title="Find notes containing this broken link">
    <span title="Link is broken">
      <s>[neuron](guide/neuron)</s>❌
    </span>
    <a href="guide/neuron" class="text-blue-600 mavenLinkBold hover:underline">
      <em>backlinks</em>
    </a>
  </span>
</span>

Tested at fcac634

To Reproduce

1. Add [neuron](guide/neuron) to docs/index.md.
2. Run bin/run.
3. Go to 127.0.0.1:9010.
4. See how the link is rendered.

Expected behavior
I'd expect [neuron](guide/neuron) to render as an internal link just like [neuron](guide/neuron.md). If this is, for some reason (like , not acceptable, at least something less confusing than the broken link should be rendered.

Screenshots

[srid]

I'd expect [neuron](guide/neuron) to render as an internal link just like [neuron](guide/neuron.md)

Emanote was not designed to support this in the first place. But since Obsidian allows it, I'm okay with Emanote doing it.

[shalzz]

Any update on this? Links are broken when using zk with emanote as well.

[srid]

@shalzz I welcome PRs.

[shalzz]

Hi, @srid I understand you welcome PRs, however I have no experience or knowledge in Haskell.
As a fellow open source developer, I do contribute where I can, however considering that this issue has been open for over an year, it would be great if this is implemented, so that others coming from obsidian and zk can start using emanote as well.
Thanks!

[kukimik]

Just taking notes for someone who wants to tackle this.

Emanote.Renderer.Pandoc.Url.urlResolvingSplice calls Emanote.Model.Link.Rel.parseUnresolvedRelTarget, which in turn uses Emanote.Route.ModelRoute.mkModelRouteFromFilePath to decide that the link is a route to a static file. This is encoded in Emanote.Model.Link.Rel.UnresolvedRelTarget (the URTResource constructor), see Emanote.Route.ModelRoute (the ModelRoute_StaticFile constructor). The other possibilities are to recognize it as a wikilink, a virtual route (like the route to the tags index) or a link to a LML file (the other constructor of Emanote.Route.ModelRoute). Here LML is "lightweight markup language". Unfortunately, none of these options is correct. I think it is rather a HTML route (?): it does not have to point at a .md or .org file - it can also point at a directory, like [this is also broken](guide).

Emanote.Model.Link.Resolve.resolveUnresolvedRelTarget tries to resolve the route to the static file and fails, thus RRTMissing (a constructor of Emanote.Model.Link.Rel.ResolvedRelTarget a) is returned, which carries no information about the original unresolved route.

The backlinks message is displayed in Emanote.Pandoc.Renderer.Url.renderSomeInlineRefWith (take note of the FIXME, which is there mostly because RRTMissing carries no information about the original link):

      pure $ do
        raw <-
          HP.rpInline
            ctx
            ( tooltip
                "Link is broken"
                [ B.Strikeout $ one $ B.Str $ Link.unParseLink origInl
                , B.Str "❌"
                ]
            )
        details <-
          HP.rpInline ctx $
            -- FIXME: This aside is meaningless for non-wikilink links (regular
            -- Markdown links)
            B.Span ("", ["emanote:error:aside"], []) $
              one $
                tooltip "Find notes containing this broken link" $
                  one $
                    B.Link B.nullAttr (one $ B.Emph $ one $ B.Str "backlinks") (url, "")

I see two ways to proceed with this task:

• disallow links of this kind and fix the FIXME (which seems easier);
• allow such links (which probably satisfies more users).

I understand the decision is to try the second way. This needs some thought on how to redesign the described mechanism.