making custom <XYZ> key names for mappings

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

making custom <XYZ> key names for mappings

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>

thanks again,


--
Renato Fabbri
GNU/Linux User #479299

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: making custom <XYZ> key names for mappings

Nikolay Aleksandrovich Pavlov
2018-02-22 18:58 GMT+03:00 Renato Fabbri <[hidden email]>:

> 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 [hidden email].
> 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: making custom <XYZ> key names for mappings

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?

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 [hidden email].
> > 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: making custom <XYZ> key names for mappings

Nikolay Aleksandrovich Pavlov
2018-02-23 1:43 GMT+03:00 Renato Fabbri <[hidden email]>:

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

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

>
>
> 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 [hidden email].
>> > 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 [hidden email].
> 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: making custom <XYZ> key names for mappings

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.
((
: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 [hidden email].
> >> > 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 [hidden email].
> > 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: making custom <XYZ> key names for mappings

Nikolay Aleksandrovich Pavlov
2018-02-23 18:21 GMT+03:00 Renato Fabbri <[hidden email]>:

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

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

>
>>
>> >
>> >
>> > 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 [hidden email].
>> >> > 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 [hidden email].
>> > 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 [hidden email].
> 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: making custom <XYZ> key names for mappings

Renato Fabbri
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 [hidden email].
> >> >> > 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 [hidden email].
> >> > 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 [hidden email].
> > 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: making custom <XYZ> key names for mappings

Nikolay Aleksandrovich Pavlov
2018-02-26 4:20 GMT+03:00 Renato Fabbri <[hidden email]>:

> 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 [hidden email].
>> >> >> > 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 [hidden email].
>> >> > 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 [hidden email].
>> > 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 [hidden email].
> 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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: making custom <XYZ> key names for mappings

Renato Fabbri


On Mon, Feb 26, 2018 at 5:04 AM, Nikolay Aleksandrovich Pavlov <[hidden email]> wrote:
2018-02-26 4:20 GMT+03:00 Renato Fabbri <[hidden email]>:
> 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.

Now, that is a piece of work. (thanks)
Well, if ec apple orage example above works,
this should work as well (seems you are not agreeing that it works).
(such line have to be on the file where the mappings are defined,
and it has to be called myscript.vim, but thats that).

And now I better see the point in the SourcePre stuff you where talking about,
the hack shout work by parsing expand("%:p").

I am using a similar solution (less file and autocommand dependent)
that you helped me develop in this thread.
It is working (perfectly smooth).
The plugins each have the mappings with
individual leader and localleader and it is like heaven.
I should post back when things are sane again
(much restructuring on my .vim tree because of many reasons
beyond leader keys).



>
> 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 [hidden email].
>> >> >> > 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 [hidden email].
>> >> > 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 [hidden email].
>> > 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 [hidden email].
> 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 a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/Y5hhjayfaUM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.



--
Renato Fabbri
GNU/Linux User #479299

--
--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.