1

I use a plugin for todo.txt file (https://gitlab.com/dbeniamine/todo.txt-vim).

Because I mapped some d[other_letters] in my .vimrc and there's a \d mapped in the plugin, to avoid delays when I type \d I want to unmap my mapping only in the "todo" files.

The filetype assignement have complex rules, then I don't want to do autocommand on filename or extension, but I want to trigger it on filetype.
Then I wrote on my .vimrc:

augroup enter_todo au! autocmd FileType todo unmap <leader>db autocmd FileType todo unmap <leader>dp autocmd FileType todo unmap <leader>dc ... augroup END

The problem:
when I open a "todo" file everything is fine but if I open another todo file, or even if I open the plugin help (the name match the todo filetype assignement rules, nevertheless it is recognized as help file, I can see that in the status line) an error happens (see the picture below).
enter image description here

Why?

How could I fix this behaviour?

P.S.: don't helps...

Improve this question

2 Answers 2

Reset to default
2

The mapping are by default global (valid for all the buffers). If you unmap it you unmap it globally and the next time you try to do so Vim will complains that the mapping is not existing.

I would suggest you to define \db and its friend as a <buffer> mapping and only define them for non todo filetype.

augroup mymapping au! autocmd FileType * if &ft!='todo' | map <buffer><leader>db mymappingdb | endif autocmd FileType * if &ft!='todo' | map <buffer><leader>dp mymappingdp | endif autocmd FileType * if &ft!='todo' | map <buffer><leader>dc mymappingdc | endif ... augroup END

If you prefer using unmap you could do:

augroup mymapping au! autocmd FileType * map <buffer><leader>db mymappingdb autocmd FileType * map <buffer><leader>dp mymappingdp autocmd FileType * map <buffer><leader>dc mymappingdc " ... autocmd FileType todo unmap <buffer><leader>db autocmd FileType todo unmap <buffer><leader>dp autocmd FileType todo unmap <buffer><leader>dc augroup END
Improve this answer
11
  • I don't like this way because if I need to add other filetype or condition I need to mess with the original mapping. No way to unmap "per buffer"? Something like autocmd FileType todo unmap <buffer><leader>db? I tried that but it doesn't works. Commented Nov 28, 2023 at 14:21
  • I have proposed another version based on unmap (and <buffer> mapping). Commented Nov 28, 2023 at 18:03
  • 1
    Vivian, with this solution I got rid of all the errors if I open the faile and then try to reload (:e), but the lag after the typing of \d is still here. I can't understand why. Commented Dec 4, 2023 at 8:35
  • 1
    What is the result of the :verbose nmap \d command after you have reloaded your todo file? Commented Dec 4, 2023 at 11:15
  • 1
    GREAT! Thanks to your "kind of magic" I discovered that in the mists of time I mapped another \d (\data), and that wasn't unmapped. SOLVED! Commented Dec 5, 2023 at 15:36
1

That plugin uses <LocalLeader> mappings, not <Leader> mappings.

If you don't define the global variables mapleader and maplocalleader, then <leader> and <localleader> are both assumed to be \. That is why the plugin's mapping clash with yours: your <leader> and the plugin's <localleader> are identical.

Defining maplocalleader to something else than what you use for <leader> should remove the conflicts you are experiencing:

let maplocalleader = " "

The above theoretically gives you two "leaders": one for your own mappings, the default \, and another one for your plugins, <Space>, which means no conflict anymore.

This looks good on the surface, but the way <[local]leader> is implemented lacks flexibility and has been known for a long time to cause conflicts. For example, plugin A might be a good citizen and use <localleader>, but plugin B might use <leader>, which would conflict with your own mappings. Or you could have plugin C and plugin D both trying to be good <localleader>-mapping citizens but eventually defining the same mappings. Etc. You are also arbitrarily limited to two leaders, which is… sad.

I prefer to implement the "leader" mechanism on my own, without any <leader> or <localleader>. This gives me fewer opportunities for conflicts with plugins AND allows me to use as many "leaders" as I need (currently four).

In a perfect world, all plugins should expose their mappings as <plug> mappings anyway, and let their users decide if and what they want to map them to. That plugin does that to a certain extent, but not for every mapping. Too bad.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.