2018-02-26 4:20 GMT+03:00 Renato Fabbri <renato.fab...@gmail.com>: > 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> > " }}}
I know what mappings this will result in. I do not understand how this sequence is *relevant* to the discussion. > >> >> > (( >> > :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 g:mapleader = '(expand("<sfile>") =~# ''\mmyscript\.vim$''?"a":"b"')' will not make `<Leader>` expand to `a` for `myscript.vim` and `b` for everything else. > > let mapleader += 'banana' > should work to add new keys, but I again fail to see the point. Neither there is a way to create `<banana>` key in runtime. > > "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+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. > > -- > -- > 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.