Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
Can we please stop linkifying random strings that happen to look like domain names?
Currently, strings that look like some subset of fully qualified domain names are automatically turned into links to the corresponding http://
resource. So, for example, example.com becomes a link to http://example.com, and something.example.com becomes a link to http://something.example.com
, but something.example doesn't become a link even though it technically is just as valid as a domain name. Similarly, something.test doesn't become a link, but something.info does. (.example and .test are both valid, reserved TLDs.)
Short of using code elements, which has other undesirable consequences, there appears to be no way to override this behavior. For example, quoting the .
with a \
doesn't change anything: example\.com
still becomes a link to http://example.com. example.com
in backticks does not become a link.
Can we please stop doing this, or at the very least, add an obvious way to override the behavior without having to resort to code
elements? Markdown already has a syntax for inline links, so I don't see the value of bastardizing things that just happen to look like some subset of FQDNs.
I've seen it multiple times before across Codidact, and just recently, came across Inductance vs frequency on Electrical Engineering where OP happened to write load.Is
instead of load. Is
, and it became a link even though it clearly was never intended as a domain name, let alone as a link.
(Reposting here for visibility) For the time being, there is a relatively simple workaround. It appears that Mark …
3y ago
I agree. This is a great example of over-reaching with trying to be "helpful" automatically. Only links explicitly dec …
3y ago
I have experienced a similar issue in VS Code, and here is an issue report that describes the problem, and proposes a so …
9mo ago
3 answers
I agree. This is a great example of over-reaching with trying to be "helpful" automatically. Only links explicitly declared so by the author should be shown as links. The site otherwise has no business guessing author intent.
If a post author forgets or otherwise doesn't properly declare a link as a link, then that's on them and they will be judged accordingly, not the site.
1 comment thread
(Reposting here for visibility)
For the time being, there is a relatively simple workaround.
It appears that Markdown isn't detected within HTML tags, so you can wrap the URL-like in a span or other tag and it won't turn into a link.
<span>dead.sh</span>
-> dead.sh
<i>dead.sh</i>
-> dead.sh
etc.
0 comment threads
I have experienced a similar issue in VS Code, and here is an issue report that describes the problem, and proposes a solution.
The issue is now, resolved in the current VS Code insider build.
While VS Code & the markdown rendering libraries that it uses are coded with JS, QPixel (Codidact core) uses Ruby. I think that this might be helpful as a reference.
0 comment threads