chrishrb / gx.nvim Goto Github PK

Not sure what is happening but when I press gx over any link I'm getting this thing on my screen:

It'd be awesome if gx.nvim supported a way to open multiple links when using visual selection.

When you select 5 links, open all 5. I haven't yet thought about if it should open only if each line contains only a link, or to try and find all the links in all the text (as in, if links are between text).

https://mylink1.com
https://mylink2.com
https://mylink3.com
https://mylink4.com

vs

Hello and welcome to https://mylink1.com. Here you will find some good stuff. https://mylink2.com
At our HQ website, https://mylink3.com, We welcome any new visitors with a registration step redirect to https://mylink4.com

Regards,

With netrw gx, following an internet url, the new window doesn't get focused but with this plugin it does. Would like an option to not lose focus of neovim and manually navigate to the internet window.

Right now the first handler that matches in the handlers table is accepted and no other handlers are evaluated.
There might be some cases where there's overlap between handlers and multiple handlers are capable of handling a URL.

The https://github.com/rmagatti/gx-extended.nvim plugin handled this by presenting the user with a popup where you could select which handler you'd want to use if there's multiple matches.

Would be great if this feature could be adopted.

As far as I can tell, the only way to interact with this plugin is by the gx keymap. So this plugin really doesn't need to be loaded before a user presses gx. In the README however, lazy loading on BufEnter is recommended: https://github.com/chrishrb/gx.nvim/blob/38d776a0b35b9daee5020bf3336564571dc785af/README.md?plain=1#L32C4-L32C5

It would be better to replace this line with

keys = { "gx" }

thanks for your useful plugin first! Nowadays I encounter this situation

Error: error occured in dts build
    at Worker.<anonymous> (/Users/shellraining/Documents/learnsth/vitepress/sugar-blog/node_modules/.pnpm/[email protected][email protected]/node_modules/tsup/dist/index.js:2294:26)

when I press gf, it not jump beacuse :2294:26, can you enhance this plugin to support?

As a plugin user I'd appreciate it if gx.nvim would allow for defining my own handlers, in good old gx-extended fashion.

To reproduce:

• Use https://github.com/tpope/vim-fugitive
• Go to a git repo with a remote configured
• open neovim
• :G log
• look for a git commit message with a github issue link and move the cursor on top
• hit gx

Expected:

• issue opens in browser

Actual:
I get prompted with the following message:

gx.nvim: No remote git repository found!

And then the plugin continues to open a google search with the text.

Similar to package.json it would be nice to support Ruts's cargo dependencies. Opening in either crates.io or docs.rs

When the line is

[a](https://a.com/), [b](https://b.com/)
 ^

and my cursor is at ^, the chosen URL is https://b.com/. I think the markdown regex is too expansive.

When I push a new branch to a repo from nvim's terminal emulator, git gives me a URL to create an MR:

To create a merge request for <branch-name>, visit:
  https://company.example.com/team-name/repo-name/-/merge_requests/new?merge_request%5Bsource_branch%5D=branch-name

If I manually copy-paste the link into my browser the %5B and %5D get replaced by [ and ] respectively. But if I use gx.nvim to open the link the URL seems to get cut off before the first square bracket. To use the example above, this is what opens in the browser:

https://company.example.com/team-name/repo-name/-/merge_requests/new?merge_request

when I press K to view docs, and move cursor to a link, then press gx, nothing has happened. Is this a bug or ?

I'm not sure if this is intentional, but currently markdown links only open if the cursor is over the url itself, rather than if it is anywhere within the boundaries of the markdown link syntax. It would be awesome if you could open the link wherever the cursor is placed, especially for longer worded links, and with url concealing being a feature!

[gx does nothing here](https://www.gx-works-here.com/).

Whenever you try to open a URL with a fragment (a hash sign #) gx.nvim opens it without the fragment in it.

Here's an example for clarity:

A URL like:
https://flask.palletsprojects.com/en/2.2.x/testing/#tests-that-depend-on-an-active-context

gx.nvim opens as:
https://flask.palletsprojects.com/en/2.2.x/testing/

Opening a github url like org/repo#issue instead tries to open the current git remote URL (and fails due to #45).
for example:

> git remote -v
origin  https://github.com/sindrets/diffview.nvim.git (fetch) [blob:none]
origin  https://github.com/sindrets/diffview.nvim.git (push)

pressing gx on neovim/neovim#23943 results in the choice between searching the string or opening
https://github.com/sindrets/diffview.nvim.git (fetch)/issues/23943

Instead, this should open https://github.com/neovim/neovim/issues/23943

gx replaces Netrw very nicely, but fugitive uses it for opening github in the browser. Fortunately, it can also use a :Browse <url> command, so exposing one will fix the problem.

Thank you for the awesome plugin. I use surf browser. It launches a new browser on each xdg-open and plenary throws error 'xdg-open ...' was unable to complete in 5000 ms. I would like to get rid of this message. Should I maybe somehow modify application entry to detach xdg-open?
My configuration of the plugin is basically default:

{
	"chrishrb/gx.nvim",
	keys = { { "gx", "<cmd>Browse<cr>", mode = { "n", "x" } } },
	cmd = { "Browse" },
	init = function ()
		vim.g.netrw_nogx = 1
	end,
	dependencies = { 'nvim-lua/plenary.nvim' },
	opts = {
		handler_options = {
			search_engine = "https://search.disroot.org/?q=",
		},
	},
}

Right now it's hardcoded to gx, but I use mini.nvim which by default binds gx to exchanging text objects. I can remap its gx, but I find that I used that much more than opening links, so I'd like to keep it and just remap this to gX or something else instead.

Similar to how open-browser.vim does. I found it pretty useful

Hey, thanks for plugin. Having troubles with single quoted plugin urls- they are open without as is, without https://github.com prepended

On Linux, the standard behaviour of xdg-open is to block, which means that when gx.nvim uses os.execute to call this and open a URL, the whole of the NeoVim interface blocks. This is actually quite annoying if you're for example looking up a URL to copy some text into it, or compare with a file, or somesuch. (On Mac, this doesn't happen).

You might instead want to consider using vim.fn.jobstart to run the process, with detach = true, which, although xdg-open will block, won't block NeoVim itself by running it in the background. This is what I did in my own config for gx until recently when gx.nvim came along. You can find an example of how I implemented it here: https://github.com/andrewferrier/dotfiles/blob/6e8e16c6faa6f3a3f5789e03d30c2e8efa254063/common/.config/nvim/plugin/improve-gx.lua#L5 (ignore the open-file script, that's a wrapper I have around opening files/URLs - imagine it's xdg-open instead).

Really enjoying using gx.nvim, thanks for the great plugin!

Hi, I have a use case that I can't find in the documentation or in the issues:

Support for Mac Deep links like message:%3C....%3E.

Have you in program to support them?

I'm trying the plugin, and it works like a charm for all the rest 💚.
Thank you!

When I do gx on a comment like -- Fixes 42, the plugin tries to open https://github.com/sportshead/init.lua.git/issues/42, which is a 404. I have my remotes set like this:

$ git remote -v
origin	https://github.com/sportshead/init.lua.git (fetch)
origin	https://github.com/sportshead/init.lua.git (push)

It seems like the regex for http urls is a bit broad:

A regex like ^origin\t(.*)(%.git)? would probably work better for this.

Right now there are no tests if the link opens on the correct cursor postion - add some test here.

There are neovim users, such as myself, who are still relying on non-lua plugin managers such as vim-plug. It would therefore be appreciated if the plugin name pattern was also matched in vimscript files instead of just lua files.