When editing a file, I can issue q: to open a command palette and compose a Vim command using the full power of Vim's normal mode. I can also Alt+Tab to another window to look for information, then Alt+Tab back to Gvim to finish composing the Vim command.

When I'm in a netrw v171 buffer and use q: to compose a command, I can't Alt+Tab away and back. I get the following error message, and I also lose the Vim command that I'm composing:

 Error detected while processing FocusGained Autocommands
 for "*"..function <SNR>36_LocalBrowseRefresh:
 line   49:
 E11: Invalid in command-line window; <CR> executes, CTRL-C quits

I never had this problem with older Vim/netrw versions, though I admit that I haven't tracked which (I just update everything from Cygwin once in a while).

From the Vim help, I know that FocusGained is an event that triggers autocommands, and from the message above, they seem specific to LocalBrowseRefresh. I looked up SNRs and understand that they are used to deconflict names between scripts. I looked for LocalBrowseRefresh and FocusGained in netrwPlugin.vim, but they aren't present.

I have to admit to just rummaging around, and there could be lots of naivity in the way I'm going about it. All I'm seeking is to Alt+Tab back and forth from Gvim, even if I started from a netrw buffer and am in the midst of composing a command using q:. Is there a simple way to achieve this or to dig deeper into the cause?

If I can find the cause without taking a hiatus to become an expert in Vimscript, I can try hacking the netrw code. It's not the most reliable approach to a solution, but I've had some success with this for BufExplorer, though that was with tremendous time and effort, and it's my only experience in hacking a plugin. I also have to re-explore how to implement the hack every time I update Cygwin.

  • fun! s:LocalBrowseRequest() is actually defined in autoload/netrw.vim not in netrwPlugin.vim
    – filbranden
    Dec 16, 2023 at 21:55
  • 1
    Thanks. I perused that function, as well as instances of LocalBrowseRefresh, FocusGained, and netrw_events, but I can't infer a scheme from them. Fast browsing seems to crop up everywhere, but I haven't found anything about it. Ah well. I appreciate the pointer to the autoload file. Dec 16, 2023 at 23:14
  • I've rolled back your latest edit: answers belong below in Answers (self-answers are fine and encouraged), not in the Question body.
    – D. Ben Knoble
    Dec 18, 2023 at 14:03
  • Copy that. I'll add it to romail's answer. Dec 18, 2023 at 17:44

1 Answer 1


Let's start with the information we have:

  • you are using Netrw,

  • you open the command-line window,

  • you alt-tab away from Vim,

  • you alt-tab back to Vim,

  • which throws the following message at you:

    Error detected while processing FocusGained Autocommands
    for "*"..function <SNR>36_LocalBrowseRefresh:
    line   49:
    E11: Invalid in command-line window; <CR> executes, CTRL-C quits

From there we can already infer, as you did, that something wrong happened when Vim got the focus back. There apparently is at least one autocommand linked to the FocusGained event:

Error detected while processing FocusGained Autocommands
for "*"

that appears to call a LocalBrowseRefresh() function:

..function <SNR>36_LocalBrowseRefresh

where something is done at line 49 that shouldn't be done:

line   49:
E11: Invalid in command-line window; <CR> executes, CTRL-C quits

Now. Finding the offending code is relatively easy. The 36 in <SNR>36 refers to script number 36 in the output of :help :scriptnames. The exact order and path might be different on every system/machine, of course, but it should look something like:

21: ~/Applications/MacVim.app/Contents/Resources/vim/runtime/autoload/netrw.vim

Thankfully, Vim has an internal environment variable that abstracts away the specifics, $VIMRUNTIME, so the file where the error happens would be:


Here is line 49 of s:LocalBrowseRefresh() from that file:

exe bufwinnr(ibuf)."wincmd w"

The buffer number part of the command is actually irrelevant, here. It essentially does :wincmd w, or "move cursor to next window".

Now let's look at :help e11, emphasis mine:

The command-line window is not a normal window. It is not possible to move to another window or edit another buffer. All commands that would do this are disabled in the command-line window. Of course it is possible to execute any command that you entered in the command-line window. Other text edits are discarded when closing the window.

So that line 49 is trying to switch to another window, which is not possible in the command-line window.

Where to go from there?

The ideal solution would be to add a check somewhere in the offending function that would prevent that :wincmd w if the command-line window is opened.

FWIW, this test has been working fine for me:

&buftype ==# "quickfix" || &buftype ==# "nofile"

If you don't feel like doing it on your own, you can simply open an issue and wait for the author of Netrw to provide a new version with a fix.

  • Thank you, romainl. I didn't follow all of the logic, but most of it. Your fix worked. I summarized the resulting changes in the posted question. I appreciate the time you took to explain the script. Dec 18, 2023 at 5:11
  • Okay, we know there's a problem and we know the solution for it. Did anybody care to notify netrw maintainers so the rest of the world could benefit from it?
    – Friedrich
    Dec 18, 2023 at 7:28
  • That would be on OP, now.
    – romainl
    Dec 18, 2023 at 8:27
  • 3
    I created github.com/vim/vim/pull/13718 for this Dec 18, 2023 at 9:15
  • Thanks! Do I have to provide a description? P.S. I also submitted an "issue" to BufExplorer and am wondering whether I should do more to get all the information that I see on chrisbra's netrw issue. Dec 18, 2023 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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