Em sexta-feira, 23 de fevereiro de 2018 15:51:35 UTC-3, ZyX escreveu:
> 2018-02-23 18:21 GMT+03:00 Renato Fabbri:
> > 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.
>
> I do not understand what you are trying to say. I know that `<leader>`
> is expanded only once, but that is not helpful: SourcePre is run only
> before some script, so if your script is not the last one you have to
> create SourcePre command which will set mapleader to one value for
> your script and to another value for everything else.
so that I understand what you are saying
(I apologize if being slow),
does this sequence of commands
have the expected behavior in your Vim:
" {{{ should make aj ec banana, bj ec apple, ak ec orange, bk not mapped:
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>
" }}}
>
> > ((
> > :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?
>
> You cannot change semantics of `<Leader>` or e.g. evaluate `mapleader`
> as an expression, so this fact is not helpful. And you also can't add
> any new keys. So "not completely" is not very helpful.
exe g:mapleader
evaluates mapleader as an expression, but I don't see the case to do this.
let mapleader += 'banana'
should work to add new keys, but I again fail to see the point.
"not completely" there is in the sense of being dependent also on
the scripts/commands parsed at runtime, not at compile time.
Apologies for not being palpable.
>
> >
> >>
> >> >
> >> >
> >> > 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.
> >
> > --
> > --
> > 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.
No comments:
Post a Comment