Wikilinks to files containing dots (".") not recognized and breaking link directly following

[mrWinston]

My Environment

$ lsb_release -a
LSB Version:	n/a
Distributor ID:	Fedora
Description:	Fedora Linux 42 (Workstation Edition)
Release:	42
Codename:	n/a

$ uname -r
6.15.9-201.fc42.x86_64

$ markdown-oxide --version
markdown-oxide v0.25.8

$ nvim --version
NVIM v0.12.0-dev-1076+g516363e6ba
Build type: RelWithDebInfo
LuaJIT 2.1.1753364724

Problem

Using wikilinks to reference a file that has dots . in its filename (apart from the .md part) results in markdown-oxide not recognizing the link, even though link autocompletion correctly suggests the name of the file.

Take the following folder structure:

/
├── link.to.this.md
├── main.md
└── workingFile.md

Opening main.md and trying to add a wikilink to link.to.this.md results in the following:

Typing [[ opens suggestion to add link to the file:

Selecting link.to.this results in the link not being recognized:

Running lua vim.lsp.buf.hover() when on the link just gives No information available.

Now, when i add a wikilink to workingFile.md, we can see that it correctly identifies the link (Notice how markdown-oxide sets another hl-group for the new link):

And opening the lsp-hover menu on [[workingFile]] opens the preview window as expected:

However, when I move the link to [[workingFile]] after [[link.to.this]], it fails to recognize both links until i add a space somewhere between the links:

[2coffee2crab]

I can partially reproduce this issue:

.
├── file.md
├── file.with.dots.md
└── main.md

Wikilinks for files containing a dot character offer autocomplete and are not flagged as unresolved references. However, "Hover" and "Go to Definition" do not work on them.

I was unable to reproduce the other part of the issue: placing a wikilink to a file with a dot right before a reference to a file without the link had no effect on the latter.

I'll take a look into this.

[2coffee2crab]

Update: I think this behavior is by design.

The regex used to capture references does not recognize any text-segment with more than one '.' character. I think it could be modified, but I'm not sure if that's what the maintainer of the project intended.

@Feel-ix-343, can you chime in? Would accepting references with dots in their filename be a desirable feature?