[vim/vim] netrw's "gx" functionality doesn't open URLs anymore in macOS (#4738)

[Yee Cheng Chin]

Describe the bug
The latest Vim has updated to a newer version of netrw, which seems to have broken the gx functionality. In the past, positioning the cursor on an URL and press gx would open the URL in a web browser (using the open command). The updated netrw would instead try to curl it, which seems wrong.

To Reproduce
Detailed steps to reproduce the behavior:

1. Run vim --clean (or gvim --clean, etc.) in macOS.
2. Enter insert mode and type "https://www.vim.org"
3. Go to normal mode and type gx.
4. Observe that Vim doesn't open the URL in a web browser.

Expected behavior
Vim should open the URL in a web browser.

Screenshots
If applicable, copy/paste the text or add screenshots to help explain your problem.

Environment (please complete the following information):

• Vim version [e.g. 8.1.1755]
• OS: macOS 10.14 (haven't tested others yet)

Additional context
Bug was introduced in 85850f3. Originally I got this bug filed against MacVim at macvim-dev/macvim#925 so cross-referencing here.

This is a netrw bug so I'm not sure if this is the correct place to post it, but with the ownership question I'm not 100% sure who owns netrw now and where I should file a bug for it to be fixed and updated to Vim's bundled plugin.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub

[Bram Moolenaar]

Can you make it work by setting g:netrw_http_cmd ?

[Arseny Nasokin]

For me this command opens some random file from the history, despite setting of g:netrw_http_cmd. The conditions are same.

[Yee Cheng Chin]

g:netrw_http_cmd didn't seem to work for me. I could take a closer look too if no one takes it up. But I think the ideal case is that the old behavior is preserved, as open is the default way to open generic paths and has been working before.

[unclebill]

I got same issue.

[cecamp]

I don't have a mac, and I believe that I'm no longer the maintainer. However, try using g:netrw_browsex_viewer, not g:netrw_http_cmd. If that doesn't help, then refer to the directions in :help netrw_debug . Perhaps the macunix exception should be pushed before the has("unix") tests in netrw#BrowseX().

[Pim Snel]

I got same issue.

[Matěj Cepl]

I got the same problem with neovim (building from master on Linux/openSUSE). With g:netrw_browsex_viewer set to setsid osurl (my own script preprocessing references, but the same thing happens when using normal xdg-open, which is the equivalent of Mac’s open) vim downloads the page from the Web with curl and then opens in the browser the downloaded file (which is completely broken of course).

Any idea how to debug it?

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or mute the thread.

[Matěj Cepl]

I have my deep suspicion about https://github.com/vim/vim/blob/master/runtime/autoload/netrw.vim#L5309. That is incorrect, isn’t it? At least, when I run :echo g:netrw_browsex_viewer =~ '\s' I get 1.

—
You are receiving this because you are subscribed to this thread.

[Matěj Cepl]

Of course, it is wrong. When my g:netrw_browsex_viewer equals 'setsid osurl' (which exactly corresponds to the examples in the documentation), netrw thinks I have that variable empty.

[cecamp]

Anyone willing to use the directions in :help netrw-debug with the gx on a mac problem? I myself don't have a mac and so I can't debug this issue without some help.

[Ihor Antonov]

this happens on linux too

[Bram Moolenaar]

> this happens on linux too

What I notice:
- File written to a temp file (how is that ever cleaned up?)
- File name is a number, browser only recognizes it as HTML when adding
the .html extension.
- It closes the current buffer and goes back to the previous one


--
'Well, here's something to occupy you and keep your mind off things.'
'It won't work, I have an exceptionally large mind.'
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Matěj Cepl]

I see! So, only truly http[s]?: URLs are broken and result in curl craziness. When running gx on something weird (e.g., gh#vim/vim#4738, which is OK, my script will translate it into URL of this ticket), then my script is run and everything works just fine.

[Ihor Antonov]

I am on nvim
@mcepl

:e http://info.cern.ch

opens a new split and gives me

**error** (netrw) not a netrw-style url; netrw uses protocol://[user@]hostname[:port]/[path])

gx on the same link opens a new split, where this message flashes and disappears, leaving a split empty

And your example :e https://matej.ceplovi.cz/blog/harry-potter-and-aristotle.html opens html of the page

gx on the same link downloads the html file, and the opens it in a browser, so I see this URL
file:///tmp/nvimOl8arl/harry-potter-and-aristotle.html in path string

[Ihor Antonov]

So I think there is a bug somewhere in URL parsing that leads to downloading pages instead of simply opening them

[Matěj Cepl]

And your example :e https://matej.ceplovi.cz/blog/harry-potter-and-aristotle.html opens html of the page

gx on the same link downloads the html file, and the opens it in a browser, so I see this URL
file:///tmp/nvimOl8arl/harry-potter-and-aristotle.html in path string

That’s exactly what I see. :e URL opens HTML of the page (which is what’s expected, isn’t it?) and gx screws things up.

—
You are receiving this because you are subscribed to this thread.

[Jürgen Krämer]

I am on nvim
@mcepl

:e http://info.cern.ch

opens a new split and gives me

**error** (netrw) not a netrw-style url; netrw uses protocol://[user@]hostname[:port]/[path])

It seems :e URL needs at least a slash in the url to separate the host name from the possibly empty path. So

:e http://info.cern.ch/

should work and open the html in Vim (at least it does for me).

[Matěj Cepl]

It seems :e URL needs at least a slash in the url to separate the host name from the possibly empty path.

There are mountains of literature about that slash, and how URL/ is quite certainly not the same thing as URL. So, if netrw doesn’t consider them as the same thing, it is actually The Right Thing™.

—
You are receiving this because you are subscribed to this thread.

[Travis]

+1 subscribing to know when this is figured out, dis curl is cramping my style

[Christian Brabandt]

If you want to help fix this, how about going with the suggestions by Charles (e.g. provide the information from :h netrw-debug?)

[Matěj Cepl]

@cecamp Here it is.
DBG.txt

[Christian Brabandt]

cc @cecamp

[Christian Brabandt]

Alternative mentioned by Ken in #1386 (#1386 (comment)) is to use open-browser

[Arseny Nasokin]

It's not a bad idea to replace usage of bundled plugin with third-party, but it doesn't solve the problem

[Arseny Nasokin]

Does this plugin have high level tests (aka integration tests) to coverup underlying changes and tell that it works the same as it did before?

[Victoria Stuart]

Workaround (fails on URLs with #):

• https://stackoverflow.com/a/20177492/1904943
• Add to ~/.vimrc :

" nmap <leader><space> yiW:!xdg-open <c-r>" &<cr>
nmap gx yiW:!xdg-open <c-r>" & <CR><CR>

[Daniel Hahler]

This is caused by 85850f3.

A difference from there is that netrw#BrowseX is called with a:remote = 1 from the mapping:

  nno <silent> <Plug>NetrwBrowseX :call netrw#BrowseX(netrw#GX(),netrw#CheckIfRemote(netrw#GX()))<cr>

Old:

  nno <silent> <Plug>NetrwBrowseX :call netrw#BrowseX(expand((exists("g:netrw_gx")? g:netrw_gx : '<cfile>')),netrw#CheckIfRemote())<cr>

[cecamp]

Please try v166a of netrw.vim. If that doesn't work for mac users, please look at the help for g:netrw_http_cmd and find a command that works; then let me know and I'll put it in as default for macos. You can get v166a from my website, http://www.drchip.org/astronaut/vim/index.html .

[Daniel Hahler]

@cecamp
I've tried v166a (which would be easier if it would be available via Git directly btw), but it still does not work (on Linux).
The (main) problem is not mac, but that it considers the buffer to be a remote file already.
This patch works for me: https://github.com/vim/vim/pull/4894/files (and was merged for Neovim already, neovim/neovim#10938).

[Christian Brabandt]

the change from #4894 has now been included as of 589edb3#diff-532bf738932796a9a60951fb92334bac

[Christian Brabandt]

Closed #4738.

[cecamp]

Reopened #4738.

[cecamp]

The "solution" given essentially is removing "if filetype is netrw" handling - not good; and making "netrw#CheckIfRemote" return a falsehood (ie. that http:... is not a remote file), also not good. For this lying effect only the second call to netrw#GX() in the macro needed to be removed, by the way, thus preserving the "if filetype is netrw" handling. It was intended that netrw should return something editable; ie. the html for the page. I'm getting the html for the page (under linux), which was the desired behavior and is consistent with what happens with ":e http://..." handling. Setting g:netrw_browsex_viewer to "firefox" would bring up the page in a browser. I could retain the correct behavior (ie. returning html) but allow an option to use a browser for http[s]:// urls (where the user would be responsible for picking "firefox", "seamonkey", "iexplorer", whatever). How about g:netrw_browser or g:netrw_browsex_browser?

[Matěj Cepl]

@cecamp Couple of notes:

1. First of all, I have never claimed this to be perfect solution, or that I would actually understand what’s going on in netrw. It just removed a regression for me, that’s all.

2. Why does it matter that much, whether I press gx over correct URL or something else? I have g:netrw_browsex_viewer set to 'setsid osurl', where osurl is this Lua script. It basically means, that when I press gx over some SUSE abbreviated URLs I get my default browser called with proper URL. So, for example gh#vim/vim#4738 gets me to this issue, boo#1151490 gets me to this bug in openSUSE bugzilla. This is perhaps in the realm of XKCD 1172, but it would be awesome if this post-processing URL functionality was preserved.

—
You are receiving this because you are subscribed to this thread.

[SRGOM]

For those suggesting xdg-open, it's itself a cancerous piece of shit- you can never get it to use the program you actually want.

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Arseny Nasokin]

I bet there's a misunderstanding in definition of this plugin, it's usage and the further expansion of it's functionality.

There's nothing wrong that people use it to just open urls. In this case viewer shouldn't download them, like @mcepl suggests.
There's nothing wrong that people wants to edit remote files (download, edit and then upload). In this case downloading and uploading process should be separate from viewing, though. This is like @cecamp suggests.

Could this plugin do both? definitely yes, but not with the same gx command

[Matěj Cepl]

For those suggesting xdg-open, it's itself an unusable- you can never get it to use the program you actually want.

Are you on Linux? Which distribution you use? What is the bug number of the issue you raised with the maintainers of xdg-utils in your distribution? I mean, fixing bugs is a way more useful (and enjoyable experience) than ranting about unusable programs.

[Christian Brabandt]

I had problems with xdg-open in the past. I have been trying to debug this and it was indeed complicated shell scripts, hard to find out what it does. Plus, it does not look very-well maintained, at least I never got any reactions on the bug report I posted: https://bugzilla.xfce.org/show_bug.cgi?id=12251 No reactions for 4 years and "Resolved Invalid" :(

[Matěj Cepl]

Plus, it does not look very-well maintained, at least I never got any reactions on the bug report I posted: https://bugzilla.xfce.org/show_bug.cgi?id=12251 No reactions for 4 years and "Resolved Invalid" :(

https://freedesktop.org/wiki/Software/xdg-utils/ is rather instructive reading. You would find out that the proper place to file the ticket is currently https://gitlab.freedesktop.org/xdg/xdg-utils/issues (it used to be somewhere in https://bugs.freedesktop.org; or perhaps your distro’s bugzilla would work), certainly not the XFCE bugzilla.

[Christian Brabandt]

Wow, thanks for telling me. But that was not helpful at all.

The actual symptom was that gx did not work from within Vim. Before opening a bug report for netrw, I decided to do my best and try to find out what was wrong and how it could be fixed.

So I did trace netrw to find out, that netrw was basically calling xdg-open. So I checked :!xdg-open which had the exact same problem. So before opening a bug report for xdg-open I decided to trace xdg-open to find out what was happening, just to find out, that xdg-open does call exo-open in a xfce session.

So I tested using :!exo-open which did have the exact same problem. So I checked who is the upstream repository to be able to open a bug report at the correct repository in order to have this fixed.

That's why I opened a bug report at the XFCE desktop bugzilla and not for the freedesktop issue reporting issue. And if you would have read the bugzilla entry, you would have seen that the issue was clearly about exo-open.

So I did my duties to be helpful and report it at the proper place and provide an easy to reproduce example. And that place is neither the netrw bug tracker (e.g. here) or the freedesktop repository you mentioned, but the XFCE bugzilla, don't you think?

[Matěj Cepl]

So I did my duties to be helpful and report it at the proper place and provide an easy to reproduce example. And that place is neither the netrw bug tracker (e.g. here) or the freedesktop repository you mentioned, but the XFCE bugzilla, don't you think?

You did, I haven’t spent enough time trying to understand that bug, and thought the bug went other way around (exo-open was broken, because xdg-open was broken). Then however, why do you complain about xdg-open, if that was innocent in the problem?

[Travis]

[SRGOM]

@mcepl you do realize that you're being obnoxious right? Chris is being patient and polite and the I've wasted too hours in my life with semi-maintained programs that I know fully well what works and what to do when it doesn't work . Xdg defaults mechanism is the crappiest piece of software I've seen across all 3 major desktop operating systems.

I challenge ou to write a succinct way to do one thing-

I want a single file that can be version controlled and stowed in my home-dir which will set default programs for extensions. I want it to take priority over anything else. Come back when you have this.

[James McCoy]

I use defaults.list. As an example:

$ cat ~/.local/share/applications/defaults.list
application/pdf=zathura.desktop
text/html=firefox.desktop
x-scheme-handler/http=firefox.desktop
x-scheme-handler/https=firefox.desktop

See also xdg-mime, which seems to be complementary (it recognizes the defaults.list data, but xdg-mime default ... modifies a different file).

[Marius Gedminas]

~/.local/share/applications/defaults.list is for applications you install into ~/.local (e.g. via flatpak user installs) to tell about what files they can handle.

~/.config/mimeapps.list is for user preferences meant to override defaults.list.

[SRGOM]

So can I version check-in defaults.list and then link ~/.local/share/applications/defaults.list to that? I remember that there was at least one file out of the 799 that xdg-defaults reads which was deleted and rewritten. I hope defaults.list isn't that? I can mark the other 798 read only if only it helps me get consistent behaviour . Or just edit whichever is the highest priority

[Blay263]

This doesn't work anymore on windows, was gx fix reverted??

[Shane-XB-Qian]

sorry jump in here for an old ticket, though the issue looks still there.
to who do not like the default behavior which download content first but not open url directly.

you can :
1, let g:netrw_nogx = 1
2, re-map gx to some cmd you like, or simply wrote a vimscript or python script or whatever you like.
3, done.

:) btw: i do not like that default behavior either.

[K.Takata]

2, re-map gx to some cmd you like, or simply wrote a vimscript or python script or whatever you like.

As I wrote in another issue, I recommend open-browser for this purpose.

[Shane-XB-Qian]

cool, so the issue probably can be closed. 👍

[Christian Brabandt]

no, because it is still an issue with the default netrw plugin.

[Yee Cheng Chin]

Hi, sorry to stir an old bug up, but seems like gx for URL's is broken again after November (5ef1c6a), when Netrw was updated to a new version (v166) and therefore removing the patch. Now it just seems to do something odd (I'm on macOS) and download a temp file and try to open something in the browser but not the website I want.

Is it possible to re-apply the patch as mentioned in #4738 (comment)?

I guess the other question I have is I read through the thread and it seems like there's some philosophical design reason and benefit that necessitated breaking gx (which is a regression because it used to work which I feel is antithetical to the Vim philosophy of not breaking existing keybindings/features) but I'm not sure what it is.

[boykoatwork]

Write small plugin for replace gx functionality in Vim. It's still raw and dirty, but...

https://github.com/tengucrow/interceptor

[vik]

[JulesC2020]

Hi,
I have this issue on Archlinux. I compiled from the sources then, the issue is also in HEAD.
For me, latest upstream release v8.0.1850 is working
The very next one: v8.1.0000 has issue with gx.
but with another message this time:
this version of netrw requires vim v7.4 with patch 213

But I don't see code changes for netrw between those two version, no obvious one. (i am not a reference, pls check)

I don't have this issue with neovim, though.
My terminal interprets the urls so, I could just click but the idea is to fix a regression, isn't it?

thank you!

[K.Takata]

The very next one: v8.1.0000 has issue with gx.
but with another message this time:
this version of netrw requires vim v7.4 with patch 213

It is a totally different issue and already fixed in v8.1.0001.

[JulesC2020]

The very next one: v8.1.0000 has issue with gx.
but with another message this time:
this version of netrw requires vim v7.4 with patch 213

It is a totally different issue and already fixed in v8.1.0001.

I might express myself incorrectly. The issue is still gx unable to open link in external browser and messing around with buffers.

v8.0.1850 is working
everything after this version were failing. v8.1.0000 is the first one with this message but it does not matter. Since v8.1.0000 , gx is not working.

I have just tested with the new HEAD, same issue: gx seems to download the content into a temporary file and open it with your $WEBROWSER which is messed up because of no css.
Then going back to vim with another buffer: sometime empty, sometime the content of the html page, sometime an old buffer...

[Christian Brabandt]

please check your version of netrw (e.g. :e $VIMRUNTIME/autoload/netrw.vim). And please also check with the latest netrw version from Charles: http://www.drchip.org/astronaut/vim/index.html#NETRW

Thanks.

[JulesC2020]

Hello Chris,

It just crossed my mind actually and yes, the version included in vim's GIT repo is v168. I have used the one from neovim ( netrw.vim v165 ) and it works. I see that Charles's version is even more recent, v170 (7th June 2020), did not test it.

Good version so fare: v156, v165
Why the embedded plugins are not in sync with upstream ? Actually, why such plugins are not developed in the same codebase ?
It is pretty admitted that netrw is part of VIM.

Of course, I could replace the gx with another custom call but the regression here is quite problematic.

Thank you again, chris!

[cecamp]

I don't have access to a mac anymore, and netrw v170g works just fine with ftp under linux. Please look at :help netrw-debug and get a debugging trace of what happens when you use gx; you then may send it to me if you wish.

[Shane-XB-Qian]

vim v8.0.1850 ( netrw.vim v156 ) and neovim (v165)

just a fyi: though it was same version num as v165 in neovim, but probably that was a modified version of netrw in it, we'v seen neovim modified netrw, or unless it had rollbacked later then.
// i do not have neovim, but just discussed it at some ticket some months ago.

[cheap glitch]

Can we get a fix for this? It seems updating netrw to the latest version (v170) in the repo would solve this.
Thanks!

[Leo Razoumov]

The bug is still present in vim-8.2.1456 (macvim-165). It is so annoying!

[K.Takata]

Netrw v170 is now included. 1d59aa1#diff-3abb9629535900f0c07a312231e18483R4
Closing.

[K.Takata]

Closed #4738.

[Leo Razoumov]

@k-takata : The "gx" bug seems to be still present. Please, see macvim-dev/macvim#1094 for details.

[K.Takata]

Hmm, reopening then.

[K.Takata]

Reopened #4738.

[Metin Yazici]

A small workaround until it's fixed (adapted from):

if has('macunix')
  function! OpenURLUnderCursor()
    let s:uri = matchstr(getline('.'), '[a-z]*:\/\/[^ >,;()]*')
    let s:uri = shellescape(s:uri, 1)
    if s:uri != ''
      silent exec "!open '".s:uri."'"
      :redraw!
    endif
  endfunction
  nnoremap gx :call OpenURLUnderCursor()<CR>
endif

[Travis]

@strboul dude, amazing. This has been literally driving me insane for months.

[K.Takata]

Okay, I also confirmed that this has been broken also on Windows since Netrw v165.
The problem is that Netrw tries to download the specified URL first, then execute the platform specific open command ("open" on macOS, "rundll32" on Windows) even the command can handle a URL directly.

Before v165, it seems that a URL was somehow determined as not a remote file, then netrw#BrowseX() worked nice unexpectedly.

[K.Takata]

I created PR #7188.
@cecamp Please check this.

[Charles Campbell]

K.Takata (Vim Github Repository) wrote:
>
> I created PR #7188 <https://github.com/vim/vim/pull/7188>.
> @cecamp <https://github.com/cecamp> Please check this.
>
>
I no longer have access to a Mac; I thus depend on someone to forward a
patch to me which addresses the problem.
Chip Campbell

[grr]

looks like this is stalled. how do we get this pushed forward?

[K.Takata]

It seems that my patch has been (partly) included in the prerelease version: http://www.drchip.org/astronaut/vim/#NETRW.
If @cecamp thinks it is ready for releasing, he will send the files to Bram. But he doesn't think it is ready?

[Charles Campbell]

K.Takata (Vim Github Repository) wrote:
>

> It seems that my patch has been (partly) included in the prerelease
> version: http://www.drchip.org/astronaut/vim/#NETRW.

> If @cecamp <https://github.com/cecamp> thinks it is ready for

> releasing, he will send the files to Bram. But he doesn't think it is
> ready?
>

That part of the update is ready; however, netrw is failing a test I
have and I'm working on it.
Chip

[J. Erik]

Improved version of @strboul suggestion.

• Open the url under the cursor, not the first url in the line
• Fixes issues with ? in url, that causes to not open the url

if has('macunix')
  function! OpenURLUnderCursor

()
    let s:uri = expand('<cWORD>')
    let s:uri = substitute(s:uri, '?', '\\?', '')
    

let s:uri = shellescape(s:uri, 1)
    if s:uri != ''
      silent exec "!open '".s:uri."'"
      :redraw!
    endif
  endfunction
  nnoremap gx :call OpenURLUnderCursor()<CR>
endif

—

[Aurélien Ooms]

Improved version of @strboul suggestion.

* Open the url under the cursor, not the first url in the line

* Fixes issues with ? in url, that causes to not open the url

if has('macunix')
  function! OpenURLUnderCursor()
    let s:uri = expand('<cWORD>')
    let s:uri = substitute(s:uri, '?', '\\?', '')
    let s:uri = shellescape(s:uri, 1)
    if s:uri != ''
      silent exec "!open '".s:uri."'"
      :redraw!
    endif
  endfunction
  nnoremap gx :call OpenURLUnderCursor()<CR>
endif

Does not work when the URL is in parentheses.

[M Imam Pratama]

Improved regex to match URL inside single or double quotes:

function! OpenURLUnderCursor()
	let s:uri = expand('<cWORD>'

)
	let s:uri = matchstr(s:uri, "[a-z]*:\/\/[^ >,;)'\"]*")

	" let s:uri = substitute(s:uri, '?', '\\?', '')
	" let s:uri = shellescape(s:uri, 1)
	if s:uri != ''

		silent exec "!xdg-open '".s:uri."' > /dev/null"

		:redraw!
	endif
endfunction
nnoremap gx :call OpenURLUnderCursor()<CR>

I don't need the commented lines in zsh.

About the > /dev/null redirection, this is what happens on my machine (ubuntu) without it:

That happens when the default browser is chrome.

[Matěj Cepl]

And now it works again (in neovim). Damn!

[SeniorMars]

I just tested this again today, and it seems I still get this error on linux. The suggestions in this chat work, but I wish it would be patchd.

[Arseny Nasokin]

Neovim has its own fork?

[Matěj Cepl]

Neovim has its own fork?

No, it just periodically refreshes by applying the particular vim patch (as usual, neovim tries hard not to fork).

[JulesC2020]

really, it is not yet fixed ? I am astonished to continue to receive mail about this. Honestly, it makes me sad to see how broken part of viM is.

such feature should have its own C implementation in the main codebase than viM. We have to stop to rely on brittle vimscript.

I have to compile my own vim (ok it's fast) and use the right vimscript version but come on, it is not sustainable.

all the best, pal!

[Christian Brabandt]

such feature should have its own C implementation in the main codebase than viM. We have to stop to rely on brittle vimscript.

In the spirit of open source, you may contribute and become famous :)

[JulesC2020]

such feature should have its own C implementation in the main codebase than viM. We have to stop to rely on brittle vimscript.

In the spirit of open source, you may contribute and become famous :)

funny, there is especially this quote in netrwPlugin.vim file
" But be doers of the Word, and not only hearers, deluding your own selves"
(James 1:22 RSV)

I am a vim user, not vim maintainer, I can't afford to learn this codebase right now, netwr is a 13k LoC beast. :/

do you know if there were discussion about a proper file manger implementation for vim?

[Shane-XB-Qian]

#4738 (comment)

neednot 13k LoC, but just remap gx to whatever you like, sometime the style did not match everyone like, specially looks vi vim born with Linux..
Since many Lang api or just some shell cmd offered way to open link, as long as that link can be opened.
you can :
1, let g:netrw_nogx = 1
2, re-map gx to whatever you like.
3, done.
// and someone above offered patch as well.

// and this ticket looks kept too long... :)

[JulesC2020]

you missed the point :)
I do have a workaround, that's not the question. Here, we see that netrw is just not reliable.

i agree on the last top sentence.

[Matěj Cepl]

Since many Lang api or just some shell cmd offered way to open link, as long as that link can be opened.
you can :
1, let g:netrw_nogx = 1
2, re-map gx to whatever you like.

Thank you for this:

1. I missed g:netrw_nogx, which is useful
2. I don’t think <cword> is the right expression. <cfile> seems to be more appropriate.

So, my final solution is:

" Doesn't work because of gh#vim/vim#4738

" let g:netrw_browsex_viewer='setsid osurl'

let g:netrw_nogx=1



" This is just temporary workaround until the above issue is truly

" resolved.

" https://github.com/vim/vim/issues/4738#issuecomment-830820565

" https://bugzilla.suse.com/show_bug.cgi?id=1173583

" (https://bugzilla.suse.com/show_bug.cgi?id=1173583)

" gh#vim/vim#4738

function! OpenURLUnderCursor()

  let s:uri = expand('<cfile>')

  echom "s:uri = " . s:uri

  if s:uri != ''

    silent exec "!osurl '".s:uri."'"

    :redraw!

  endif

endfunction

nnoremap gx :call OpenURLUnderCursor()<CR>

(of course, you should replace calling [osurl](https://gitlab.com/mcepl/vim-suse-changes/-/blob/master/osurl) in my case with anything you want).

[K.Takata]

I recommend tyru/open-browser.vim.

[Valentin Hristev]

OS: MacOSX 11.2.3
NeoVim: NVIM v0.5.0-dev+1318-g61aefaf29

That was working for me for the past years but now it seems after some upgrade and I upgrade the entire system + neovim + all plugins. I end up here.

When i use 'GBrowse' i get an error below:
**warning** (netrw) shell signalled an error

Strange is that URL looks fine if i copy it and paste it in the browser is working.

'gx' also does not work. I tried setting

let g:netrw_http_cmd='open' but without success.

[Matěj Cepl]

let g:netrw_http_cmd='open' but without success.

Not sure about :GBrowse, but otherwise I just gave up ... see #4738 (comment) .

[Lifepillar]

I haven't been using netrw for a long time (at least with macOS), but gx was useful, so I retained it. In my vimrc I have something like the following, which works for me in Vim 8.2.2874 and macOS 11.3.1:

filetype plugin on
let g:loaded_netrwPlugin = 1
nnoremap gx :call netrw#BrowseX(expand((exists("g:netrw_gx")? g:netrw_gx : '<cfile>')),netrw#CheckIfRemote())<cr>

Try it with vim -N -i NONE -u gx.vim, where gx.vim is the script above. At the time, I had copied the definition for gx from netrw's source code. Comparing with the current version, the only difference I see is that netrw#GX() has been added.

Removing netrw#GX() from the argument of netrw#CheckIfRemote() in $VIMRUNTIME/plugin/netrwPlugin.vim, line 84, seems to fix the issue (Vim 8.2.2874). No idea what the consequences of this change are, though.

[y]

Is it expected behavior that using 'gx' will cause a modified file to be saved when 'autowrite' is set?

[rmagillxyz]

I haven't been using netrw for a long time (at least with macOS), but gx was useful, so I retained it. In my vimrc I have something like the following, which works for me in Vim 8.2.2874 and macOS 11.3.1:

plugin on

let g:loaded_netrwPlugin = 1
nnoremap gx :call netrw#BrowseX(expand((exists("g:netrw_gx")? g:netrw_gx : '<cfile>')),netrw#CheckIfRemote())<cr>

Try it with vim -N -i NONE -u gx.vim, where gx.vim is the script above. At the time, I had copied the definition for gx from netrw's source code. Comparing with the current version, the only difference I see is that netrw#GX() has been added.

Removing netrw#GX() from the argument of netrw#CheckIfRemote() in $VIMRUNTIME/plugin/netrwPlugin.vim, line 84, seems to fix the issue (Vim 8.2.2874). No idea what the consequences of this change are, though.

@lifepillar I've been messing with this for a while, and found this thread from a thread pointing here which was created in 2017 and starting to think I would never figure it out but alas! thanks mate.

Also, here is the code in lua for anyone switching over:

vim.cmd('filetype plugin on')
vim.g.loaded_netrwPlugin = 1
vim.api.nvim_set_keymap('n', 'gx', ":call netrw#BrowseX(expand((exists('g:netrw_gx')? g:netrw_gx : '<cfile>')),netrw#CheckIfRemote())<cr>", {noremap = true, silent = true})

[Felipe Contreras]

**error** (netrw) not a netrw-style url; netrw uses protocol://[user@]hostname[:port]/[path])

I get the same here (Arch Linux).

So sad that in 2021 vim is unable to call one program with one argument, which happens to be one of the most standardized things in history (a URL).

[Felipe Contreras]

really, it is not yet fixed ? I am astonished to continue to receive mail about this. Honestly, it makes me sad to see how broken part of viM is.

That's because vim has an archaic development process, and in particular parts of code maintained by Charles E. Campbell (web site), who is not precisely responsive.

It took me six years to get a patch merged to vim because he is the maintainer of sh.vim. (I sent the first patch in 2014).

I could probably dig deep into the code and find the proper fix, but why bother if the patch is going to be ignored? (just like my last patch)

It's easier to just give on that software and find a workaround.

[rmagillxyz]

really, it is not yet fixed ? I am astonished to continue to receive mail about this. Honestly, it makes me sad to see how broken part of viM is.

That's because vim has an archaic development process, and in particular parts of code maintained by Charles E. Campbell (web site), who is not precisely responsive.

It took me six years to get a patch merged to vim because he is the maintainer of sh.vim. (I sent the first patch in 2014).

I could probably dig deep into the code and find the proper fix, but why bother if the patch is going to be ignored? (just like my last patch)

It's easier to just give on that software and find a workaround.

What's your opinion of vim vs neovim? Neovim is much more active.

[Matěj Cepl]

What's your opinion of vim vs neovim? Neovim is much more active.

I use neovim, but it doesn’t help you here (or with sh.vim), because neovim uses runtime (i.e., non-C files) from vim, and tries very hard not to make much difference between the two unless necessary. So, for example, this is the neovim ticket as well.