Re: Use and meaning of

Reply to message «Re: Use and meaning of <plug>»,
sent 01:52:21 26 July 2011, Tuesday
by esquifit:

> As you see, there are three steps involved:
> 1) key binding to <plug>foo
> 2) map <plug>foo to <SID>something
> 3) map <SID>something to :call <SID>bar()
>
> as opposed to two steps in your example:
> 1) key binding to <plug>foo
> 2) map <plug>foo to :call <SID>bar()
>
> I wonder what good is the extra way over <SID>something.
I do not see any good here. Ask whoever has written the help. I personally use
neither this three-stepped solution nor proposed two-stepped: in my case frawor
takes care about customization ability.

> I don't quite catch it. Can't a user customize
>
> map <unique> <Leader>YX :call MyscriptMyfunction()<CR>
>
> by simply remapping it?
1. hasmapto('<Plug>...') is shorter.
2. hasmapto('<Plug>...') allows you to do refactoring without touching user
options: it can be kept more stable.
3. Nobody said that there cannot be <SID> in the {rhs}.
4. Customizing here requires using an `after' directory, maparg() to get {rhs},
:unmap to remove the mapping. It cannot be as simple as
map ,yy <Plug>MyscriptMymappingname
5. Never use *map without `nore' in such cases. In <Plug> solution you know that
{rhs} is remapped and you know exactly what it is remapped to and second mapping
has `nore'. Here you don't know whether {rhs} is remapped or not.

> It seems that this the whole point of <plug>. The special symbol is
> guaranteed not to match any typed sequence, therefore it cannot
> interfere with other mappings defined by the user or by other plugins.
> It still fails, if I'm not utterly wrong, to address the uniqueness of
> the symbol (that's apparently why the vim help suggests adhering to a
> convention like <plug>ScriptnameFunctionname). Specifically, nothing
> can prevent two plugin authors from deciding that their functions
> would be externally accessible through the same symbol <plug>foo.
> Therefore they are expected to think of a 'foo' that is likely to be
> as
> unique as, say, d9531003-d4e8-40e5-abaf-f69afd4b6872, in which case I
> don't see the benefit of prepend <SID> to the function pointed to; it
> would be the same to call the function
> MyVeryUniqueNameOrAtLeastIThinkSo_foo(), except of course for
> readability.
Function <SID>Foo defined is plugin plugin/foo.vim and function <SID>Foo defined
in plugin plugin/foobar.vim will have different real names (vim does not have
non-global functions): for example <SNR>10_Foo and <SNR>11_Foo (if
plugin/foo.vim was sourced just before plugin/foobar.vim). You do not need to
invert unique prefix here by yourself and it is guaranteed that for different
plugins <SID> will expand to different strings. The point of <SID> here is to
1. avoid a possibility of name collisions on an empty place: one possibility
(string after <plug>) is enough and
2. tell that function is for internal use only.

Original message:
> On 24 Jul, 01:21, ZyX <zyx....@gmail.com> wrote:
> > Reply to message «Use and meaning of <plug>»,
> > sent 03:02:27 24 July 2011, Sunday
> >
> > by esquifit:
> > > map <unique> <Leader>XY <Plug>MyscriptMyfunction
> > > noremap <unique> <script> <Plug>MyscriptMyfunction <SID>Myfunction
> > > noremap <SID>Myfunction :call <SID>Myfunction()<CR>
> >
> > Where have you seen such code? Most of time it is
> >
> > if !hasmapto('<Plug>MyscriptMyfunction')
> > map <leader>XY <Plug>MyscriptMyfunction
> > endif
> > noremap <Plug>MyscriptMyfunction :call <SID>Myfunction()
>
> Except for the 'if', which I intentionally left out for clarity, the
>
> lines come from the following sources:
> :he using-<Plug>
>
> ----------------
> 21 if !hasmapto('<Plug>TypecorrAdd')
> 22 map <unique> <Leader>a <Plug>TypecorrAdd
> 23 endif
> ..
> 24 noremap <unique> <script> <Plug>TypecorrAdd <SID>Add
> ..
> 28 noremap <SID>Add :call <SID>Add(expand("<cword>"), 1)<CR>
>
> Hacking VIM - p.167
> -------------------
> if !hasmapto('<Plug>MyscriptMyfunctionA')
> map <unique> <Leader>a <Plug>MyscriptMyfunctionA
> endif
> noremap <unique> <script> <Plug>MyscriptMyfunctionA
> <SID>MyfunctionA
> noremap <SID>MyfunctionA :call <SID>MyfunctionA()<CR>
>
> As you see, there are three steps involved:
> 1) key binding to <plug>foo
> 2) map <plug>foo to <SID>something
> 3) map <SID>something to :call <SID>bar()
>
> as opposed to two steps in your example:
> 1) key binding to <plug>foo
> 2) map <plug>foo to :call <SID>bar()
>
> I wonder what good is the extra way over <SID>something.
>
> > It does make sense as it allows user to customize the mappings.
>
> I don't quite catch it. Can't a user customize
>
> map <unique> <Leader>YX :call MyscriptMyfunction()<CR>
>
> by simply remapping it?
>
> > > Wouldn't the following line solve the problem given the same
> > > assumptions (instead of the three above)?
> > >
> > > map <unique> <Leader>YX :call MyscriptMyfunction()<CR>
> >
> > Never write this:
> > 1. User may have exchanged meanings of `:' and `;' or did something
> > else which will break the above. User is unlikely to remap
> > <Plug>MyscriptMyfunction though and in :noremap
> > <Plug>MyscriptMyfunction :call <SID>Myfunction() it is safe due to
> > `nore'.
>
> It seems that this the whole point of <plug>. The special symbol is
> guaranteed not to match any typed sequence, therefore it cannot
> interfere with other mappings defined by the user or by other plugins.
> It still fails, if I'm not utterly wrong, to address the uniqueness of
> the symbol (that's apparently why the vim help suggests adhering to a
> convention like <plug>ScriptnameFunctionname). Specifically, nothing
> can prevent two plugin authors from deciding that their functions
> would be externally accessible through the same symbol <plug>foo.
> Therefore they are expected to think of a 'foo' that is likely to be
> as
> unique as, say, d9531003-d4e8-40e5-abaf-f69afd4b6872, in which case I
> don't see the benefit of prepend <SID> to the function pointed to; it
> would be the same to call the function
> MyVeryUniqueNameOrAtLeastIThinkSo_foo(), except of course for
> readability.
>
> > 2. It does not allow user to customize plugin.
>
> As expressed above, I don't see why.