New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[netrw v162h] gx does not bring up the url in a browser #1386

Open
xc1427 opened this Issue Jan 16, 2017 · 12 comments

Comments

Projects
None yet
7 participants
@xc1427
Copy link

xc1427 commented Jan 16, 2017

Environment:
gvim 8.0.45 64bit on windows 10 or windows 7.
netrw v162h

Bug description:
gx (|netrw-gx|) executed on an URL downloads the URL as a file.
I didn't set g:netrw_gx and g:netrw_browsex_viewer variable.

Expected behavior:
gx brings up the URL in a browser.

@cecamp

This comment has been minimized.

Copy link
Collaborator

cecamp commented Jan 16, 2017

Please try the directions in :help netrw-debug. I don't have a windows 10 system myself to work with.

@xc1427

This comment has been minimized.

Copy link

xc1427 commented Jan 16, 2017

cecamp commented 7 hours ago
Please try the directions in :help netrw-debug. I don't have a windows 10 system myself to work with.

FYI, I also tested on a windows 7 PC, which shows the same problem. I will try the debug later.

@xc1427

This comment has been minimized.

Copy link

xc1427 commented Mar 5, 2017

@cecamp Disable all the other plugin does not solve the problem. So I activated Decho and I found the problem is from netrw.
Actually, gx in visual mode did bring up the url in browser. Then I compared the debug information between gx in normal mode and visual mode.

In visual mode:
netrw#BrowseXVis calls netrw#CheckIfRemote without parameter, letting remote=0. As a result, fname is assigned by a:fname, which is the URL.

In normal mode:
On the contrary, netrw#CheckIfRemote is called with parameter, letting remote=1. In consequence, netrw#BrowseX creates a local copy (netrw.vim 162j :5087), making fname renamed by a tmp file.

*Solution*
The simple solution is to remove the parameter passed into the function CheckIfRemote at line 84 in the file vimfiles/plugin/netrwPlugin.vim. So this line should be:

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

An URL is indeed a remote resource. But here it should be treated as a local one as in gx-visual.

Debug info
I paste below the debug information when url http://chez-syl.fr/2012/03/bonnes-pratiques-jquery/ is operated by gx.

  • Debug normal gx
 netrw#CheckIfRemote() a:0=1 {
|curfile<http://chez-syl.fr/2012/03/bonnes-pratiques-jquery/>
|return netrw#CheckIfRemote 1 }
netrw#BrowseX(fname<http://chez-syl.fr/2012/03/bonnes-pratiques-jquery/> remote=1) {
|remote: a:remote=1: create a local copy of <http://chez-syl.fr/2012/03/bonnes-pratiques-jquery/> ~53
|basename<chez-syl> ~59
|newname <C:/Users/cxi/AppData/Local/Temp/chez-syl.tmp> ~60
|newname=C:/Users/cxi/AppData/Local/Temp/chez-syl.tmp
|fname<C:/Users/cxi/AppData/Local/Temp/chez-syl.tmp> ~79
|exten<fr/2012/03/bonnes-pratiques-jquery/> netrwFileHandlers#NFH_fr/2012/03/bonnes-pratiques-jquery/():exists=0 ~80
|windows ~134
|return netrw#BrowseX }
  • Debug visual gx
netrw#BrowseXVis() {
|@@<http://chez-syl.fr/2012/03/bonnes-pratiques-jquery/> ~4
|netrw#CheckIfRemote() a:0=0 {
||curfile<Git_repo/tabcdn_simulmo/README.md>
||return netrw#CheckIfRemote 0 }
|netrw#BrowseX(fname<http://chez-syl.fr/2012/03/bonnes-pratiques-jquery/> remote=0) {
||fname<http://chez-syl.fr/2012/03/bonnes-pratiques-jquery/> ~79
||exten<fr/2012/03/bonnes-pratiques-jquery/> netrwFileHandlers#NFH_fr/2012/03/bonnes-pratiques-jquery/():exists=0 ~80
||windows ~134
||return netrw#BrowseX }
|return netrw#BrowseXVis }

@xc1427 xc1427 changed the title [netrw v162h] gx does not bring up the url in a browser [netrw v162k] gx does not bring up the url in a browser Mar 25, 2017

@xc1427 xc1427 changed the title [netrw v162k] gx does not bring up the url in a browser [netrw v162h] gx does not bring up the url in a browser Apr 16, 2017

@xc1427

This comment has been minimized.

Copy link

xc1427 commented Apr 16, 2017

News on version v162k:
gx(visual) now works the same way as gx(normal). So gx(visual) does not either bring up the URL in a browser if you highlights an URL like http://www.free.fr and do gx.

This is because the function netrw#BrowseXVis, which is executed by gx(visual), is slightly modified in v162k:

" See file vimfiles/autoload/netrw.vim:5327
call netrw#BrowseX(@@,netrw#CheckIfRemote(@@))

which was called without checking if remote in previous version:

call netrw#BrowseX(@@,netrw#CheckIfRemote())

Remarks on the unified gx behavior:
When we do gx (either visual or normal) on a string having a pattern as xxx://, netrw considers it as a remote file. However on windows this string should be consider as a local file if you want a browser to open it.
So if you want to open a URL without modifying the source code of netrw, visual select an URL excluding the http:// part, then use gx to open it. The fault with this solution is that it cannot handle the URL which can only be opened by https protocol.

@cecamp

This comment has been minimized.

Copy link
Collaborator

cecamp commented Apr 16, 2017

@xc1427

This comment has been minimized.

Copy link

xc1427 commented Apr 17, 2017

That's because the "without parameter" call was incorrect.

I agree with you. And I think gx is meant to handler other url-like string such as ftp, scp, etc as well.

You should get a message: error not a netrw-style url; netrw uses
protocol://[user@]hostname[:port]/[path])

I didn't get this error message but some bizarre split window behavior . This is another story about netrw#ErrorMsg() not working correctly. Nevertheless, this message should have been printed.

gx is intended to handle urls like http://xxx.whatever/ (note that
trailing slash), and it needs to know whether the call is local or remote.

The question is how netrw should handle a http(s):// string. The actual behavior on win10 is that it considers http(s):// a remote call, then downloads the web page, renames it as xxxx.tmp and tries to open this tmp file. But this behavior does not make any sense. While, if http(s):// is seen as local, then it can be directly handled by a browser and I think that makes sense.

I think some finer condition test should be written inside the netrw#BrowseX function.

@astyagun

This comment has been minimized.

Copy link

astyagun commented Nov 24, 2017

I see the problem on macOS as well:

netrw

Environment:

  • macOS High Sierra 10.13.1 (17B48)
  • MacVim 8.0.1272 (142)
  • netRW v162: Sep 19, 2016
@mmikeww

This comment has been minimized.

Copy link

mmikeww commented Dec 13, 2017

in Gvim7.4 on Windows, pressing gx over a URL would successfully open Chrome. First I would get a quick cmd window that would disappear and then the browser would open

in Gvim8, I'm seeing the cmd window open and close, and then quickly seeing this error in the Vim command line:

"NetrwMessage" --No lines in buffer--

and then the error disappears and it opens up a horizontal split

@k-takata

This comment has been minimized.

Copy link
Member

k-takata commented Dec 13, 2017

I personally use open-browser.vim for this purpose.
I think it is stable and tested well. Moreover, it works on many platforms including macOS, Linux, Windows, etc.

@pinggit

This comment has been minimized.

Copy link

pinggit commented Jan 13, 2018

is there a fix to this issue yet?
I just tested the fresh new cygwin install that contains vim8. seem issue and no luck.
will have to try the open-browser.vim plugin...

@jsatk

This comment has been minimized.

Copy link

jsatk commented May 29, 2018

I'm still getting this issue. I'd love to not have to not install yet another plugin.

I'm willing to help diagnose and code to help fix the issue.

@cecamp

This comment has been minimized.

Copy link
Collaborator

cecamp commented May 31, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment