Don't block use of user defined text objects

[alerque]

I don't know if this is the right solution because there may be ramifications to allowing mappings through here, but this change solves the problem I was having, fixing #199. With these changes and the text objects I have setup such as q for curly double quotes and Q for curly single quotes, I can dow do things like:

• Change “double̝ quotes” to single with csqQ → Change ‘double quotes’ to single
• Change “double̝ quotes” to star with csq*→ Change *double quotes* to star
• Change (in̝ parenthesis) to quotes with cs(q→ Change “in parenthesis” to quotes

These (along with things like dsq to delete surrounding quotes) were ignored before even if the surround mapping AND text object existed.

By contrast the solution presented in #107 only works for arbitrary single characters where the left and right side of the surround use the same character and the 'surround target' character is an exact match for the one being searched for. It doesn't work for more complex surround objects such as mixed matched pairs that have special text objects.

[tpope]

The ramification is that this breaks setups that remap e.g. d (unusual, but not unheard of, particularly among Dvorak users). You can probably achieve your goal by defining global script maps:

nnoremap <SID>d d

I'm not sure off the top of my head how to invoke them from norm; you might need to stitch the script id in yourself (see :h ).

[Porges]

I tried this by using s:SID from the <SID> docs and using the remapping. It works for some things (yss" followed by cs"q, dsq works), but seems to have broken other mappings like ] or }. I wonder if there is a bad interaction with targets.vim?

Here's my attempted fix: https://github.com/Porges/vim-surround/commit/3c49004bc3aa5edb3140b6ab9b1c3b889fdd74b0

[Maelan]

I’d love to have this feature working. It would be useful not only for “literature” quotes, but also for things like:

/* comment */
begin ... end

[alerque]

I'm not sure what the status is here. Five years later I'm still using my forked version of this plugin so that it plays nice with vim-textobj-quote. As the newly appointed maintainer of the latter I'd be happy to fix this from that side if it could be done, but I still don't see how, and stabbing in the dark I haven't found any other way of fixing it from this end. If anybody has enough expertise to suggest how this could be resolved from either end I'm all ears.

[Vftdan]

To avoid triggering maps in unwanted places I create a <Plug>-noremap for the sequence, I used this approach in my fork that implements the same functionality: Vftdan@f0183c3 .

The ramification is that this breaks setups that remap e.g. d (unusual, but not unheard of, particularly among Dvorak users). You can probably achieve your goal by defining global script maps:

nnoremap <SID>d d

I'm not sure off the top of my head how to invoke them from norm; you might need to stitch the script id in yourself (see :h ).

Should a configuration variable be created for cases when someone doesn't want this (omap respecting) behavior?

[Konfekt]

The typical idiom for a mapping where you rely on one mapping being remapped map and the other not is, as proposed above, something like

onoremap               <SID>(underline) _
nmap          <expr> gww  'gw' . v:count1 . '<SID>(underline)'

to remap the non-remapped map as well.

Instead of stitching in the SID itself for use with :normal, easier would be to use a <plug> mapping, but for me simply using <SID> has been working fine:

exe norm "gw\<SID>(underline)

instead