[201_94]: Fix slink bare URL redirect without HTTPS (#2324)

[divyansharma001]

Problem

When typing slink and entering a bare domain like liiistem.cn (without https://), Ctrl+clicking the link does nothing. The URL is treated as a local file path because go-to-url routes it through default-root-handler, which fails to find any local file.

Fix

Added detection of bare domain-like URLs in go-to-url (TeXmacs/progs/link/link-navigate.scm). When the input string:

• Has no protocol prefix (http://, https://, etc.)
• Is not a file path (doesn't start with /, ., ~, #)
• Contains a dot (.)
• Does not exist as a local file

...then https:// is automatically prepended before URL routing.

How to test

1. Type slink, press Enter, enter liiistem.cn
2. Ctrl+click the rendered link
3. Browser should open https://liiistem.cn

Also verify these still work correctly:

• https://liiistem.cn — unchanged, opens normally
• www.google.com — opens as https://www.google.com
• ./local-file.tm — not affected (relative path)

Closes #2324

[Copilot]

Pull request overview

This PR fixes \slink navigation when users enter a bare domain (no https:// prefix) by detecting domain-like strings in go-to-url and automatically prepending https:// so links open in the browser rather than being treated as local file paths.

Changes:

• Add string heuristics in go-to-url to detect “bare domain” inputs and prepend https://.
• Introduce helper predicates url-string-has-protocol? and url-string-looks-like-web?.
• Add a developer note (devel/201_94.md) documenting behavior and manual testing steps.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
devel/201_94.md	Adds dev log + manual test steps for the slink bare-domain redirect fix.
TeXmacs/progs/link/link-navigate.scm	Implements bare-domain detection and https:// prepending in go-to-url.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

url-string-has-protocol? only recognizes a small hard-coded set of schemes (http/https/ftp/file/tmfs/blank). The codebase already has URLs with other rooted protocols (e.g. zotero:// in TeXmacs/progs/network/url-test.scm), and those would be treated as “no protocol” here. If such a URL contains a dot anywhere (host/path/query), go-to-url may incorrectly prepend https:// and break the link. Consider detecting protocols generically (e.g., treat any string that contains "://" before any whitespace as having a protocol, or parse with system->url and check (url-rooted? ...)) instead of enumerating schemes.

Suggested change

	(or (string-starts? s "http://")
	(string-starts? s "https://")
	(string-starts? s "ftp://")
	(string-starts? s "file://")
	(string-starts? s "tmfs://")
	(string-starts? s "blank://")))
	(with i (string-index s #\:)
	(and i
	(>= (- (string-length s) i) 3)
	(char=? (string-ref s (+ i 1)) #\/)
	(char=? (string-ref s (+ i 2)) #\/))))

[Copilot]

url-string-looks-like-web? can misclassify Windows paths (e.g. C:\Users\me\file.tm or \\server\share\file.tm) as web URLs when the target file does not exist, because these paths don’t start with /, ., ~, or # and may contain dots. In that case TeXmacs would try to open https://C:\..., which is clearly unintended. Consider explicitly excluding Windows absolute/UNC path forms (or using url-drive-letter / a dedicated “looks-like-file-path?” predicate) rather than relying on url-exists? alone.

[Copilot]

There’s no automated regression test covering the new bare-domain detection / https:// prepending logic (e.g. liiistem.cn should be rewritten, ./local-file.tm should not, Windows paths should not, and already-rooted URLs should not). Since the repo has Scheme regression tests under TeXmacs/tests/, it would be good to add a small test file (or extend an existing group) to lock in this behavior and prevent future regressions.

[wumoin]

There are still many issues. For example, if the link points to a file, it may be incorrectly identified as a web URL.