Page names with "." (again)

Ideas
1

Once upon a time, when I was young and naive, I assumed the only thing you'd ever want to keep in your SilverBullet is markdown files. So, I decided: names == file path + ".md".

Simple enough!

But then came the urge to also put images in notes, and to embed them. Initially this was still fine, you'd use ![alt](picture.jpg) and life was fine, there was no ambiguety here, really, you'd never want to include a page as an image.

Then came transclusions: ![[something]]. Now things started to get really tricky. Was something always a page, or could it also be a document (non-page file)? For something we could still assume it's a page, but what about something.else? Well, now we assume it's a document, so — tough cookies.

As of a few weeks ago, we now have SilverBullet+, a desktop app. Now that it's here, I realized that SB is actually by far nicest tool to open any set of markdown files. And it the current AI age, markdown is dominating. A lot of us are (I am anyway) spending a lot of time looking at or reviewing and editing .md files now. This is a great opportunity for SB I think, but it does mean that SilverBullet needs to be able to play nicely with content coming from "foreign" tools, that don't necessarily like to play by SilverBullet "no dots in the name" rules.

Case in point: I have a folder with files with names like something.template.md and I cannot open them in SilverBullet :frowning:

So, how to resolve this? The best idea I've been able to come up with is this:

If a name contains a . it is assumed to be a page name unless it the suffix of a whitelist of file extensions. This whitelist of file extensions would be configurable via config, but would default to things like jpg, jpeg, png, pdf, excalidraw, mov, mpeg etc.

So [[my.template]] would resolve to my.template.md unless template is in this file extension whitelist, and my.jpg would resolve to the my.jpg document.

Thoughts? Other ideas?

2

That does seem like a sensible approach. As linking to files of which silverbullet cannot handle the extension / format, doesn't make much sense. Maybe connect it to which extension has a plugin registration?

Although it is ugly if it is an extension that silverbullet does not know about. Maybe some other type of diagram like C4, plantuml, or some example code example_script.py. In that case silverbullet would be happy to create a markdown file at the location when you try the link...

Let's think of some alternatives:

(option 2) If a wiki link does not have a . then add the .md. For a file like 'my.template.md', it requires writing out the [[my.template.md]]. Probably won't work out of the box with markdown created in other tools, but I think most tools do handle if the link contains the '.md' extension. So would require rewriting, but hopefully once that is done it works in both tools.

(option 3) For max compatibility of notes written in other tools: For links in the page, check if the file exists and if not check if the file with the added .md exists. If I then have a 'my.jpg.md' that I use to describe my jpeg file, then the link 'my.jpg' would still work. And if there was an existing "CHANGELOG" which typically is without the 'md' extension, you could also transclude that with ![[CHANGELOG]]. If neither file currently exists, maybe assume it is a markdown file when someone clicks on the link? Not sure what transclusion does when the file doesn't exist, maybe show error message that neither exists...

None of the options is perfect. I have a slight preference for option 2, as it seems a bit more easy to keep consistent.

3

What if the algorithm was, to resolve [[something.with.dots]], it will first see if there is an exact match file with name something.with.dots, if yes, use that. If no, find all the files that start with something.with.dots.and that dont have any dots after something.with.dots., if that list has only one element, use that, else, error and ask the user to be more specific and use [[something.with.dots.png]] or [[something.with.dots.md]].

This does mean that if you introduce another file in future that also starts with something.with.dots you'd now need to fix all the links.

4

Yes, I prefer a solution that is predictable with simple rules, and not have meaning change depending on whether a file happens to exist or not.

5

My gut says this is a bad idea. It probably will work, but generally I think we should get all the code to conform to the current rules before changing the rules.

6

I am a little confused and maybe am misunderstanding something here.

Let me think out loud and you point to where I am wrong.

[[Wikilinks]] are not part of markdown spec. It is sb-specific stuff. So we can treat it as such and only allow .md files' names there as this is the way to store page names here (with any number of dots and extension-like or url-like parts).

And if we want to link to some asset file (like .jpg or .pdf), we can use some other notation. Like here.

All this doesn't prevent sb from being a markdown viewer.