Implement OSC 8 hyperlink support #68
Comments
|
Sure, sounds useful, I'll look into it when I have some time. It's a fairly large change as there are currently no spare bytes in kitty's cell structure. |
|
Shouldn't there be some way to query the terminal emulator for support of this feature? I'd suggest using the existing DECRQM escape sequence with a value of 2018 (2016 and 2017 are used by the kitty protocol extensions) https://github.com/kovidgoyal/kitty/blob/master/protocol-extensions.asciidoc |
|
Indeed it's not one of those easy-to-implement features. :) It might as well make sense for you to wait and see if apps start using it. As for querying: Ideally there should be a way, but I really despise asynchronous solutions. DECRQM/DECRPM might be nice for feature completeness against ancient specs, but I don't see much practical use. What would a utility or application do? Emit this and then wait for the response... for how long? Some terminal emulators don't send a response at all. So there must be a timeout. Why make the app slower by this timeout in certain terminal emulators? (Even think about shell scripts launching such utilities in a loop.) What if the timeout is hit because of the delay over ssh? Would the app then just not emit hyperlinks, totally confusing the user why it's randomly sometimes buggy? Fullscreen apps could just paint their screens without hyperlinks and then repaint once the positive response arrives. Silly user experience if the delay is visible, plus makes it quite complicated to implement in certain apps (they'd have to recognize this escape sequence in all parts of their code wherever they read and parse input, e.g. all widgets, dialog boxes etc.). Simple utilities that "just" print stuff can't go for this approach. Pretty much all terminal emulators ignore unknown OSC sequences, and I believe that's more than good enough to get starting with wide deployment of this feature. Especially since I believe apps and utilities should not blindly emit this sequence, but make it conditional to some app-specific user preference or cmdline switch. If some detection is implemented, it should be readily (synchronously) available for apps, e.g. as part of termcap/terminfo. VTE, according to my best knowledge, does not implement DECRQM/DECRPM and maybe we have a low-traffic bugreport about it but I'm not even sure, maybe we don't have any. It's not something that users really miss. |
|
termcap/terminfo is an awful solution because it means you have to have the terminfo files on remote servers as well when using SSH. Not to mention that the maintainers of terminfo have gone permanently to sleep. As for asynchronicity, the problem domain is fundamentally asynchronous, because terminals have to work over networked connections (SSH). There is no way around that. Well technically, the way around that is to have the ssh program forward terminal info to the remote side as part of connection setup, but given that this is a network problem, making it happen is going to require lots of time and effort to get buy in from the various involved parties. In this particular case, a well behaved application should either:
|
|
Oh and assuming the terminfo maintainers can be budged, the solution for the timeout problem is simply to add a capability to terminfo for DECRQM. So if terminfo indicates the terminal supports it, client applications should wait, otherwise not. |
|
Also, in case it is not clear, the reason I recommed adding detection for this feature is that client applications can change their output based onit. If the feature is present they can output clickable links as blue underlined text, for instance. That makes the feature much more discoverable. |
For terminfo I agree with you. For termcap, as far as I know, its value (in the $TERMCAP environment variable) could be forwarded via ssh, and that would probably be a proper design. (Or even better, forward the entire terminal description, but instead of placing it in a giant environment variable, rather place it in a file and create an env var pointing to that file, similarly to $XAUTHORITY. Terminal emulators could initally just set this env var pointing to their local copy of the file. Anyway, I guess designing the proper solution is way out of scope of this particular feature. It would be nice to come up with a solution accepted by all major OSes, libraries etc., quite a few people have brought this up on various forums recently, but unfortunately I don't see a reasonable chance for this to happen.
ncurses's terminfo database is actively maintained, and despite a few folks requesting it, its maintainer has repeatedly refused to introduce an entry to denote 24-bit true color support. So I don't see a chance he being in favor of adding a flag for the hyperlink feature.
The full duplex channel is asynchronous by its nature, but normally it doesn't limit the overall speed. The problem is when you have to wait for a response because then roundtrip time becomes the bottleneck. With a small utility using DECRQM executed a thousand times in a shell script in a loop, and a roundtrip time of 0.1s, this becomes an additional 100 second delay. That's a huge problem! It's okay for ssh to take a few roundtrips as it initializes the connection, but subsequent operation should avoid that.
This sounds the worst idea to me so far. Like, the app starts to use a feature, and at one point it figures out it's not available and then it goes like "oops, sorry, lemme redo without it"? What do we expect for when it emits hyperlinks? The screen to appear correctly? Then why stop doing it? Or the screen to get garbled? Why would we allow to have a temporarily garbled screen? Even with 1. and 2., the main problems are that detecting availability is slow and is extremely complicated. As such, I'm pretty sure hardly any (if any at all) applications will bother. I am a bit familiar with Midnight Commander, so let's take that as example. Each widget (e.g. the copy dialog if you press F5) is responsible for handling the input on its own. So each widget would need to look for this escape sequence possibly arriving, and instruct the global app to repaint. Probably requires huge and ugly refactoring. Keep in mind that you can typeahead, press F5 before mc starts up, that is, the DECRPM response would only arrive at mc after the F5 keycode. Plus, the user-visible behavior would still be suboptimal to say the least. We've been to similar situation, the urxvt mouse extension protocol pretty much failed because it was hard (not impossible at all, just hard) for applications to implement it. If we need a way of autodetecting at all, we need a damn simple way. Also, think about simple utilities that "just" print stuff. They can have their standard file descriptors redirected, e.g. input read from a file, output piped to No, this DECRQM approach is just not viable at all. Terminfo has its serious downsides, we agree in that, but I firmly believe DECRQM is even worse from a practical point of view.
This might look good on paper, but not in real world practice. Terminfo is not something that works perfectly, it's something that "mostly works". Some emulators, e.g. VTE and konsole set TERM=xterm-256color, although their behavior is not exactly what's defined there. They used to set TERM=vte or TERM=gnome or TERM=konsole, but that approach just caused even more problems. Also take a look at stackoverflow how many people still to this day have problems with incorrect TERM variables inside tmux, etc. You simply cannot count on TERM being set properly, risking a complete freeze of apps if it isn't.
Just because a terminal emulator supports hyperlinks, I don't think it means the application should suddenly change their behavior. There is a chance that the user doesn't like this behavior or just prefers the layout he got used be. Even if an app only wants to linkify some pieces of text, I think it could ask users whether they want it. If an app wants to change its layout (change its displayed text) because of hyperlinks, it should definitely be a user config, not some magic autodetection. On discoveability, blue underline: VTE dashed-underlines hyperlinks for discoverability. (This might change in the future.) I believe it's better if the terminal emulator gives a unique look of all such strings, rather than if each app is responsible for choosing and explicitly setting the hyperlink style. Although I'm not sure it's good mixing the semantics and the presentation the way we did. We'll hopefully gather user feedback during the next months or few years, and revise if necessary... |
|
On Fri, Apr 28, 2017 at 02:21:03PM -0700, egmontkob wrote:
"termcap/terminfo is an awful solution" – For terminfo I agree with you. For termcap, as far as I know, its value (in the $TERMCAP environment variable) could be forwarded via ssh, and that would probably be a proper design.
(Or even better, forward the entire terminal description, but instead of placing it in a giant environment variable, rather place it in a file and create an env var pointing to that file, similarly to $XAUTHORITY. Terminal emulators could initally just set this env var pointing to their local copy of the file. `ssh` would forward its contents, place in a temporary file on the remote host, set the env var accordingly, and remove the temporary file upon closing the connection... Hmmm, I'm wondering if they could do it with terminfo and $TERM as well...)
This can be done already via the TERMINFO env var. This is incidentally
how kitty manages to work without needing to be installed using root
access. But, yeah, I dont have the time/patience to convince the
maintainers of ssh to use this, and in any case this would only be
useful if the maintainers of terminfo could be convinced to actually
add modern capabilities to their database.
Anyway, I guess designing the proper solution is way out of scope of this particular feature. It would be nice to come up with a solution accepted by all major OSes, libraries etc., quite a few people have brought this up on various forums recently, but unfortunately I don't see a reasonable chance for this to happen.
I agree.
"maintainers of terminfo have gone permanently to sleep" – ncurses's terminfo database is actively maintained, and despite a few folks requesting it, its maintainer has repeatedly refused to introduce an entry to denote 24-bit true color support. So I don't see a chance he being in favor of adding a flag for the hyperlink feature.
Really, that must have changed recently. But anyway, in my experience
they are asleep, in yours they are un-cooperative, in either case, no
dice.
"As for asynchronicity, the problem domain is fundamentally asynchronous" – the full duplex channel is asynchronous by its nature, but normally it doesn't limit the overall speed. The problem is when you have to wait for a response because then roundtrip time becomes the bottleneck. With a small utility using DECRQM executed a thousand times in a shell script in a loop, and a roundtrip time of 0.1s, this becomes an additional 100 second delay. That's a huge problem! It's okay for ssh to take a few roundtrips as it initializes the connection, but subsequent operation should avoid that.
See isatty(), which is synchronous and any well behaved app should only
wait if its output stream is actually connected to a tty. And
applications that are designed for rapid multi-execution can very well
choose not to wait.
The essential point you seem to be missing here is that feature
detection is not compulsory. If it exists, applications for which
it makes sense can use it, applications for which it does not, will not.
"3. Start outputting with OSC codes and stop when a response is not received." – This sounds the worst idea to me so far. Like, the app starts to use a feature, and at one point it figures out it's not available and then it goes like "oops, sorry, lemme redo without it"? What do we expect for when it emits hyperlinks? The screen to appear correctly? Then why stop doing it? Or the screen to get garbled? Why would we allow to have a temporarily garbled screen?
Because it is better than a permanently garbled screen.
Even with 1. and 2., the main problems are that detecting availability is slow and is extremely complicated. As such, I'm pretty sure hardly any (if any at all) applications will bother. I am a bit familiar with Midnight Commander, so let's take that as example. Each widget (e.g. the copy dialog if you press F5) is responsible for handling the input on its own. So each widget would need to look for this escape sequence possibly arriving, and instruct the global app to repaint. Probably requires huge and ugly refactoring. Keep in mind that you can typeahead, press F5 before mc starts up, that is, the DECRPM response would only arrive at mc _after_ the F5 keycode. Plus, the user-visible behavior would still be suboptimal to say the least. We've been to similar situation, the urxvt mouse extension protocol pretty much failed because it was hard (not impossible at all, just hard) for applications to implement it. If we need a way of autodetecting at all, we need a damn simple way.
Huh? Have the global application query support for all the extensions it
needs once at startup, and set a global variable indicating whether it
exists or not. After that all the application components/widget/what
have you can simply read from the global variable.
Also, think about simple utilities that "just" print stuff. They can have their standard file descriptors redirected, e.g. input read from a file, output piped to `less -R`. Where to send DECRQM and where to expect DECRPM to arrive from, then? Maybe the controlling terminal? What if it doesn't exist (e.g. `ssh hostname command`)?
Once again, isatty().
No, this DECRQM approach is just not viable at all. Terminfo has its serious downsides, we agree in that, but I firmly believe DECRQM is even worse from a practical point of view.
The ability to optionally detect if a feature exists is never worse than
no ability to detect it exists at all.
"So if terminfo indicates the terminal supports it, client applications should wait, otherwise not." – This might look good on paper, but not in real world practice. Terminfo is not something that works perfectly, it's something that "mostly works". Some emulators, e.g. VTE and konsole set TERM=xterm-256color, although their behavior is not exactly what's defined there. They used to set TERM=vte or TERM=gnome or TERM=konsole, but that approach just caused even more problems. Also take a look at stackoverflow how many people still to this day have problems with incorrect TERM variables inside tmux, etc. You simply cannot count on TERM being set properly, risking a complete freeze of apps if it isn't.
I said applications should wait if terminfo indicates support for
DECQRM, not that they should wait permanently. The only downside to
mis-configured systems is then a short delay at startup.
But I totally agree that terminfo is awful. The proper solution for
terminal querying capabilities is to have the kernel add support for it.
Either via a new termios system call or via a new device file like
/dev/pts-cap/<num>
"client applications can change their output based onit. If the feature is present they can output clickable links as blue underlined text, for instance. That makes the feature much more discoverable" – Just because a terminal emulator supports hyperlinks, I don't think it means the application should suddenly change their behavior. There is a chance that the user doesn't like this behavior or just prefers the layout he got used be. Even if an app only wants to linkify some pieces of text, I think it could ask users whether they want it. If an app wants to change its layout (change its displayed text) because of hyperlinks, it should definitely be a user config, not some magic autodetection.
Huh? The choices here are either:
1) No feature detection which means client applications always change
their output regardless of terminal emulator used
2) Feature detection: which means client applications have at least the
possibility of doing the right thing, depending ont he terminal emulator
being used
application configurability is completely orthogonal to this.
On discoveability, blue underline: VTE dashed-underlines hyperlinks for discoverability. (This might change in the future.) I believe it's better if the terminal emulator gives a unique look of all such strings, rather than if each app is responsible for choosing and explicitly setting the hyperlink style. Although I'm not sure it's good mixing the semantics and the presentation the way we did. We'll hopefully gather user feedback during the next months or few years, and revise if necessary...
Yes, and in order for a user to know some random piece of text is
clickable they have to first hover their mouse over it. There is a reason
links on the web are highlighted.
|
|
Actually thinking about it, one does not even need to involve the kernel at all. All one needs is a simple program that can store and retrieve terminal capabilities keyed by terminal device file. So the terminal emulator calls echo hyperlinks,colored-underlines,... | terminal-capabilities set /dev/pts/[fd-no]Client programs call terminal-capabilities getto get the above list. It will get the capabilities for the current controlling tty SSH will simply call For security There you have, robust, synchronous detection of terminal capabilities. The only requirement is that the |
|
Obviously, the format and semantics of the capabilities needs to be defined more carefully, but the essential mechanism of setting/getting them will work as above, regardless of the details. |
|
I edited the above proposal slightly, to use file paths instead of fd numbers. |
I would love to have a simple way to autodetect this feature. One that's simple enough for pretty much all utilities to use without going into the inevitable troubles of asynchronity. But not one which is so complicated as this proposal and has so many problems. Introducing such a troublesome way of autodetection is, in my opinion, much more of an additional burden and source of problems to carry than a solution for apps that are interested. VTE has been doing fine for maybe like 15 years without DECRQM. It has tons of features that cannot be autodetected. Just to stay at the OSC world, there's no way to detect whether OSC 0, 1, 2 (title, icon title), 6, 7 (current file and directory) etc. work, and at this point we're no longer specific to VTE. This hasn't been a problem so far. E.g. just as with hyperlinks, an app might want to know if whatever it puts in the title will actually be visible for the user or not. No way to do that, and noone has been missing this feature yet. If you add an asynchronous escape sequence, which I'm still strongly against, I believe you should figure out a generic way for OSC sequences, rather than maintaining an arbitrary mapping between OSC and DECSET numbers, and reserving a number in the DECSET range which doesn't have a corresponding DECSET/DECRESET behavior. E.g. similarly to OSC 4, 5, 10... reporting the given color, it could be OSC 8 with a Also, I believe this should at the very least be discussed involving all people who participated in the hyperlink feature. Due to the problems I've mentioned above (and clarified below as well), I don't have any motivation in implementing or advocating any asynchronous behavior. Of course I can't and don't speak in the name of VTE's main developer, or iTerm2's developer. If there's anything I'd be happy to see and happy to contribute some work towards, although I don't have time to drive it, would be to get OSes and distributions to patch their terminfo downstream, or to have a fork of terminfo, which would contain flags for features like truecolor, hyperlinks and possibly other new ones. See e.g. the comments from https://gist.github.com/XVilka/8346728 dated this Feb-Mar.
What you are missing here: There might be (and usually there are) multiple places in an app's code where it reads input. And all of them, without any exception, have to be prepared for receiving the given sequence due to its asynchronous nature and the possibility of typing input keys before the application starts up. Or, the application refactored so that the input goes through a common preprocessing phase (which handles and removes this response) before it reaches those individual places where it is read. Or just think about a simple shell script using the
Such responses address a small subset of the problem area, but not the entire area. E.g. what if I pipe the output to
Assuming that the feature detection is designed well, works robustly, and is supported across terminal emulators. Which your proposal is not. To summarize, and to make myself more explicit and more pragmatic, because I feel like this discussion is no longer leading us anywhere:
|
|
If I do implement this feature in kitty, in the future, it will be with feature detection. The idea that not having any feature detection is better than having feature detection is just plain wrong. Since you dont seem to want to have a discussion, I wont bother elaborating on that. |
|
It's not that I don't want to have a discussion. We had a decent one, and I believe we got to the point where our opinions won't get any closer to each other. Hence I see no point in repeating ourselves over and over again. |
|
I'd love to have this feature in kitty for use with mdcat, even without proper feature detection. I must admit that I am disappointed to read that you insist on feature detection, and I fear that this useful feature be delayed indefinitely in order to first solve a problem that no one has solved in the past 30 years and likely will solve in years to come, if at all. iTerm2 and gnome-terminal/VTE don't provide a proper feature detection mechanism either, but in my experience it doesn't cause any serious issues. We can detect the underlying terminal by various environment variables different emulators set. Not perfect of course, but in my opinion good enough in most cases, and it seldom fails catastrophically. I'd like to ask you to reconsider your stance, and add this feature to kitty. |
|
Umm implementation of this feature is not gated on detection. I just dont have much use for it personaly, so it is not a priority, especially since implementing it will have negative effects on performance (it will require increasing the cell size) |
|
@kovidgoyal Oh, I’m sorry, I misunderstood your comment:
I’m sorry for the noise. |
|
no worries :) |
|
I came to say that it would be great to have this. |
|
For what it's worth, I work on a chat client called Matterhorn that supports terminal hyperlinking via the underlying Vty Haskell library. Although Matterhorn makes hyperlinking configurable to avoid issues with terminals that don't support the feature, I use Kitty myself and would love to see this feature supported! |
|
I've been doing a bit of reading about this feature recently and I've grown more apprehensive about it the more thought I've put in. On the one hand it does sound like a useful feature to have. However I'm not convinced you can implement this securely - at least not without putting enough hurdles in place that you compromise any effective usability benefits. Even putting aside the debates about non-HTTP protocol handlers, plenty of administration tools are HTTP based these days so it would be trivial to craft a malicious HTTP/S request. Given the terminal is pretty central for developers, systems administrators and everyone in between, and given we have survived this long without needing hyperlinks in the terminal, this feature seems to add little benefit but at the cost of exposing our most important management tool to rudimentary URL spoofing. In terms of how browsers get around this problem: they don't. They can't full. The status bar used to give some insight into a URL when you hovered your mouse over it but even that cannot be trusted since you can rewrite the status bar text in JavaScript (Google's search engine results do this in fact). And thus network admins / desktop support guys have had no end of problems with people falling for phishing attacks and such like. So in my opinion this feature, as cool as it is, does not belong in our terminals. |
|
@lmorg I dont quite understand what the security issue is. If a terminal implements this feature, all it means is that it allows programs running in the terminal to cause the terminal emulator to open the browser with arbitrary URLs in response to a user click. Local programs can just launch browsers with arbitrary URLs all by themselves anyway. So the only possible new attack surface is that a program running on a remote machine connected over ssh could entice the user into opening a browser with an arbitrary URL on the local machine. Is that what you are worried about? And given that pretty much any website can cause the user to open locall browsers with arbitrary URLs anyway, I dont really see how allowing terminals to do the same significantly adds any risk. If you are at a point where even launching a browser with a URL is a security risk, then I'd say you are pretty hosed. |
|
I mostly agree with @kovidgoyal here. And you don't have to click the links in your terminal if you think they might be malicious. Also not everyone has local servers with no authentication and and no CSRF protection running. |
It's twofold:
In the above example a terminal user would be under the impression the hyperlink will direct them to
The risk is that it breaks the WYSIWYG trust that people have in terminals and terminals generally runs on more sensitive systems too. History has already taught us that users cannot be trusted to follow due diligence with checking what hyperlinks are safe before clicking them so it seems dangerous to me to allow this behaviour to then migrate onto terminals - which are expected to be more secure.
That's not an acceptable answer because some people will. Security has to have the defence of depth to work. Simply asking people to show due diligence doesn't offer that depth - not even remotely.
Some HTTP-based administrative interfaces might cache user authentication via cookies. Granted in an ideal world those cookies should have an ultra short TTL and any actionable APIs should be POST requests (rather than GET) - however you cannot assume that will be the case all of the time. Thus we come back to the defence of depth point I raised earlier. |
|
I think given the risks this feature brings and the push some power users are having in enabling this feature, an alternative question should be asked:
The only ones I've seen thus far:
The problem with hyperlink support in terminals is I'm not convinced their benefits outweigh their risks. The mitigating controls suggested in this issue don't even follow basic security principles let alone offer sufficient protection against the problems I've outlined. Anyhow, I've been rather negative in this thread so thought I'd end on a high: I really value the work you've done on Kitty. It's an awesome terminal emulator. Thank you. |
|
Would showing the real URL when hovering over the link like many browsers do be an acceptable compromise? |
|
It's better that having the administrator blindly click a link but it still doesn't address the defence of depth point I raised earlier. Plus there are a couple of obvious issues with hover-over interfaces:
Realistically we should really be discussing what problems you're trying to solve with hyperlinks in the first place rather than how we might educate users to use them safely. It might be the case that there is a better solution to the problem you're trying to solve than having hyperlinks in the terminal. But without knowing the incentive behind this feature request we'd just be doomed into a cyclic argument of whether a user can be trusted to perform due diligence. |
|
Security aspects have been discussed in the comments section of the feature's gist, I recommend to you guys to go through them. The only pending concern I find valid is that some OSes allow various apps to register (unsafe) handler apps for various protocols. A solution could be to limit support in Kitty for a few well-known protocols, e.g. http, https, ftp and file.
Equally so from a browser. If a malicious HTTP(S) request can be crafted, your website is buggy as it doesn't do proper authentication, CSRF etc. protection.
It's not strictly speaking a "need", it's a new convenience feature. Sure you can live without it, just as much you can live without curly and colored underlines, raw keyboard reporting, image support and all those other new features newly supported by Kitty or whichever other terminal.
First, Kitty might offer a config option to disable hyperlinks. Then you can just entirely disable this feature for yourself. Second, apps (e.g. mutt), if they implement explicit hyperlinks, might also offer a way to disable them. This way you can disable them for apps that handle untrusted data. This feature is also expected to be useful in cases when you fully trust the utility you're using, e.g. an in-house deployment script pointing to an in-house webpage that shows the progress, or for example "ls --hyperlink". In such cases you still have the trust.
Sure, the terminal doesn't provide more defense than web browsers do. But why is that a requirement? Whenever a website can be hacked by following an unexpected link in a terminal, so can it be by following the same link from another webpage in your browser.
I use this feature quite frequently. 5 seconds indeed sounds like a good estimate on average (counting for cases where copy-pasting the filename doesn't work due to space characters in it; tab completion stopping at unexpected places where I have to locate the next letter of the filename to be typed; and cases when I mix up the utility's name and type "evince" instead of "geeqie" or the other way around which does happen to me quite frequently). Then multiply this 5 seconds by maybe 10-20 times a day, for me.
In gnome-terminal, a single click doesn't follow the link, it selects text. You need to Ctrl+click, or right-click and choose the corresponding menu entry to open the link.
The feature's specification lists quite a few current and possible future use cases. |
|
Can we please take discussion of the desirability or otherwise of this |
|
@lmorg while your concerns with hover interfaces are generally valid, I don't think they apply to kitty:
kitty currently requires one or more configurable keys to be pressed while clicking a URL for it to be opened.
Well kitty supports Linux and macOS and at least on macOS this concern doesn't apply because there are no Macs with touch screens. I'm not sure about Linux as I have never tried to use a touch screen with Linux before.
I'm pretty sure kitty doesn't work with a screen reader as it uses OpenGL to render stuff. Other terminals that explicitly support screen readers will probably work much better for this sort of thing. |
|
@kovidgoyal sorry, read your comment after posting. |
|
OK, I'll put my comments on the main gist. Thank you @Luflosi @egmontkob https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda#gistcomment-2829793 |
|
Since your comment is about the design of the feature, not about anything specific to kitty, it should be discussed in the gist linked above. |
|
@Luflosi we already had done that more than a month ago. I'm a little confused why you're resurrecting this conversation. |
|
This would be extremely useful for tmux users, as clicking on a URL in a tmux-split plane is pretty much impossible; you have to awkwardly copy and paste portions of it, or zoom the pane and click on the URL and unzoom it, both being subpar experiences ergonomically. |
|
Sorry, @lmorg I didn't mean you. Someone else left a comment, he must have deleted it. |
|
haha fair enough. |
@sssilver I'm guessing you have mouse support enabled? You basically have two options: 1/ shift+select. This is how I do any mouse operations when mouse support is enabled 2/ disable mouse support. This might be a bit drastic for some users however I personally have found it gets in the way more often than not. Also if you have mouse support enabled you might find that ANSI URLs wouldn't work anyway (depending on how the terminal emulator implements it) |
|
Note the URL on the right pane being highlighted only for the first virtual "line", making it effectively useless. How does shift+select or disabling mouse support help me navigate to that URL? |
|
Maybe the rectangle selection helps in this case. See https://sw.kovidgoyal.net/kitty/conf.html#opt-kitty.rectangle_select_modifiers. |
|
Sure but this would entail selecting, copying, switching to a browser, creating a new tab, pasting the copied URL into the address bar, and pressing Enter. I thought this thread was about the ability to automate all those actions with a single "navigate to this URL" action, whether through clicking on it with a mouse or through navigating to it by other means, i.e. keyboard. |
Yes. This may be the best solution as long as this feature isn't implemented.
Yes, it is. I was simply trying to offer a workaround that is better than what you seem to be currently doing. |
|
YES! It got added! |
|
@kovidgoyal: Thanks! Do you have plans to implement support for this in the hints kitten too? |
|
On Tue, Sep 15, 2020 at 12:23:43PM -0700, Trygve Aaberge wrote:
@kovidgoyal: Thanks! Do you have plans to implement support for this in the hints kitten too?
Yes, and note the implementation is nowhere near complete yet.
|
|
And as promised, I have added detection, that even reports the current value of the allow_hyperlinks config option. This is based on the existing XTGETTCAP escape code pioneered by XTerm so it can be used even without the kitten. |
GNOME Terminal (VTE) and iTerm2 have just implemented a brand new and hopefully really cool feature: hyperlinks (that is, HTML-like anchors).
This is different from the autodetection of URLs that appear onscreen. This time the text that appears does not have to look like a URL, it can be anything, and the target URL is specified explicitly by the utility along with the displayed text, using the OSC 8 escape sequence.
We'd like to get some wider support for this feature, and it would be great if kitty joined the game!
For further information on this feature, see
A dedicated page with all the details: https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
GNOME Terminal bugreport (way too long and probably not that interesting at this point, although might contain some useful tips): https://bugzilla.gnome.org/show_bug.cgi?id=779734
iTerm2 bugreport: https://gitlab.com/gnachman/iterm2/issues/5158
The text was updated successfully, but these errors were encountered: