Vim-pathogen: vim starts in replace mode

[andreasmischke]

Since using pathogen, vim always starts in replace mode (Shift-R from normal mode).
How can I disable that behaviour?

My environment: Windows 7, cygwin, vim 7.3, pathogen 2.2

[tpope]

Pathogen seems an unlikely culprit. Are you sure you have this problem even with no other plugins installed?

[andreasmischke]

I emptied the /bundles directory (~/.vim/bundles) and the problem still occurs.
When I comment out the line execute pathogen#infect() in .vimrc, the problem is solved.

If it helps, here my .vimrc: http://pastebin.com/qKg8b197

I should mention that I am a fairly n00b to vim and bash...

[tpope]

You could try changing :execute to :call but that's really a shot in the
dark.

On Fri, Jul 26, 2013 at 2:38 AM, Andreas Mischke
[email protected]:

I emptied the /bundles directory (~/.vim/bundles) and the problem still
occurs.
When I comment out the line execute pathogen#infect() in .vimrc, the
problem is solved.

If it helps, here my .vimrc: http://pastebin.com/qKg8b197

I should mention that I am a fairly n00b to vim and bash...

—
Reply to this email directly or view it on GitHubhttps://github.com/tpope/vim-pathogen/issues/102#issuecomment-21604003
.

[andreasmischke]

That did not help, I am afraid.
Perhaps the error is caused by some other settings in my bash. Therefore never mind, I will investigate that problem later when there is time for that.
Until then I will just install the 1-2 packages manually. At least on that machine.

[aroneous]

For what it's worth, I get the same issue on Windows 8 with cygwin, but only when running with the 'mintty' terminal that comes with cygwin. Starting cygwin bash under a Windows command shell and opening vim from there works fine. Commenting out the Pathogen call stops the problem for me as well.

[Wyatts]

I can also confirm seeing this issue with MinTTY and nowhere else. I tried setting an autocommand to just hit escape, but couldn't get it to work.

I'm pretty sure I didn't have this problem a couple months ago (though the vintage of the pathogen I was using at the time is unclear), so this may be a more recent change?

EDIT, it's a dirty, dirty hack, but what DID work (as far as I can tell) is to have it like this in your vimrc:

nnoremap R <Esc> " Disable replace mode
call pathogen#infect()
au BufEnter * nnoremap R R " Reenable it after entering the buffer

[tpope]

So a few other things to try:

• Check :set rtp? with no plugins installed, and make sure pathogen hasn't found plugins where you don't expect.
• Try call pathogen#infect('bundle/*'). This will add * paths directly to the runtime path, which mostly works the same, but short circuits some of the machinery in pathogen.vim (i.e., less to go wrong).

[tpope]

Oh, and regarding the "more recent change" part, if you could find a commit where this started happening, that would make it super easy to track down the problem.

[Wyatts]

My Windows workstation has been a glorified SSH/screen terminal for a while (because the IT department loves rebooting the blame thing and losing all my state), but having gotten the bugmail, I probed a little more and noticed with an (almost) empty config it wasn't happening. Bisecting my own config, I tracked it to this particular bit:

autocmd BufReadPost *
    \ if line("'\"") > 1 && line("'\"") <= line("$") |
    \ exe "normal! g`\"" |
    \ endif

(This is from the vimrc_example.vim that comes with the standard vim distribution. I'm probably not alone in having based my own vimrc on that example when I started using it years ago.)

In particular, this line:

    \ exe "normal! g`\"" |

I found that it _seems_ to work as expected if I change it to:

autocmd BufEnter *

...but I'm not familiar enough with the nuances to know what possible negative side effects that has. Regardless, as long as it remains in its original form in the upstream example, this will probably keep coming up (to say nothing of people who haven't touched that line in a decade.)

I'll see if I can find a chance to git bisect over lunch and figure out where it started.

[tpope]

Good detective work. If anyone else could confirm, that would be great.

One thing that might be good to rule out is pathogen#cycle_filetype(), which is called by pathogen#infect(). You can skip it by directly calling pathogen#incubate() instead.

[Wyatts]

And there it is! I experimentally replaced pathogen#infect() with pathogen#cycle_filetype(), and it started in replace mode just like that.

I fooled with it a little more and was amused to find that if you change the condition in cycle_filetype() to if(g:did_load_filetypes), it (apparently) only starts in replace mode every _other_ time you start vim. (No really, what.)

I gather the intent of that function is to re-detect file type in the event pathogen loaded more filetype definitions from the plugin path, so would it be sufficient to make the invocation au BufEnter * call pathogen#cycle_filetype()?
I tried that and can verify it still executes, and it _doesn't_ cause me to start in replace mode (I'm no vimscript guru, so it's a bit unclear which buffer event would be the right one, here).

[tpope]

I think the next logical step is to bisect $VIMRUNTIME/filetype.vim and find out what the real culprit is. Start by emptying it and seeing if the problem persists.

Buffer events make no sense for an event that's supposed to happen on startup.

[Wyatts]

Well, I _emptied_ $VIMRUNTIME/filetype.vim and... it still happened.

Okay, so not buffer events. Some other event? (I'm having an awful time finding clear documentation on what happens when in vim startup.)

[tpope]

The event you're looking for is VimEnter, but I'd rather not resort to that as I want reloading the vimrc to retrigger filetype cycling, plus it's unclear to me that filetype cycling _after_ loading all the user's autocmds won't cause trouble.

Looking at the Vim source, ftdetect.vim plus optionally ftplugin.vim and indent.vim are run on filetype on, and ftoff.vim plus optionally ftplugof.vim and indoff.vim are run on filetype off. The optional ones are contingent on which features are enabled: check the output of a bare :filetype. As I read it, those 6 files are the only possible effects of the two commands, so emptying all 6 should give pretty conclusive results of if we're on the right track. (But note it's possible to have multiples of any of these files, so check :scriptnames to make sure you got them all.)

[tpope]

BTW now that we know the cause, a workaround to skip the filetype cycling call pathogen#incubate().

[ljani]

Just to let you know, I'm seeing a similar problem (vim randomly starts in replace mode) in a totally separate environment with vim-autoclose, if it helps debugging this issue. Removing vim-autoclose fully fixes the problem for me.

I'm using spf13-vim and thus Vundle to install the plugin, not pathogen.

On Cygwin and Cygwin x64:

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Apr 23 2014 23:56:13)
Included patches: 1-264
Compiled by <[email protected]>
Huge version without GUI.  Features included (+) or not (-):
+acl             +farsi           +mouse_netterm   +syntax
+arabic          +file_in_path    +mouse_sgr       +tag_binary
+autocmd         +find_in_path    -mouse_sysmouse  +tag_old_static
-balloon_eval    +float           +mouse_urxvt     -tag_any_white
-browse          +folding         +mouse_xterm     -tcl
++builtin_terms  -footer          +multi_byte      +terminfo
+byte_offset     +fork()          +multi_lang      +termresponse
+cindent         +gettext         -mzscheme        +textobjects
-clientserver    -hangul_input    +netbeans_intg   +title
+clipboard       +iconv           +path_extra      -toolbar
+cmdline_compl   +insert_expand   +perl/dyn        +user_commands
+cmdline_hist    +jumplist        +persistent_undo +vertsplit
+cmdline_info    +keymap          +postscript      +virtualedit
+comments        +langmap         +printer         +visual
+conceal         +libcall         +profile         +visualextra
+cryptv          +linebreak       +python/dyn      +viminfo
+cscope          +lispindent      +python3/dyn     +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con      +lua/dyn         +rightleft       +windows
+diff            +menu            +ruby/dyn        +writebackup
+digraphs        +mksession       +scrollbind      -X11
-dnd             +modify_fname    +signs           -xfontset
-ebcdic          +mouse           +smartindent     -xim
+emacs_tags      -mouseshape      -sniff           -xsmp
+eval            +mouse_dec       +startuptime     -xterm_clipboard
+ex_extra        -mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    -xpm
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/etc"
 f-b for $VIMRUNTIME: "/usr/share/vim/vim74"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H   -I/usr/include/ncursesw  -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/usr/src/ports/vim/vim-7.4.264-1.x86_64/build=/usr/src/debug/vim-7.4.264-1 -fdebug-prefix-map=/usr/src/ports/vim/vim-7.4.264-1.x86_64/src/vim74=/usr/src/debug/vim-7.4.264-1 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc   -L.   -L/usr/local/lib -Wl,--as-needed -o vim.exe        -lm -lelf    -lncursesw -liconv -lintl   -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--enable-auto-image-base -fstack-protector  -L/usr/lib/perl5/5.14/x86_64-cygwin-threads/CORE -lperl -ldl -lcrypt

[Oberon00]

I had the same symptoms on Ubuntu/gnome-terminal but tracked it down to this line in my vimrc:

nnoremap <silent> <Esc> :nohlsearch<CR>

It seems like remapping escape only leads to problems.

[defndaines]

For me, the problem seems to be inherent to using vim 7.4. I've tried playing with all the fixes and hacks on this page, and none of them solve the problem. In the meantime, I'm just forced to stay on vim 7.3. I see the problem on OS X and Ubuntu 14.04.

[Carlodf]

Same issue with:
nnoremap <silent> <Esc> :nohlsearch<cr>
remapping to something else fixed the issue.
Personally I replaced it with
nnoremap <silent> <leader>/ :nohlsearch <cr>

[Zabanaa]

Thanks a lot @Carlodf I did just that and it fixed the issue for me.

I'm on xubuntu 16.04 - gnome terminal - vim 8

cheers

[AstroProfundis]

I can confirm this issue been fixed as @Carlodf suggested. Thanks a lot!

I'm running ArchLinux with vim 8.0.628, and the issue is fixed by commenting out this line in my .vimrc:
nnoremap <esc> :nohl<cr>

So the question now becomes: how can I continue use <ese> as :nohl if that's my favorite?

[tpope]

If you really want to get to the bottom if it, you'll need to tear apart pathogen.vim itself and try to figure out what line causes the issue.

[noytzach]

@Carlodf's fix works for me. Thanks.

commenting out my nmap of \

[magks]

@AstroProfundis
I replaced it with
nnoremap <esc><esc> :nohl<cr>
and this worked for fixing the replace mode issue while still being somewhat close to the mapping. Just a doubletap on the escape instead of one. Not too bad if the capsLock key has been swapped with escape on your keyboard.

[goerz]

For what it's worth, I've had the same problem of nnoremap <silent> <Esc> :nohlsearch<cr> causing vim to start in REPLACE mode (unrelated to pathogen). This only happened for TERM=xterm*.

I was able to get around the problem by appending the contents of https://gist.github.com/goerz/36015f27c2a5423c64a5f9dc03865f2c to my vimrc.