5

I like having netrw loaded for browsing directory contents when I open '.' and for downloading webpages when I split http://host/path, but it's really getting in the way of opening files with gF or ^wf when netrw doesn't understand the protocol.

I'm editing a sizable library of Salt statelists for a project, and they have a lot of Salt filesystem URLs in the configs (salt://path/path/file) that I'd like to be able to split into with gF and ^wf. There's no hope for netrw understanding these as built-ins, which is acceptable. Some local config would be required to explain to vim where the files really are.

I'd like a local config to teach netrw to open them or some other method of bypassing netrw so I can open them.

I tried to use:

set includeexpr=substitute(v:fname, "salt://", "location/of/file_root/").

It took me quite a while to figure out includeexpr was never being applied. What seems to happen is that netrw handles the URL, decides it's a filename, and fails to execute includeexpr.

What are my options here? disable netrw in BufEnter for files I'm likely to see the salt urls? preemptively fire includeexpr before netrw can get to it? Also, where would you set events that happen before netrw fires?

  • 6
    You should could clarify what you're doing. What exactly is "split http://whatever"? What is this salt:// thing? When and where isn't gF working? See: How to create a Minimal, Complete, and Verifiable example?. The easier it is for people to see the problem in their own local environment, the better chance you have of getting an answer (right now, I'm not even sure how to reproduce the problem). – Martin Tournoij Sep 2 '16 at 16:52
  • I second Carpetsmoker. I'm also confused exactly what your problem is. It sounds like gF isn't working, but I'm not aware of netrw handling URL's. So I'm not sure how to try and replicate your working environment. – Tumbler41 Sep 2 '16 at 22:15
  • Alright. It seemed pretty clear to me, but I cleaned it up as best I could. The particulars of what salt://blah/blah really means are irrelevant, and I think are made clear by the example includexpr. The problem is that it's never applied. I'm really looking for a way to either handle the URL before netrw handles it, or handle the URL after netrw handles it. Either would work, but the things I'm trying aren't working. – jettero Sep 4 '16 at 11:33
0

Like your other responders, I'm not at all sure exactly what it is that you're desirious of doing.

If you're using gf on a http://host/path, then you want to disable netrw responding to the http:// string. To do that, I suggest writing your own plugin that is a copy of augroup Network ... augroup END without the http:// support. Include a au BufReadCmd http://* to do whatever it is that you want done. You can find this code in netrwPlugin.vim.

If you want to use gf on a salt:// path, then netrw shouldn't be involved at all, as salt:// isn't in the BufReadCmds (in augroup Network). In that case, please describe/give an example where this netrw interference occurs.

In looking back at your new & improved question, it appears to me that netrw has nothing to do with your issue. That's because the "salt://*" url is not one of those that netrw sets up with Buf(Read|Write)Cmds. However, there's a clue in that: try setting up your own BufReadCmd! As an example:

au BufReadCmd salt://*  :exe "r ".substitute(expand(""),'salt://\(.*\)',expand("$HOME").'/\1','')

Change the path to suit your needs, of course. You may also wish to have a BufWriteCmd; I'll leave that as an exercise.

Not the answer you're looking for? Browse other questions tagged or ask your own question.