copy a map (in order to restore it later)

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

copy a map (in order to restore it later)

Hari Krishna Dara-3

I need to be able to create an imap for <Tab> when my plugin is
toggled on, and unmap it when it is toggled off. What I would prefer
is to restore the previous map of <Tab> rather than simply unmap it,
but there is no straight-forward way to capture the existing map such
that it can be restored later. I first ventured into capturing the
output of :imap command and extract the <rhs>, but this won't work for
many scenarios (including the case of <script>). Even if Vim has a
command or function to output a script to recreate the map, it won't
work for all scenarios (e.g., the <script>), so I think what I need is
a command to create a "copy" of an existing map. Using such a command,
I can "copy" the existing map to a <Plug> map and when I need to
restore it, "copy" back to the original. The implementation of such a
copy should be simpler than other alternatives, assuming it involves
an actual copy of the underlying map data from the source. I think the
command can fall into the existing map family of commands, rather than
become a completely new command, something like "[nvxsoilc]mapc[opy]
<newlhs> <oldlhs>". Does anyone have a clue on the feasibility of such
a command or a better alternative? Is there a workaround that doesn't
required creating this new command?

--
Thanks,
Hari

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: copy a map (in order to restore it later)

Kana Natsuno

On Sun, 27 Sep 2009 14:58:25 +0900, Hari Krishna Dara <[hidden email]> wrote:

> I need to be able to create an imap for <Tab> when my plugin is
> toggled on, and unmap it when it is toggled off. What I would prefer
> is to restore the previous map of <Tab> rather than simply unmap it,
> but there is no straight-forward way to capture the existing map such
> that it can be restored later. I first ventured into capturing the
> output of :imap command and extract the <rhs>, but this won't work for
> many scenarios (including the case of <script>). Even if Vim has a
> command or function to output a script to recreate the map, it won't
> work for all scenarios (e.g., the <script>), so I think what I need is
> a command to create a "copy" of an existing map.

I agree with you on the idea.  It's not possible to perfectly copy
existing key mapping as far as I know - we can get the rhs of a key
mapping with maparg() or mpcheck() but it's not possible to determine
whether <buffer>/<expr>/<script>/<silent> were given for the key
mapping.  Alternative way is to parse output of :map commands, but it's
messy and it's not possible to determine whether <expr>/<silent> were
given.  Even if we can get the information on <expr>/<script>, it's not
possible to recreate the same key mapping for <script> one.

Recently I need to copy a key mapping to enhance my plugin.  It defines
another kind of key mappings which is expanded when multiple keys are
simultaneously pressed.  These key mappings can coexist with ordinary
key mappings even if both {lhs}es conflict with each other, but it's
a bit difficult or troublesome to resolve conflicts manually.  I want to
resolve conflicts automatically, but it's not possible to realize
without the way to copy existing key mappings.  (I also want a function
version of :map_l to get the information of a series of key mappings to
realize the feature.)


--
To Vim, or not to Vim.
http://whileimautomaton.net/


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: copy a map (in order to restore it later)

Andy Wokula
In reply to this post by Hari Krishna Dara-3

Hari Krishna Dara schrieb:

> I need to be able to create an imap for <Tab> when my plugin is
> toggled on, and unmap it when it is toggled off. What I would prefer
> is to restore the previous map of <Tab> rather than simply unmap it,
> but there is no straight-forward way to capture the existing map such
> that it can be restored later. I first ventured into capturing the
> output of :imap command and extract the <rhs>, but this won't work for
> many scenarios (including the case of <script>). Even if Vim has a
> command or function to output a script to recreate the map, it won't
> work for all scenarios (e.g., the <script>), so I think what I need is
> a command to create a "copy" of an existing map. Using such a command,
> I can "copy" the existing map to a <Plug> map and when I need to
> restore it, "copy" back to the original. The implementation of such a
> copy should be simpler than other alternatives, assuming it involves
> an actual copy of the underlying map data from the source. I think the
> command can fall into the existing map family of commands, rather than
> become a completely new command, something like "[nvxsoilc]mapc[opy]
> <newlhs> <oldlhs>". Does anyone have a clue on the feasibility of such
> a command or a better alternative? Is there a workaround that doesn't
> required creating this new command?

+1 from me.

It sounds too specific at the first glance, but will probably turn out
to be very useful!  I'd like to use :mapcopy for repmo.vim.

--
Andy

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: copy a map (in order to restore it later)

Hari Krishna Dara-3
In reply to this post by Kana Natsuno

On Sun, Sep 27, 2009 at 3:04 PM, Kana Natsuno <[hidden email]> wrote:

>
> On Sun, 27 Sep 2009 14:58:25 +0900, Hari Krishna Dara <[hidden email]> wrote:
>> I need to be able to create an imap for <Tab> when my plugin is
>> toggled on, and unmap it when it is toggled off. What I would prefer
>> is to restore the previous map of <Tab> rather than simply unmap it,
>> but there is no straight-forward way to capture the existing map such
>> that it can be restored later. I first ventured into capturing the
>> output of :imap command and extract the <rhs>, but this won't work for
>> many scenarios (including the case of <script>). Even if Vim has a
>> command or function to output a script to recreate the map, it won't
>> work for all scenarios (e.g., the <script>), so I think what I need is
>> a command to create a "copy" of an existing map.
>
> I agree with you on the idea.  It's not possible to perfectly copy
> existing key mapping as far as I know - we can get the rhs of a key
> mapping with maparg() or mpcheck() but it's not possible to determine
> whether <buffer>/<expr>/<script>/<silent> were given for the key
> mapping.  Alternative way is to parse output of :map commands, but it's
> messy and it's not possible to determine whether <expr>/<silent> were
> given.  Even if we can get the information on <expr>/<script>, it's not
> possible to recreate the same key mapping for <script> one.

Very well said and accurate to the point. I didn't realize that
|map-listing| has no information to indicate that a mapping involves
<expr> option. Not surprisingly, the below two appear the same in the
listing:

:map <expr> XX "XX"
:map XX
:map XX "XX"
:map XX

I think this was an oversight on the part of <expr> feature implementation.

>
> Recently I need to copy a key mapping to enhance my plugin.  It defines
> another kind of key mappings which is expanded when multiple keys are
> simultaneously pressed.  These key mappings can coexist with ordinary
> key mappings even if both {lhs}es conflict with each other, but it's
> a bit difficult or troublesome to resolve conflicts manually.  I want to
> resolve conflicts automatically, but it's not possible to realize
> without the way to copy existing key mappings.

I am not clear on your use case. Were you going to backup some maps
and unmap them to help resolve conflicts? Is the functionality of this
plugin somehow similar to my execmap plugin
(http://www.vim.org/scripts/script.php?script_id=598)?


> (I also want a function
> version of :map_l to get the information of a series of key mappings to
> realize the feature.)
>

That would be nice.

--
Hari


>
> --
> To Vim, or not to Vim.
> http://whileimautomaton.net/
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: copy a map (in order to restore it later)

iler.ml
In reply to this post by Hari Krishna Dara-3

On Sun, Sep 27, 2009 at 08:58, Hari Krishna Dara <[hidden email]> wrote:

>
> I need to be able to create an imap for <Tab> when my plugin is
> toggled on, and unmap it when it is toggled off. What I would prefer
> is to restore the previous map of <Tab> rather than simply unmap it,
> but there is no straight-forward way to capture the existing map such
> that it can be restored later. I first ventured into capturing the
> output of :imap command and extract the <rhs>, but this won't work for
> many scenarios (including the case of <script>). Even if Vim has a
> command or function to output a script to recreate the map, it won't
> work for all scenarios (e.g., the <script>), so I think what I need is
> a command to create a "copy" of an existing map. Using such a command,
> I can "copy" the existing map to a <Plug> map and when I need to
> restore it, "copy" back to the original. The implementation of such a
> copy should be simpler than other alternatives, assuming it involves
> an actual copy of the underlying map data from the source. I think the
> command can fall into the existing map family of commands, rather than
> become a completely new command, something like "[nvxsoilc]mapc[opy]
> <newlhs> <oldlhs>". Does anyone have a clue on the feasibility of such
> a command or a better alternative? Is there a workaround that doesn't
> required creating this new command?

Following commands saving mappings into file,
in a form readable back as map commands:

:mksession
:mkview
:mkexrc
:mkvimrc

Maybe you can manipulate their options to save *only*mappings ?
Or extract mappings from theiroutput files ?

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: copy a map (in order to restore it later)

Charles E Campbell Jr
In reply to this post by Hari Krishna Dara-3

Hari Krishna Dara wrote:
> I need to be able to create an imap for <Tab> when my plugin is
> toggled on, and unmap it when it is toggled off. What I would prefer
> is to restore the previous map of <Tab> rather than simply unmap it,
> but there is no straight-forward way to capture the existing map such
> that it can be restored later...[snip]
>  

You could see if cecutil's SaveUserMaps() and RestoreUserMaps()
functions that I wrote will help you.  In particular:

SaveUserMaps("n","","<tab>","hkd")
SaveUserMaps("bn","","<tab>","hkd")

will save normal mode mappings for <tab>s (if any); the first one for
ordinary normal-mode  maps, and the second one will append
<buffer>-qualified maps for <tab>.  A  RestoreUserMaps("hkd") will then
restore those maps (again, if any).  You can get a copy from my
website:  http://mysite.verizon.net/astronaut/vim/index.html#CECUTIL .

The "hkd" is a suffix used to differentiate save-map groups (ie. in
script space, there's a s:restoreusermaps_hkd variable used).

Regards,
Chip Campbell



--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: copy a map (in order to restore it later)

Kana Natsuno

On Wed, 30 Sep 2009 09:23:56 +0900, Charles E Campbell Jr <[hidden email]> wrote:
> You could see if cecutil's SaveUserMaps() and RestoreUserMaps()
> functions that I wrote will help you.

It uses maparg() to get information on existing key mapping,
but with maparg(), it's impossible to cover all scenarios
to use key mappings, as Hari Krishna Dara and I described.


--
To Vim, or not to Vim.
http://whileimautomaton.net/

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: copy a map (in order to restore it later)

Hari Krishna Dara-3

On Tue, Sep 29, 2009 at 5:35 PM, Kana Natsuno <[hidden email]> wrote:
>
> On Wed, 30 Sep 2009 09:23:56 +0900, Charles E Campbell Jr <[hidden email]> wrote:
>> You could see if cecutil's SaveUserMaps() and RestoreUserMaps()
>> functions that I wrote will help you.
>
> It uses maparg() to get information on existing key mapping,
> but with maparg(), it's impossible to cover all scenarios
> to use key mappings, as Hari Krishna Dara and I described.
>

I also noticed that map and maparg() fail to even give the right
<rhs>. E.g., try either of the the below maps:

:inoremap <buffer> <Tab> <Tab>
:inoremap <buffer> <Tab> <lt>Tab>

the later is equivalent to (in functionality):

:inoremap <buffer> <expr> <Tab> "<Tab>"

and try the below commands:

:echo maparg('<Tab>', 'i')
<Tab>
:imap <buffer> <Tab>
i  <Tab>       *@<Tab>

You get indistinguishable results.

Regarding the suggestion of reusing the code from the :mksession, this
code explicitly skips some maps, including those with <script> option,
so it is not a complete solution. 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:
- You are able to create fresh maps into script context, kind of like
meddling with its encapsulation. However Vim doesn't prevent calling
SID functions so you could argue that this is on the same lines. But
this could give a way to access SID variables which are otherwise not
accessible (not that there is such a need to break script
encapsulation).
- You can't persist such maps across sessions (as the SID may not be
the same across sessions), but this case might not even be useful, so
probably OK.

--
Hari

>
> --
> To Vim, or not to Vim.
> http://whileimautomaton.net/
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: copy a map (in order to restore it later)

Kana Natsuno
In reply to this post by Hari Krishna Dara-3

On Wed, 30 Sep 2009 02:50:25 +0900, Hari Krishna Dara <[hidden email]> wrote:

>> Recently I need to copy a key mapping to enhance my plugin.  It defines
>> another kind of key mappings which is expanded when multiple keys are
>> simultaneously pressed.  These key mappings can coexist with ordinary
>> key mappings even if both {lhs}es conflict with each other, but it's
>> a bit difficult or troublesome to resolve conflicts manually.  I want to
>> resolve conflicts automatically, but it's not possible to realize
>> without the way to copy existing key mappings.
>
> I am not clear on your use case. Were you going to backup some maps
> and unmap them to help resolve conflicts? Is the functionality of this
> plugin somehow similar to my execmap plugin
> (http://www.vim.org/scripts/script.php?script_id=598)?

Almost same.  For example, there are quite a few users who prefer display line
motions (gj/gk) to logical line motions (j/k), so they put the following in
their vimrc:

        noremap j  gj
        noremap k  gk

While I want to :join with an operator.  But there is no suitable key sequence
to assign the operator in my environment.  So I assign it to a combination of
keys as follows:

        Arpeggio noremap oj  <Plug>(operator-join)

With the above setting, <Plug>(operator-join) is executed if o and j are
simultaneously pressed, while solely pressed o and j do the same as their
default actions.  (Here <Plug>(operator-join) is an operator to :join, and
:Arpeggio is a command provided by my plugin arpeggio.
http://www.vim.org/scripts/script.php?script_id=2425  )

But arpeggio defines key mappings for o and j to check whether the keys are
simultaneously pressed or not.  So "noremap j" and "Arpeggio nnoremap oj"
conflict.  One of them is overridden depending on the order of them.

There is a way to resolve this conflict.  Arpeggio defines
<Plug>(arpeggio-default:{X}) to customize the action for solely pressed {X}.
So this conflict can be resolved with the following:

        noremap <Plug>(arpeggio-default:j)  gj

But as I define other arpeggio key mappings, the number of conflicts with
ordinary key mappings are increased rapidly.  It's a boring work to resolve
these conflicts manually.

If there are functions to copy/list key mappings, these conflicts can be
resolved automatically.


--
To Vim, or not to Vim.
http://whileimautomaton.net/


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: copy a map (in order to restore it later)

Andy Wokula
In reply to this post by Hari Krishna Dara-3

Hari Krishna Dara schrieb:
> On Tue, Sep 29, 2009 at 5:35 PM, Kana Natsuno <[hidden email]> 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>

> 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 (?).

--
Andy

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: copy a map (in order to restore it later)

Hari Krishna Dara-3
On Wed, Sep 30, 2009 at 2:27 AM, Andy Wokula <[hidden email]> wrote:

>
> Hari Krishna Dara schrieb:
>> On Tue, Sep 29, 2009 at 5:35 PM, Kana Natsuno <[hidden email]> 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 (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: copy a map (in order to restore it later)

Andy Wokula

Hari Krishna Dara schrieb:

> On Wed, Sep 30, 2009 at 2:27 AM, Andy Wokula <[hidden email]> wrote:
>> Hari Krishna Dara schrieb:
>>> On Tue, Sep 29, 2009 at 5:35 PM, Kana Natsuno <[hidden email]> 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.

Not only an <SID> (<SNR> actually), but also the script-ID.

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

(sorry these examples hurt the eyes ...)

I'm pretty much aware of that ... you pointed out several things and I
was only referring to the following paragraph:

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

Again: This functionality is already there (?).

> Are you referring to the <script:SID> format already being there?

Yes, I did.

> I just checked, it is not there.

Ah, you want to add a new map-modifier <script:SID> next to <script>,
<expr>, etc?  And with SID replaced by the script number?  For example

    :nn <script:15> <SID>yank :call <SID>yank()<CR><SID>DoMore

(Please correct this as needed)

But how is this different from

    :nn <script> <SNR>15_yank :call <SNR>15_yank()<CR><SNR>15_DoMore

> You could of course call script local functions using the <SNR>_
> syntax, but it doesn't serve all cases.

Ok.
Which are those cases?
Which are those cases solved by your suggestion?

> I went ahead and did a POC for this feature and am attaching the
> patch.

Looks promising, but I'll have to let others comment on that.

--
Andy

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: copy a map (in order to restore it later)

Hari Krishna Dara-3

On Thu, Oct 1, 2009 at 4:03 PM, Andy Wokula <[hidden email]> wrote:

>
> Hari Krishna Dara schrieb:
>> On Wed, Sep 30, 2009 at 2:27 AM, Andy Wokula <[hidden email]> wrote:
>>> Hari Krishna Dara schrieb:
>>>> On Tue, Sep 29, 2009 at 5:35 PM, Kana Natsuno <[hidden email]> 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.
>
> Not only an <SID> (<SNR> actually), but also the script-ID.
>
>> 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>
>
> (sorry these examples hurt the eyes ...)
>
> I'm pretty much aware of that ... you pointed out several things and I
> was only referring to the following paragraph:
>
>>>> 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:
>
> Again: This functionality is already there (?).
>
>> Are you referring to the <script:SID> format already being there?
>
> Yes, I did.
>
>> I just checked, it is not there.
>
> Ah, you want to add a new map-modifier <script:SID> next to <script>,
> <expr>, etc?  And with SID replaced by the script number?  For example
>
>    :nn <script:15> <SID>yank :call <SID>yank()<CR><SID>DoMore
>
> (Please correct this as needed)
>
> But how is this different from
>
>    :nn <script> <SNR>15_yank :call <SNR>15_yank()<CR><SNR>15_DoMore
>
>> You could of course call script local functions using the <SNR>_
>> syntax, but it doesn't serve all cases.
>
> Ok.
> Which are those cases?
> Which are those cases solved by your suggestion?

Your suggestion to use <SNR> syntax only serves the cases which
involve calling script local functions, but <script> serves a
different case than that, see ":help <script>". Also, there is no
workaround suggested towards capturing maps with <expr> option yet on
this thread. I am sure we can come up with ways to cover these missing
cases by enhancing existing commands, but I think the :dupmap command
that I am suggestion is the most straight-forward and complete way to
capture an existing map (as it literally copies the map at the lowest
level).

--
Hari

>
>> I went ahead and did a POC for this feature and am attaching the
>> patch.
>
> Looks promising, but I'll have to let others comment on that.
>
> --
> Andy
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: copy a map (in order to restore it later)

Kana Natsuno
In reply to this post by Hari Krishna Dara-3

On Fri, 02 Oct 2009 06:46:13 +0900, Hari Krishna Dara <[hidden email]> wrote:
> 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.

It sounds great, but I have two suggestions.

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

It seems to be confusing because the meaning of {rhs} is completely different
from other :map commands.  It should be named {newlhs}.

And IMHO, functions are better than Ex commands for this functionality.
Because the main usage of copying a key mapping is for scripts to process many
key mappings which are given dynamically, so functions are easy to use for the
purpose.  Even it's possible to process with the following command
":execute 'dupmap' a:lhs a:newlhs", it's a bit troublesome to deal with special
characters such as <Space> (not escaped by <> notation) in a:lhs and a:newlhs.

So I prefer "mapcopy({lhs}, {newlhs}, {modes})" to ":dupmap {lhs} {newlhs}".


--
To Vim, or not to Vim.
http://whileimautomaton.net/


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: copy a map (in order to restore it later)

Hari Krishna Dara-3

On Thu, Oct 1, 2009 at 4:32 PM, Kana Natsuno <[hidden email]> wrote:

>
> On Fri, 02 Oct 2009 06:46:13 +0900, Hari Krishna Dara <[hidden email]> wrote:
>> 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.
>
> It sounds great, but I have two suggestions.
>
>> 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*
>
> It seems to be confusing because the meaning of {rhs} is completely different
> from other :map commands.  It should be named {newlhs}.

Yes, I realized that while I was typing the message and did mention
this (you didn't quote that part, so can't see it above), but I didn't
just want to go back to recreate the patch at that time.

>
> And IMHO, functions are better than Ex commands for this functionality.
> Because the main usage of copying a key mapping is for scripts to process many
> key mappings which are given dynamically, so functions are easy to use for the
> purpose.  Even it's possible to process with the following command
> ":execute 'dupmap' a:lhs a:newlhs", it's a bit troublesome to deal with special
> characters such as <Space> (not escaped by <> notation) in a:lhs and a:newlhs.
>
> So I prefer "mapcopy({lhs}, {newlhs}, {modes})" to ":dupmap {lhs} {newlhs}".
>

How is this different from existing scenarios in which :map needs to
be done created using :exec (there is no equivalent function for :map
either). Regarding <Space>, are you saying that using physical space
(" ") instead of <Space> causes the issue? A physical space would need
to be escaped anyway, so it is always better to use <Space>. Can you
give an example where using :exec is really a problem?

BTW, in case someone wants to try this patch out without having to
apply it and rebuild, I uploaded my windows gvimd.exe here (about 4M
in size): http://haridara.googlepages.com/gvimd.exe

--
Thanks,
Hari

>
> --
> To Vim, or not to Vim.
> http://whileimautomaton.net/
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: copy a map (in order to restore it later)

Andy Wokula
In reply to this post by Hari Krishna Dara-3

Hari Krishna Dara schrieb:

> On Thu, Oct 1, 2009 at 4:03 PM, Andy Wokula <[hidden email]> wrote:
>> Hari Krishna Dara schrieb:
>>> On Wed, Sep 30, 2009 at 2:27 AM, Andy Wokula <[hidden email]> wrote:
>>>> Hari Krishna Dara schrieb:
>>>>> On Tue, Sep 29, 2009 at 5:35 PM, Kana Natsuno <[hidden email]> 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.
>> Not only an <SID> (<SNR> actually), but also the script-ID.
>>
>>> 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>
>> (sorry these examples hurt the eyes ...)
>>
>> I'm pretty much aware of that ... you pointed out several things and I
>> was only referring to the following paragraph:
>>
>>>>> 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:
>> Again: This functionality is already there (?).
>>
>>> Are you referring to the <script:SID> format already being there?
>> Yes, I did.
>>
>>> I just checked, it is not there.
>> Ah, you want to add a new map-modifier <script:SID> next to <script>,
>> <expr>, etc?  And with SID replaced by the script number?  For example
>>
>>    :nn <script:15> <SID>yank :call <SID>yank()<CR><SID>DoMore
>>
>> (Please correct this as needed)
>>
>> But how is this different from
>>
>>    :nn <script> <SNR>15_yank :call <SNR>15_yank()<CR><SNR>15_DoMore
>>
>>> You could of course call script local functions using the <SNR>_
>>> syntax, but it doesn't serve all cases.
>> Ok.
>> Which are those cases?
>> Which are those cases solved by your suggestion?
>
> Your suggestion to use <SNR> syntax only serves the cases which
> involve calling script local functions, but <script> serves a
> different case than that, see ":help <script>". Also, there is no
> workaround suggested towards capturing maps with <expr> option yet on
> this thread. I am sure we can come up with ways to cover these missing
> cases by enhancing existing commands, but I think the :dupmap command
> that I am suggestion is the most straight-forward and complete way to
> capture an existing map (as it literally copies the map at the lowest
> level).

Hmm, for now this seems to get nowhere and you don't want to give more
explanation about that one paragraph ...

I see the problem with <script>, <expr>, <silent>, <special> etc ...
that you don't know if these modifiers were used.
At the moment I think your new :dupmap command is a very good idea.

--
Andy

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: copy a map (in order to restore it later)

Andy Wokula
In reply to this post by Hari Krishna Dara-3

Hari Krishna Dara schrieb:
> 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 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 for the build, here are a few things I tried with it:

"|This is a line of command output in the echo area.

map j gj
dupmap j <Plug>mem_j
dupmap j <Plug>mem_j
dupmap j <Plug>mem_j
map <Plug>mem_j
"|   <Plug>mem_j     gj
"|   <Plug>mem_j     gj
"|   <Plug>mem_j     gj
"
" Expected: one line of output

unmap <Plug>mem_j
map <Plug>mem_j
"|No mapping found
"
" Ok

ndupmap j <Plug>mem_j
map <Plug>mem_j
"|   <Plug>mem_j     gj
"
" Expected: <Plug>mem_j only mapped for Normal mode:
"|n  <Plug>mem_j     gj

--
Andy

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---