Em quinta-feira, 22 de fevereiro de 2018 22:05:29 UTC-3, ZyX  escreveu:
> 2018-02-23 1:43 GMT+03:00 Renato Fabbri:
> > 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?
> 
> No, you set mapleader for *all* scripts, either to default or to
> something else. There is no SourcePost for some reason; an alternative
> is messing with SourceCmd, but this is harder to do right in general,
> but easier to use for specific use cases.

hum... try this:
let mapleader = 'a'
nn <leader>j :ec 'a banana'<CR>
let mapleader = 'b'
nn <leader>j :ec 'an apple'<CR>
let mapleader = 'a'
nn <leader>k :ec 'an orange'<CR>

which work 100% fine here.
((
:version                                                                        
                                                                                
          
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jan  6 2018 23:48:57)              
                                                                                
          
Included patches: 1-1428                                                        
                                                                                
          
Compiled by renato@xps                                                          
                                                                                
          
Huge version without GUI.
)) + python 2-3 and termguicolors


> 
> >
> > Anyway, I understood that it is not needed to define
> > extra <XXX> key names, but is it possible within Vim standard
> > capabilities?
> 
> What is possible? All XXX in `<XXX>` are defined at compile time only,
> you can’t evaluate expression inside XXX or something like this.

Ok, so question closed here.
Notice that <XXX> is surely not completely
defined in compile time, for we use
g:mapleader to set <leader> at run time.

Am I following things right?

> 
> >
> >
> > 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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to