Re: making custom key names for mappings

2018-02-26 4:20 GMT+03:00 Renato Fabbri <renato.fabbri@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+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.

--
--
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.