Replit’s markdown preview doesn’t properly resolve links that contains spaces in filepaths if those files are local to the workspace.
Spaces in filepaths should not affect link behavior in MD preview.
Links to URLs that contain spaces do not work. In particular, I just want to be able to reference another file in the workspace.
I have tried using
<> notation (which CommonMark indicates should be supported for any minimum MD implementation). File can’t be found.
I have tried using
%20 - file can’t be found.
I have tried using just spaces (Markdown just converts all spaces to
%20 anyway. I suspect this may be part of the problem, see the attached image for the error message.)
Steps to reproduce:
Create a file with any space in the full filepath (can be in the filename or a parent directory).
Attempt to link to that location in a Markdown file.
I’ve tested this with images, videos, Excalidraw files and other Markdown files. It appears that all paths are being formatted as URLs even if the referenced location isn’t remote to the workspace.
Can you also try these:
(is not) OK,
("is not") OK,
(is\ not) OK.
Grabbed from SO:
I appreciate the link, but this is not the problem. These don’t work in Replit’s Markdown preview when the target is a local file. That’s the bug.
More explicitly - the bug is that the markdown preview treats all links as URL encoded. That’s fine - if matching against local files compares against the local filepaths also being URL encoded.
I understand. I did more research and tinkering and found the cause of the issue and a workaround. This issue should be fixed.
When you link in a repl markdown such as
[my link](my_file.py), the link becomes something like
https://replit.com/@username/my-project#my_file.py. In addition, special characters in the
my_file.py name (there are none here) are URL encoded because it needs to create the link to the replit file (it’s really just a shortcut to creating the repl file link).
Unfortunately, spaces will make a repl MD link invalid, it will not be formatted (because URLs don’t contain spaces). So file names like
my file.txt cannot easily be linked to. If you try
[link](my%20file.txt), then it encodes the encoding, becoming the link
Consider the MD link
[my link](<my file.txt>). This allows space to be used, but unfortunately it gets double encoded, the space becoming
Now, I was out of options but I tried
[my link](<#my file.txt>) and this somehow works.
I reproduced the problem, the common fixes don’t work, this needs to be fixed.
A workaround is:
[my link](<#my file.txt>)
@NuclearPasta0 - Thanks for poking around at this some more.
It does look like that works for links at least. Unfortunately, it doesn’t seem to work properly for embedded images, videos and drawings, which is primarily what I want to use this for. The reference works, but the embeds don’t function properly.
For example, this does not work:
![Video](<#Path to video with space.mp4>)
The video player shows up in the doc, but isn’t functional.
And for drawings:
![Drawing](<#Path to video with space.draw>)
This generates the following in the preview:
Edit: Incidentally, both of these are the same behavior that is exhibited when you just use the full URL path instead of the filepath.
![video](<#video.mp4>) is equivalent to
That is unfortunate.
The workaround can give a link to a file but the link does not point to an image or video, just to the editor. It is not an “image address”, it does not host images.
A very old thread encountered a similar problem (replit supports it now though).
Though replit MD now supports local images, it probably uses some extra behavior behind the scenes so, no workaround for special file names.
The thread suggested using paste.pics website, then using the absolute url to that, which is of course a way but not very convenient.
This does seem like a more uncommon issue, for most cases one can replace all of the spaces with something a bit more friendly like underscores.
Depends on who you want to be friendly for, I guess. We have some ways to work around this, sure, but I’d really prefer that the behavior is just consistent with what I would expect from other MD renderers.
@learnto-ai Thanks for reporting this.
I was able to reproduce as well and we’ll bring it up with our internal teams for discussion on how to improve this behavior going forward. Thanks again and have a good rest of your day.
You are a rockstar, @SuzyAtReplit! Looking forward to seeing this fixed.
@learnto-ai I have some good news. Our team has released a fix for this issue.
When you have a moment, would you mind testing and verifying? I want to make sure there aren’t any lingering issues.
I’m still not seeing this working properly on my side. Anything I need to do to make sure I have the latest version?
@SuzyAtReplit - I invited you to a repl that demonstrates the exact issue that I’m seeing. Small example with just a couple of embedded excalidraw files. The same behavior exists with images, videos, etc. Of course, feel free to disregard if that’s not helpful.
Thank you for this example! Let me get some clarification from our developer on what was fixed and if we missed anything.
@learnto-ai Okay, now your example Repl is looking better! Does all look good to you or do you have any other uses cases we may have missed?
Looks like this fixed it! Awesome!
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.