3

I'm somewhat ashamed to admit, the main reason I chose neovim over vim was it's native feature of changing cursor shape in different modes. For example, it uses vertical-bar in insert mode, block-shape in normal mode and horizontal-bar in operator-pending mode.

Until recently, I didn't know there was a cursor shape for operator-pending mode. This was because I'm using vim-surround. So, I now don't get the horizontal-bar when pressing c or d. Again, I'm ashamed to admit that this little thing bothers me. I peeked around in the plugin, but honestly I understand very little of it. The best solution I came up with was to remap the cs and ds keymaps to some Leader mappings, but that defeats the purpose of extending text objects.

So, I want to be able to see horizontal bar while I use default keymappings for vim-surround. How do I do that?

8
  • Are you sure that this is actually a neovim only feature? If you refer to the feature 'guicursor', this also exists in vim and this since version 5, see :h new-5. Just because it is 2018 and vim 5 was released 1998, this means for 20 years :-).
    – Hotschke
    Sep 25, 2018 at 14:33
  • 'guicursor' doesn't work in terminal in case of vim-8.0. Or I might have done something wrong. Help?
    – 3N4N
    Sep 26, 2018 at 9:17
  • I think vim's guicursor only works in gui-mode. But neovim's works in terminal also.
    – 3N4N
    Sep 26, 2018 at 9:22
  • I am pretty sure now that you are right: :h nvim-features, :h 'guicursor' and :h tui-cursor-shape in neovim mention this. I took the gui in 'guicursor' literally. However, I use mainly macvim gui. On the command line I never missed it. IMHO I'm somewhat ashamed to admit feels right to me (LOL). I am still not convinced to make the switch. What I feel ashamed about is: I want to have scroll bars in my gui window. That is the reason why I still use macvim and not github.com/qvacua/vimr#vimr--neovim-refined which otherwise seems to be a decent gui where CMD-X/C/V work.
    – Hotschke
    Sep 26, 2018 at 9:44
  • 1
    I raised github.com/tpope/vim-surround/issues/272
    – gib
    Jan 6, 2019 at 22:26

1 Answer 1

6

If vim-surround were implemented as 's' and 'S' (pseudo-)text-objects instead of operators ds, dS, cs, cS etc, this wouldn't be an issue. I don't know if there's some technical reason for this design choice, but anyway one solution would be to write your own wrapper omap:

let g:surround_no_mappings = 1
function! SurroundOp(char)
    if v:operator ==# 'd'
        return "\<plug>D" . a:char . "urround"
    elseif v:operator ==# 'c'
        return "\<plug>C" . a:char . "urround"
    elseif v:operator ==# 'y'
        return "\<plug>Y" . a:char . "urround"
    endif
    return ''
endfunction
omap <expr> s '<esc>'.SurroundOp('s')
omap <expr> S '<esc>'.SurroundOp('S')

I haven't tested it thoroughly but it seems like this would work. The first '<esc>' serves to cancel the currently pending s operator and the rest is just surround's normal mode mapping.

This wouldn't work for yss or ySs (separate mapping for surrounding the current line), for that you can just use a plugin which provides a line textobject, e.g. kana/vim-textobj-line, for example with vim-plug:

Plug 'kana/vim-textobj-line'
Plug 'kana/vim-textobj-user'

That way you can use ysil in place of yss.

This still doesn't cover all the vim-surround mappings, there is still xmap gS and the insert mode mappings. You could copy those mappings into your vimrc to get them.

This site is temporarily in read-only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .