On Wed, Sep 30, 2009 at 2:27 AM, Andy Wokula <[email protected]> wrote: > > Hari Krishna Dara schrieb: >> On Tue, Sep 29, 2009 at 5:35 PM, Kana Natsuno <[email protected]> >> wrote: > > At least > :map <SNR> > > prints all my <SID> mappings, which include the script numbers, and I > can do e.g. > > :nn <SNR>15_yank :call <SNR>15_yank()<CR> > > at the command line to re-execute what was previously defined by a > script as: > > :nn <SID>yank :call <SID>yank()<CR>
This is not a "feature" per se, you are simply finding all those maps
that have an <SID> in the front. This is not the case that we are
trying to point out. Consider these two samples:
:nmap <script> <F12> <Plug>SomeScriptLocal
:inoremap <expr> <Tab> <SID>expandTab()<CR>
If you capture these using all the current means and recreate them,
they would end up completely different and non-functional.
>
>> If we can extend the :map command to accept an optional scriptID as
>> <script:SID>, then we could output map commands with the original SID
>> in place, but then there are two issues:
>
> The functionality is already there (?).
Are you referring to the <script:SID> format already being there? I
just checked, it is not there. You could of course call script local
functions using the <SNR>_ syntax, but it doesn't serve all cases.
I went ahead and did a POC for this feature and am attaching the
patch. This adds a new set of commands such as :dupmap (for "duplicate
mapping") and it seems to work nicely for a few simple cases that I
tried. The same do_map() function also handles abbreviations, so in
theory we could easily extend this to take care of abbreviations (by
adding commands such as :dupabbr) also, though not sure how useful
that would be.
The general usage of :dupmap is same as :map, and it behaves identical
to :map when {rhs} is missing. But with both {lhs} and {rhs}, it
copies the existing {rhs} value of the specified {lhs} into the
specified {rhs} (probably better referred to as {newlhs}).
Here is a list of all the new commands:
:dupmap {lhs} {rhs} |mapmode-nvo| *:dup* *:dupmap*
:ndup[map] {lhs} {rhs} |mapmode-n| *:ndup* *:nupmap*
:vdup[map] {lhs} {rhs} |mapmode-v| *:vdup* *:vupmap*
:xdup[map] {lhs} {rhs} |mapmode-x| *:xdup* *:xupmap*
:sdup[map] {lhs} {rhs} |mapmode-s| *:snor* *:supmap*
:odup[map] {lhs} {rhs} |mapmode-o| *:odup* *:oupmap*
:dup[map]! {lhs} {rhs} |mapmode-ic| *:dup!* *:dupmap!*
:idup[map] {lhs} {rhs} |mapmode-i| *:idup* *:iupmap*
:ldup[map] {lhs} {rhs} |mapmode-l| *:ldup* *:lupmap*
:cdup[map] {lhs} {rhs} |mapmode-c| *:cdup* *:cupmap*
I chose "dup" as the prefix instead of "copy" as suffix (like in
:mapcopy) to imitate the existing scheme (like :unmap and :noremap),
but couldn't call it "copymap" because that would conflict with :cmap
(unless the code is changed further). We can discuss if someone can up
with a better naming scheme that doesn't conflict with the existing
ones.
The documentation is not complete, the changes were intended to mainly
list the commands. Please give it a try and let me know what you
think.
--
Thanks,
Hari
>
> --
> Andy
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
dupmap.patch
Description: Binary data
