Vim: Resolve ambiguity of key mappings in a specific buffer to avoid timeout

Question

I use plugin "Buffet", and there's local-to-buffer mapping "d" to delete buffer under cursor.

I also use plugun Surround, and there's global mapping "ds" that means "delete surround".

So, when i press "d" in the Buffet's window, Vim waits for a second before execute mapping "d". I know about &timeoutlen, but i don't want to change it. So that I want to resolve ambiguity of key mappings for "d" in the Buffet's window to avoid timeout to delete a buffer.

To resolve the problem, I want to unmap in Buffet window all the mappings that start with "d", but except Buffet's own mappings. How can i do that?

P.S. I have read about maparg() and mapcheck(), but they seem not to be what i need, unfortunately.

Answer 1

It seems like i found the solution myself:

au BufEnter buflisttempbuffer* nunmap ds
au BufLeave buflisttempbuffer* nmap   ds <Plug>Dsurround

I hoped that there's more universal approach (to remove really all mappings starting from "d"), but at this moment i failed to find it.

Even if i found out how to get all these mappings, unfortunately i can't do unmap <buffer> ds, because ds is a global mapping. I'm sure that i should be able to disable global mapping for some buffer, though. Vim is great but not perfect.

Well, it works for me now.

Answer 2

Now that the question has been "rephrased", this solution is no longer relevant, but I'll post it anyway since I spent a few minutes on it.

Here's a function that grabs the output of map <letter> and extracts the individual maps. Then it unmaps them all.

function! Unmap(leader)
    redir => maps
        sil exe "map " . a:leader
    redir END
    let maps_list = split(strtrans(maps),'\^@')
    if len(maps_list) > 1
        for this in maps_list
            let mapn = matchstr(this,"^\\w\\s*\\zsd\\w*\\>")
            exe "unmap " . mapn
        endfor
    endif
endfunction

Example usage: call Unmap("d"). This will remove all mappings that begin with d, leaving only Vim's defaults.

Disclaimer: this has not been rigorously tested. In particular I don't know how portable the \^@ character is, but that's how it looks on my (Win32) machine.