Add vimtex_mappings_prefix to configure leader mappings prefix

[wintermute-cell]

Would it make sense to you to allow users to customize the prefix used for <localleader> based mappings?

My Use-Case:
Usually, all <localleader> vimtex mappings reside under <localleader>l....
I like how the existing vimtex mappings are chosen, but <localleader>l is the prefix I have been using for language-server related mappings. To remedy this, I want to modify all existing vimtex keymaps to start with <localleader>v instead. Remapping each function manually would not feel like a clean solution to this.

Some Notes:

• I have never used VimScript, so i hope I am using g: and l: correctly.
• The l:prfx shorthand is just for readability, as g:vimtex_mappings_prefix would lengthen the lines a lot.
• Not sure if the newer .. or the older . is the preferred way to concat strings for this project.

[lervag]

Yes, this does not seem totally inappropriate. However, I think this should be expanded. If we allow to customize the prefix, then we should include <localleader> as well!

I think a cleaner way to do it would be something like this:

function! s:init_default_mappings() abort " {{{1
  if !g:vimtex_mappings_enabled | return | endif

  call s:map_prefixed(0, 'n', 'i', '<plug>(vimtex-info)')
  " ...
endfunction

" ...

function! s:map_prefixed(ftype, mode, lhs, rhs, ...) abort " {{{1
  return call('s:map_prefixed', [
        \ a:ftype,
        \ a:mode,
        \ g:vimtex_mappings_prefix . a:lhs,
        \ a:rhs
        \] + a:000)
endfunction

" }}}1

[lervag]

I believe it is safe to ignore the varargs stuff as well, which would simplify it to this:

function! s:map_prefixed(ftype, mode, lhs, rhs) abort " {{{1
  let l:lhs = g:vimtex_mappings_prefix . a:lhs
  call s:map_prefixed(a:ftype, a:mode, l:lhs a:rhs)
endfunction

[wintermute-cell]

Okay thanks for the feedback, that's a good idea; That even brings us back down below 80 characters for all lines!

I'm assuming you didn't mean to do a recursive call in your s:map_prefixed function?

Based on that assumption I implemented your suggestion and added a documentation entry.

[lervag]

Thanks!