Use and meaning of <plug>
Locked
 
|
|
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() It does make sense as it allows user to customize the mappings. > 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'. 2. It does not allow user to customize plugin. Original message: > What is the actual value of using <plug>? I've always seen the same > pattern: > > map <unique> <Leader>XY <Plug>MyscriptMyfunction > noremap <unique> <script> <Plug>MyscriptMyfunction <SID>Myfunction > noremap <SID>Myfunction :call <SID>Myfunction()<CR> > > As far as I understand, <plug> allows users of a (third party) plugin > to define their own mappings to symbols defined in the plugin as > <SID>Something. This is apparently necessary because the actual value > of <SID> is not known in advance and it could change in the course of > time. However, in order to make use of <plug>, the plugin author is > expected to craft a name which is globally unique, for instance by > following the convention '<Plug> scriptname mapname', so that this > name does not clash with other from other plugins. In the example > above, this would correspond to '<plug>MyscriptMyfunction'. But then, > what good is the whole <SID> thing, if the plugin author is still > expected to use unique global identifiers (here MyscriptMyfunction)? > Wouldn't the following line solve the problem given the same > assumptions (instead of the three above)? > > map <unique> <Leader>YX :call MyscriptMyfunction()<CR> > > I'm evidently missing the main point and I'd be most grateful if > somebody could show me the light :-) |
signature.asc (205 bytes)
|
|
|
Reply to message «Re: Use and meaning of <plug>»,
sent 08:08:49 24 July 2011, Sunday by Tony Mechelynck: > The whole <SID> thing is meant to allow creating mappings and functions > which are only visible from within the script where they were created > (i.e., not in other scripts, not at the command-line, but can be used in > autocommands defined in that script). <SID> can also be used in the > {rhs} of a mapping created in the same script, to allow some kind of > restricted access to script-local functions. Wrong. <SID> mappings are normally visible: check out :map <SNR>: for me it shows two mappings from align and one from vimrc. Same for functions: they all are global, even anonymous ones. s: for functions and <SID> for functions and mappings both only create prefix that should be unique. If you get somewhere a script number and substitute <SID> with <SNR>{SID}_ everything will work normally: call <SNR>107_dosurround('"') removes surrounding '"' in my vim. Same technique works for {lhs}, but if you redefine script functions in this way it will be assigned that script context where it was defined, not that mentioned after <SNR>. You can't redefine anonymous functions, but you can use call() to call them without having a reference. The only script-local thing is s: dictionary: I do not know how to access it without a debugger or without passing it somewhere. Original message: > On 24/07/11 01:02, esquifit wrote: > > What is the actual value of using<plug>? I've always seen the same > > pattern: > > > > map<unique> <Leader>XY<Plug>MyscriptMyfunction > > noremap<unique> <script> <Plug>MyscriptMyfunction<SID>Myfunction > > noremap<SID>Myfunction :call<SID>Myfunction()<CR> > > > > As far as I understand,<plug> allows users of a (third party) plugin > > to define their own mappings to symbols defined in the plugin as > > <SID>Something. This is apparently necessary because the actual value > > of<SID> is not known in advance and it could change in the course of > > time. However, in order to make use of<plug>, the plugin author is > > expected to craft a name which is globally unique, for instance by > > following the convention '<Plug> scriptname mapname', so that this > > name does not clash with other from other plugins. In the example > > above, this would correspond to '<plug>MyscriptMyfunction'. But then, > > what good is the whole<SID> thing, if the plugin author is still > > expected to use unique global identifiers (here MyscriptMyfunction)? > > Wouldn't the following line solve the problem given the same > > assumptions (instead of the three above)? > > The whole <SID> thing is meant to allow creating mappings and functions > which are only visible from within the script where they were created > (i.e., not in other scripts, not at the command-line, but can be used in > autocommands defined in that script). <SID> can also be used in the > {rhs} of a mapping created in the same script, to allow some kind of > restricted access to script-local functions. > > <SID> is guaranteed to be different for every script: in the first > script sourced it means <SNR>1_ then in the second script <SNR>2_ etc. > > <Plug> is global, meant for mappings etc. that can be seen outside the > script. > > See also ":help using-<Plug>" for a discussion of the difference between > <SID> and <Plug>. Also see the preceding page or so of help text for an > example similar to what you quoted above, and how to use it. > > > map<unique> <Leader>YX :call MyscriptMyfunction()<CR> > > > > I'm evidently missing the main point and I'd be most grateful if > > somebody could show me the light :-) > > In the end, you will only see the light if enlightenment comes to you > from within. All we can do is try to help. > > > Best regards, > Tony. |
|
|
|
|
|
|
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. 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. 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 <[hidden email]> 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. |
Loading...
| Powered by Nabble | Edit this page |