Keyboard shortcuts for opening links, copying file paths or hashes.

[ferdinandyb]

Abstract

Add a new feature that allows for quick action on URL-s, file paths, hashes or other user defined regexes.

Possible solutions:

• Kitty for example has a keybind which will assign a number/letter to each visible link, and pressing the key opens the link in the default browser (see kitty's docs for details).
• Another solution I could imagine is defining some searches for the vi-mode, so with a keybind the user could jump into vi mode with search for say URL-s already enabled. Cycling through with n and for example using gx to open the url in default browser or if it's a path or a hash than pasting it with an appropriate key.

Motivation

Currently, the fastest way to open a link seems to be ctrl + mouse click. Using only the keyboard one would need to enter vi mode, navigate manually to the URL, yank it (yiW if lucky, more complicated if not), switch to a browser, and manually input the copied URL. Which is rather cumbersome. Although vi mode is great for selecting arbitrary text, I think opening URLs and copying file paths and (git commit) hashes to the currently typed command are very common operations, that could benefit from extra speed.

[Utkarsh-khambra]

Hi @ferdinandyb Adding a vim motion to jump to urls is already something we discussed and wanted to add and vim motions for hashes and paths seems like good candidates too, and I think a good general solution could be to allow users to bind jump motions to regexs. I haven't thought about how it'll work, but this could be a base to provide jumps over hashes etc.

[christianparpart]

Checklist for implementing this could look like:

• [ ] vim mode: gx to open the URI (or file) underneath the cursor position
• [ ] vim mode: ]x to jump to next and [x to jump to previous URI (or file) in screen's grid buffer
• [ ] allow customising how to detect what an URI is via a regex through the config file (profile).
• [ ] visually differentiate matches (just like search/click matches) to make cycling through them and quickly identifying them visually more appealing

I did have a look at how kitty is annotating the currently visible links on the screen. Somehow I do not find that actually nice to look at. We could certainly do something like this, too, but since I am not certain yet, we could implement that on top of the above any time later (I'm open to that).

[ferdinandyb]

Checklist for implementing this could look like:

• [ ] vim mode: gx to open the URI (or file) underneath the cursor position
• [ ] vim mode: ]x to jump to next and [x to jump to previous URI (or file) in screen's grid buffer
• [ ] allow customising how to detect what an URI is via a regex through the config file (profile).

Would this mean, that users will need to define which type of thing they want to follow with ]x? I.e hardcode in config whether it is a file or an URL?

• [ ] visually differentiate matches (just like search/click matches) to make cycling through them and quickly identifying them visually more appealing

I did have a look at how kitty is annotating the currently visible links on the screen. Somehow I do not find that actually nice to look at.

Me neither really :) Although it is pretty practical.

We could certainly do something like this, too, but since I am not certain yet, we could implement that on top of the above any time later (I'm open to that).

I'm obviously quite fine with whatever you decide, the vim mode seems very in-line with contour (and has an added advantage that it can also find URLs that are currently not visible, but were shown earlier, if I understand correctly).

[christianparpart]

Would this mean, that users will need to define which type of thing they want to follow with ]x? I.e hardcode in config whether it is a file or an URL?

by default that'll be URIs (and file paths I think). but that aught to be configurable.

I'm obviously quite fine with whatever you decide, the vim mode seems very in-line with contour (and has an added advantage that it can also find URLs that are currently not visible, but were shown earlier, if I understand correctly).

yes, you do.

and this functionality can later be extended to support regex searches as well. (one feature at a time. our current prio currently should lie on the qml pr though, but this one here makes sense to have as well, of course).