-
-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow relative URLs in bottom bar #71
Comments
This is a good feature, and should be easy to implement. I've thought about how I want this myself, just never made an issue for it. This will be added, thanks! Likely by v1.6.0. |
Please poke me whenever the commit is made (or you decide what path you want to take towards implementing it, so I can give it a shot in a way that doesn't conflict with how you want the project to work (all variants I can think of would change multiple parts of the project)). |
Basically change these lines to support any path starting with a dot, and use Feel free to take a shot! |
CC - done |
Consider an index.gmi that exposes some subdirectories but not others (e.g a ./hidden link that's not in index.gmi).
(There are many such use-cases, such as leaving the door open to people with the link, or simply not wanting to have a directory exposed in the index, since most viewers will not care about it.)
In the current scenario, as far as I can tell, the only way to navigate to it is to type out the entire current prefix followed by /hidden, but the current path may be long.
It would be nice if one could type
./hidden
in the bottom bar, and (if the current url is a real one) the resolution happens internally.I notice that amfora already has this for link handling (
followLink
), butURL()
specifically wants absolute paths.There's a couple of ways I can think of implementing this, but the calls are kind of all over the place.
Could this feature be added for convenience's sake?
I think a "good enough" heuristic should be if the first character of the bottom bar is "." - this way the method can also take care of handling ".." (but also further, things like "../otherdir").
The text was updated successfully, but these errors were encountered: