telescope-browser / telescope

browser for the small internet
https://telescope-browser.org
ISC License
43 stars 1 forks source link

Feature suggestions: Relative mode #10

Closed zzo38 closed 6 months ago

zzo38 commented 8 months ago

Feature suggestions: Relative URL mode: It will ignore the heuristics described in the documentation and will instead treat user-entered URLs as relative to the current file if no scheme is specified. If it is a command-line argument, then it is relative to the current directory if no scheme is specified.

omar-polo commented 8 months ago

Hello @zzo38, thanks for the feature request!

Does prefixing the URL ./ works? For example, with telescope foo:bar.gmi telescope assumes that the protocol is foo and fails because it can't speak it, but with telescope ./foo:bar.gmi it opens foo:bar.gmi as a file (in the current directory). Similarly for absolute paths.

zzo38 commented 8 months ago

Your example describes the correct behaviour in the existing heuristic mode and in my suggested relative mode (although only if given as a command-line argument), since the URL includes (what has the correct syntax of) a scheme. Similarly, a absolute path (starting with /) which is "relative to the current directory" would have the same behaviour in both modes too. If a scheme is specified (whether or not that scheme is implemented) it would work like it already does.

However, other files (e.g. world.gmi), as well as loading when a document is already loaded (instead of command-line argument), would have different meanings. So, if the current file is gemini://example.org/example.gmi and you type / then you will get gemini://example.org/ but as a command-line argument (or if the current file is any local file) you would get file:/// instead.

If you intend to implement Gempub in future, then the jar: scheme should also be implemented; in this case, if you are currently viewing a Gempub file, then / would refer to the root directory of the ZIP archive, and not the root directory of the entire computer.

(I have modified Firefox to work like I described, and I think it would be helpful in other programs too; I find it much more convenient for my uses, and possibly some other people might prefer this too.)

omar-polo commented 8 months ago

@zzo38 Thanks for the in-depth explanation. There is still one thing that I haven't understood however.

Suppose you're viewing the page gemini://example.org/example.gmi. If then you press > (the default key binding for load-url), then / and press enter, telescope will interpret it as file:///. So I'm not sure if this is the behaviour you'd like or if you prefer the opposite (i.e. loading gemini://example.org).

P.S.: adding support for gempubs is in my todo list. There are a few 'big' things I'd like to implement first, but hopefully i'll get to it :)

zzo38 commented 8 months ago

I would prefer it to load gemini://example.org/ in that case, although maybe it should be a separate command such as load-url-relative (and perhaps load-current-url-relative). (A separate command would not help for command-line arguments though. So, perhaps a separate setting is better.)

For Gempub, some implementations do not use the jar: scheme (although my implementation in Firefox does use it), instead just adding the path directly after the file name. (Another alternative would be to automatically redirect the URL of the ZIP file to the corresponding jar: URL.) This has advantages and disadvantages, so you might or might not consider it.

omar-polo commented 8 months ago

Sorry for the delay, I thought a lot about this. I think your proposed behaviour not only makes sense, but should even be the default.

I think that when loading an url from the command line the current heuristic works fine, but from inside the client using the current url as base as you're proposing makes a lot of sense. Not sure if adding a couple of more commands is needed, I'd just add a toggle in the config (something like load-url-prefer-file which defaults to false.)

omar-polo commented 8 months ago

Actually while implementing it I noticed that this is still a bit rough to use. For example, some users prefer that d.net would be interpreted as gemini://d.net, while if we disable the heuristic entirely (as in the draft I've just committed, please see 4bb6a4fa12277e60cec320dacf7968754b26db7d) would load the file d.net at the current URL.

For now I've committed an option that, if unset with set load-url-use-heuristic = 0 in the config file would disable the heuristics.

But maybe the problem is not in the heuristics used by load-url and just in the fact that telescope doesn't provide any command or easy way to navigate "up" one level in the path hierarchy, nor go to the "home" or "root" directory?

zzo38 commented 8 months ago

I know that some people would prefer the current behaviour which is why I suggested making it an option, like you are doing. (Which way should be the default is a different question of course. Probably, to avoid confusion, making the default what it already did before, is better, so that if you upgrade then it can be a "configuration-safe upgrade".)

I think that it is not necessary to do anything more complicated than simply enabling or disabling it entirely. Since, if I want gemini://d.net then I can just type that in; users who don't like that can enable the heuristic mode instead.

However, I do have one suggestion: This setting should affect command-line arguments too. If you type telescope file.gmi then it should load the file called file.gmi in the current directory (and, if it does not exist, then it is an error). (If you type telescope foo:bar.gmi then it is an error (since it has the format of a absolute URL but not a valid scheme), like it is now, whether or not a file called foo:bar.gmi exists; you can add ./ if necessary, which is how URLs are working anyways.)

omar-polo commented 8 months ago

I know that some people would prefer the current behaviour which is why I suggested making it an option, like you are doing.

At first I thought we could come up with an improved heuristic that would cover both use-cases, but adding a setting seems more robust. I like heuristics when they're predictable and simple, adding too many cases may feel confusing.

This also helped me realize the usefulness of providing out-of-the-box the command up, home and root to ease the navigation.

I think i'll keep the heuristics as default though.

I think that it is not necessary to do anything more complicated than simply enabling or disabling it entirely. Since, if I want gemini://d.net then I can just type that in; users who don't like that can enable the heuristic mode instead.

Yes, fully agree. It could be interesting to think of ways to maybe having telescope automatically fill in "gemini://" (or "gopher://", or ...) using some key-binding. Just wondering.

However, I do have one suggestion: This setting should affect command-line arguments too.

Fully agree here too, it was confusing otherwise. I've changed the meaning of load-url-use-heuristic to cover command-line arguments too. I think that now it should behave as you suggested.

Thanks,

omar-polo commented 6 months ago

Telescope 0.9 is now available and includes the load-url-use-heuristic configuration knob.

One minor improvements is that now that setting is a boolean, so

set load-url-use-heuristic = false

should be used instead of setting it to 0.

I'm going to close this, but feel free to reopen (or file a new issue); thanks :)