target = _blank style defaults for links?
csik opened this issue · comments
I'd like to be able to keep state in domterm if a hyperlink is clicked in browser over network. This could either mean "stowing" a session, or making all links default to some variant of target=_blank by default. The latter is used in some other emulators, and would be completely satisfactory in my use case.
I believe there is no pure CSS way to do this, so it can't be done by modifying settings. I imagine I could add javascript to repl-client.html but I'm not sure this won't have side effects. Is there a best way of approaching this? Thanks.
Unclear what you're asking. I belive clicking on a link is as if target=_blank.
There is a CSS :visited pseudo-class that can be used for styling - though note there are some restrictions for security reasons.
What is your goal here?
Sorry if I was unclear. I am serving DomTerm through a port to the browser. Links are clicking straight through. If at the bash terminal I echo "http://www.example.com" it takes me straight through, no new tab or window. Moreover, if I am reading the DomTerm site correctly, the behavior should be:
"To reduce accidental clicks, these automatic links are only active if you also hold the control key;"
This is not happening.
The behavior is the same in python:
pip3 install rich
/usr/bin/python3 -m rich
At the bottom you'll find several links, these pass immediately to a new page, not a new tab or window.
I tried to test with hcat, but this just freezes when invoked on an html file, easy or complex. imgcat works fine.
Did this make sense?
"At the bottom you'll find several links, these pass immediately to a new page, not a new tab or window."
This is a bug, I think. Should be an easy fix. A work-around is to right-click to get a context menu and then select "Open link"; then it should work as expected.
"To reduce accidental clicks, these automatic links are only active if you also hold the control key;"
These are not "Automatic links" - they're explicitly requested using the OSC 8 escape sequence. So I think it is reasonable they act differently - but they should still open in a new tab/window, not hi-jack the DomTerm window.
"I tried to test with hcat, but this just freezes when invoked on an html file"
Can you give me an example?
Hi, it looked like a bug to me but I always err on the side of self-doubt. I'd love to see it fixed. How links work seems like a pretty central UI element; I'm wondering if it makes sense for this to be configurable in some way?
Regarding hcat I tried
<a href="http://example.com">test</a>
and
<html></html>
and
<html><head></head><body><a href="http://example.com">test</a></body></html>
and finally a locally saved wget of example.com's index.html. In all cases there's a newline and then it freezes until a ctrl-c.
^^^ that's a perennially blinking cursor.
"How links work seems like a pretty central UI element; I'm wondering if it makes sense for this to be configurable in some way?"
I'm leaning towards having two kinds of link: subtle, and non-subtle, based on whether the class attribute contains the word "subtle". A regular link displays (by default) in the "normal" link style (typically blue text with underline). A click opens the URL according to the "Specifying handlers for clicked links" documentation, as does Right click->Open link. (If the URL resolves to "browser" and we're currently running in a browser, a fresh window or tab is opened.)
A "subtle" link is similar but is not shown in a different color, and is underlined only on a hover. A plain (left) click ignored unless Ctrl is pressed; it can also be opened by Right click->Open link. (This behavior matches Gnome Terminal.) Again, use the same link handler.
"Subtle" style is used for links created implicitly (by pattern-matching) or inserting HTML with explicit class="subtle". The links created by the rich library (using OSC 8) should not be subtle.
I think this behavior is close to what I intended originally, but at some point it got broken.
I'm not seeing the hcat problems you report. For example, if you configued --with-asciidoctor you should be able to:
bin/domterm hcat share/domterm/help/domterm-browse.html
(after make without installing).
(The old logic has plain as well as subtle links in addition to ones that are neither. I'm thinking that may be excessible complexity.)
I think this approach seems fine. Just a note that I tried in Safari and Firefox just now, and the links are indeed working as I think you'd expect -- the cursor changes over them, but only right-clicking works to open a new tab or window.
With Chrome, however, left clicks pass directly through.
Regarding hcat my mistake -- I was running hcat directly as a binary
bin/hcat test.html
rather than as an argument to domterm
bin/domterm hcat test.html
I checked in some fixes to link handling. Please let me know how it works for you now.
I also made "Link handling" a separate documentation page and updated it.
Thanks! It's working in Chrome, requires a right-click.
Not sure what this means, but double-clicking links produces this message:
starting frontend command: firefox
no executable front-end (browser) 'firefox'
I don't believe I have this preference set anywhere...
"Not sure what this means, but double-clicking links produces this message ..."
Not sure why double-clicking makes a difference. Doesn't seem to for me - but I do have Firefox installed and running.
The default if unset for the setting open.link.application is {!mailto:}browser;{!mailto:}chrome;{!mailto:}firefox. (This doesn't quite match the documentation, it seems. Sigh.) Not sure how that would work - if the defaultbrowser doesn't work, I don't see a fallback path. Ah well - probably not a priority.
Hi, sorry, I hope this is helpful, but now on all three browsers my default links seem to be turned into "plain" and are acting like "subtle" in your Link Handling description. It is fine for me, but it seems to contradict what you wrote in the documentation, which indicates that the default is allowing link following with a regular click. There is also no mention of a "plain" class in the docs. Not a complaint, but it seems to not reflect what the docs say.
I added a sentence: "If the class attribute includes the word plain then no underline is added, but normal link styling applies otherwise."
The links displayed by python -m rich are regular (non-subtle) links, with class=plain set. However, you see an underline because the rich tool kit adds it.
Try ls --hyperlink=auto. That creates "normal plain" links without underlining (except during hover).
A "subtle" link would be if you did echo http://example.com with no special escape sequence.
Is the documentation still wrong or confusing?
Okay! I guess you have two categories for your documentation: normal and subtle. That's different from the possible classes, which are at least plain and subtle. What was more confusing to me, I think, was that the default link is subtle, and the "regular" link isn't the default. But that was partly because I was using a browser where subtle was erroneously clicking through immediately, so I doubt others will have my confusion... As always, thanks!
"I guess you have two categories for your documentation: normal and subtle. That's different from the possible classes, which are at least plain and subtle."
Specfically, plain is a variant of "regular" - same click-behavior, but slightly different styling (no added underline except on hover).
"was that the default link is subtle, and the "regular" link isn't the default."
That is not correct - well, I guess it depends what you mean by "default". An implicit link created by pattern-patching (i.e. not an explicit escape sequence) is subtle, but link explicitly created (including the ones created by the rich toolkit) are regular, not subtle. The latter may be plain, depending on the specific escape sequence. (Actually, you can explicitly create a subtle link, but you would have to emit HTML explicitly with <a class="suble">.)