Re: copy a map (in order to restore it later)
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 mem_j
dupmap j mem_j
dupmap j mem_j
map mem_j
"| mem_j gj
"| mem_j gj
"| mem_j gj
"
" Expected: one line of output
unmap mem_j
map mem_j
"|No mapping found
"
" Ok
ndupmap j mem_j
map mem_j
"| mem_j gj
"
" Expected: mem_j only mapped for Normal mode:
"|n mem_j gj
--
Andy
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: copy a map (in order to restore it later)
Hari Krishna Dara schrieb: > On Thu, Oct 1, 2009 at 4:03 PM, Andy Wokula wrote: >> Hari Krishna Dara schrieb: >>> On Wed, Sep 30, 2009 at 2:27 AM, Andy Wokula wrote: Hari Krishna Dara schrieb: > On Tue, Sep 29, 2009 at 5:35 PM, Kana Natsuno > wrote: At least :map prints all my mappings, which include the script numbers, and I can do e.g. :nn 15_yank :call 15_yank() at the command line to re-execute what was previously defined by a script as: :nn yank :call yank() >>> This is not a "feature" per se, you are simply finding all those maps >>> that have an in the front. >> Not only an ( actually), but also the script-ID. >> >>> This is not the case that we are trying to point out. Consider these >>> two samples: >>> >>> :nmap
Re: copy a map (in order to restore it later)
On Thu, Oct 1, 2009 at 4:32 PM, Kana Natsuno wrote:
>
> On Fri, 02 Oct 2009 06:46:13 +0900, Hari Krishna Dara
> 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 (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 , are you saying that using physical space
(" ") instead of causes the issue? A physical space would need
to be escaped anyway, so it is always better to use . 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
-~--~~~~--~~--~--~---
Re: copy a map (in order to restore it later)
On Fri, 02 Oct 2009 06:46:13 +0900, Hari Krishna Dara
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 (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
-~--~~~~--~~--~--~---
Re: copy a map (in order to restore it later)
On Thu, Oct 1, 2009 at 4:03 PM, Andy Wokula wrote: > > Hari Krishna Dara schrieb: >> On Wed, Sep 30, 2009 at 2:27 AM, Andy Wokula wrote: >>> Hari Krishna Dara schrieb: On Tue, Sep 29, 2009 at 5:35 PM, Kana Natsuno wrote: >>> At least >>> :map >>> >>> prints all my mappings, which include the script numbers, and I >>> can do e.g. >>> >>> :nn 15_yank :call 15_yank() >>> >>> at the command line to re-execute what was previously defined by a >>> script as: >>> >>> :nn yank :call yank() >> >> This is not a "feature" per se, you are simply finding all those maps >> that have an in the front. > > Not only an ( actually), but also the script-ID. > >> This is not the case that we are trying to point out. Consider these >> two samples: >> >> :nmap
Re: copy a map (in order to restore it later)
Hari Krishna Dara schrieb: > On Wed, Sep 30, 2009 at 2:27 AM, Andy Wokula wrote: >> Hari Krishna Dara schrieb: >>> On Tue, Sep 29, 2009 at 5:35 PM, Kana Natsuno >>> wrote: >> At least >>:map >> >> prints all my mappings, which include the script numbers, and I >> can do e.g. >> >>:nn 15_yank :call 15_yank() >> >> at the command line to re-execute what was previously defined by a >> script as: >> >>:nn yank :call yank() > > This is not a "feature" per se, you are simply finding all those maps > that have an in the front. Not only an ( actually), but also the script-ID. > This is not the case that we are trying to point out. Consider these > two samples: > > :nmap
Re: copy a map (in order to restore it later)
On Wed, Sep 30, 2009 at 2:27 AM, Andy Wokula wrote: > > Hari Krishna Dara schrieb: >> On Tue, Sep 29, 2009 at 5:35 PM, Kana Natsuno >> wrote: > > At least > :map > > prints all my mappings, which include the script numbers, and I > can do e.g. > > :nn 15_yank :call 15_yank() > > at the command line to re-execute what was previously defined by a > script as: > > :nn yank :call yank() This is not a "feature" per se, you are simply finding all those maps that have an in the front. This is not the case that we are trying to point out. Consider these two samples: :nmap
Re: copy a map (in order to restore it later)
Hari Krishna Dara schrieb: > On Tue, Sep 29, 2009 at 5:35 PM, Kana Natsuno > wrote: At least :map prints all my mappings, which include the script numbers, and I can do e.g. :nn 15_yank :call 15_yank() at the command line to re-execute what was previously defined by a script as: :nn yank :call yank() > If we can extend the :map command to accept an optional scriptID as > , 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 -~--~~~~--~~--~--~---
Re: copy a map (in order to restore it later)
On Wed, 30 Sep 2009 02:50:25 +0900, Hari Krishna Dara
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 (operator-join)
With the above setting, (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 (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
(arpeggio-default:{X}) to customize the action for solely pressed {X}.
So this conflict can be resolved with the following:
noremap (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
-~--~~~~--~~--~--~---
Re: copy a map (in order to restore it later)
On Tue, Sep 29, 2009 at 5:35 PM, Kana Natsuno wrote:
>
> On Wed, 30 Sep 2009 09:23:56 +0900, Charles E Campbell Jr
> 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
. E.g., try either of the the below maps:
:inoremap
:inoremap Tab>
the later is equivalent to (in functionality):
:inoremap""
and try the below commands:
:echo maparg('', 'i')
:imap
i *@
You get indistinguishable results.
Regarding the suggestion of reusing the code from the :mksession, this
code explicitly skips some maps, including those with
Re: copy a map (in order to restore it later)
On Wed, 30 Sep 2009 09:23:56 +0900, Charles E Campbell Jr 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 -~--~~~~--~~--~--~---
Re: copy a map (in order to restore it later)
Hari Krishna Dara wrote:
> I need to be able to create an imap for 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 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","","","hkd")
SaveUserMaps("bn","","","hkd")
will save normal mode mappings for s (if any); the first one for
ordinary normal-mode maps, and the second one will append
-qualified maps for . 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
-~--~~~~--~~--~--~---
Re: copy a map (in order to restore it later)
On Sun, Sep 27, 2009 at 08:58, Hari Krishna Dara wrote: > > I need to be able to create an imap for 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 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 , but this won't work for > many scenarios (including the case of
Re: copy a map (in order to restore it later)
On Sun, Sep 27, 2009 at 3:04 PM, Kana Natsuno wrote: > > On Sun, 27 Sep 2009 14:58:25 +0900, Hari Krishna Dara > wrote: >> I need to be able to create an imap for 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 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 , but this won't work for >> many scenarios (including the case of
Re: copy a map (in order to restore it later)
Hari Krishna Dara schrieb: > I need to be able to create an imap for 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 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 , but this won't work for > many scenarios (including the case of
Re: copy a map (in order to restore it later)
On Sun, 27 Sep 2009 14:58:25 +0900, Hari Krishna Dara wrote: > I need to be able to create an imap for 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 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 , but this won't work for > many scenarios (including the case of
copy a map (in order to restore it later)
I need to be able to create an imap for 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 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 , but this won't work for many scenarios (including the case of
