Re: making custom key names for mappings

Well, from your comments, i put a:

let g:aall = mapleader
" let mapleader = '<Space>'
if exists("g:aa_leader")
let mapleader = g:aa_leader
el
let mapleader = 'anything'
en


before the mappings, and a:

let mapleader = g:aall

after them and it is all ok.
(only these mappings use the
temporarily defined leader key.)

I did not understand how SourcePre
would be used.
Something like:
au SourcePre mymappings.vim let [g:fooleader, mapleader] = ['something', mapleader]

in combination with a somewhat SourcePost event to
set mapleader to fooleader?

Anyway, I understood that it is not needed to define
extra <XXX> key names, but is it possible within Vim standard
capabilities?


Em quinta-feira, 22 de fevereiro de 2018 18:22:51 UTC-3, ZyX escreveu:
> 2018-02-22 18:58 GMT+03:00 Renato Fabbri:
> > leader and localleader are the standard, so one might
> > have conflicts between scripts because
> > all of them use leader and localleader.
> >
> > how would you define, say
> > <coolleader>, which you set to the
> > leader by default,
> > but can be changed to any key
> > sequence (including c-v derived).
> >
> > ==
> > ideally, I would have a command mkKeyName with which to define
> > <coolleader> such as
> >
> > :mkKeyName -default=leader coolleader
> >
> > and might set it to anything such as
> > se mapcoolleader=^[
> > se mapcoolleader=
> > se mapcoolleader!
> > se mapcoolleader!=<Space>
> >
> > (this implies that one would also able to use
> > :setlocal mapcoolleader ??
> >
> > and use it in your mappings
> > as in
> > nnoremap <coolleader>B :call MyCoolFunction()<CR>
>
> This is not needed, there is `:execute` as something requiring changes
> to plugin code. E.g. my plugins (on my frawor framework) allow
> defining plugin-specific leader.
>
> To override `mapleader` for plugins which are not nice enough to allow
> defining plugin-specific leader there is SourcePre event.
>
> I personally find mapleader and maplocalleader as quite *incomplete*
> thing. For plugins much better idea would be key-value store: e.g. in
> place of
>
> nnoremap <Plug>(FooPluginDoBar) :call foo#bar()<CR>
> nnoremap <Plug>(FooPluginDoZab) :call foo#zab()<CR>
>
> nmap <Leader>fb <Plug>(FooPluginDoBar)
> nmap <Leader>fz <Plug>(FooPluginDoZab)
>
> (last two possibly surrounded by `if !hasmapto(…)|endif`) one would write just
>
> mapdefineprefix FooPlugin <Leader>f
> nnoremap <:FooPlugin:DoBar(b)> :call foo#bar()<CR>
> nnoremap <:FooPlugin:DoZab(z)> :call foo#zab()<CR>
>
> and Vim will handle actually substituting values like this: each
> `<:prefix:mapname(default)>` expands into a concat of two strings:
>
> 1. The rhs of the first `:mapdefineprefix` command with lhs equal to `prefix`.
> 2. The rhs of the first `:mapdefine` command or the `default` value if
> no `:mapdefine` commands with lhs equal to `prefix:mapname` were
> issued. Inside `default` `<>` are good as long as they are balanced,
> various special characters like `)` may be entered via something like
> `<Char-41>`.
>
> In both cases using bang clears the prefix, so next non-banged command
> will define it (normally it is ignored).
>
> E.g. in this case if user wants mappings of foo plugin start with `,o`
> and not `<Leader>f` all he needs would be putting
>
> mapdefineprefix FooPlugin ,o
>
> into the vimrc (requirement: before sourcing actual plugin). If
> additionally he thinks that `DoZab` command is easier to run with
> `,oo` he would need
>
> mapdefine FooPlugin:DoZab o
>
> (requirement is the same).
>
> Currently plugins may do this on top of `:execute`, but nobody
> bothers. I normally want this functionality to e.g. make NERDCommenter
> mappings all start with `,c` (no, redefining `<Leader>` for all
> plugins does not sound like a good idea; `SourcePre` is useful, but
> still feels like a hack) or "undefine" (i.e. prefix with something you
> would never type, e.g. `<Plug>XXXIWouldNeverTypeThisXXX`) mappings for
> plugins I install for functionality other then mappings (not everybody
> is nice enough to have g:NERDCreateDefaultMappings setting).
>
> >
> > thanks again,
> >
> >
> > --
> > Renato Fabbri
> > GNU/Linux User #479299
> > labmacambira.sourceforge.net
> >
> > --
> > --
> > You received this message from the "vim_use" maillist.
> > Do not top-post! Type your reply below the text you are replying to.
> > For more information, visit http://www.vim.org/maillist.php
> >
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "vim_use" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to vim_use+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.