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?

Improve this question
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
    Commented 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
    Commented Sep 26, 2018 at 9:17
  • I think vim's guicursor only works in gui-mode. But neovim's works in terminal also.
    – 3N4N
    Commented 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
    Commented Sep 26, 2018 at 9:44
  • 1
    I raised github.com/tpope/vim-surround/issues/272
    – gib
    Commented Jan 6, 2019 at 22:26

1 Answer 1

Reset to default
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.

Improve this answer

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.