Loading ...
Sorry, an error occurred while loading the content.
 

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

Expand Messages
  • Hari Krishna Dara
    ... Your suggestion to use syntax only serves the cases which involve calling script local functions, but serves a different case than that, see
    Message 1 of 17 , Oct 1 4:17 PM
      On Thu, Oct 1, 2009 at 4:03 PM, Andy Wokula <anwoku@...> wrote:
      >
      > Hari Krishna Dara schrieb:
      >> On Wed, Sep 30, 2009 at 2:27 AM, Andy Wokula <anwoku@...> wrote:
      >>> Hari Krishna Dara schrieb:
      >>>> On Tue, Sep 29, 2009 at 5:35 PM, Kana Natsuno <kana@...> 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
      -~----------~----~----~----~------~----~------~--~---
    • Kana Natsuno
      ... It sounds great, but I have two suggestions. ... It seems to be confusing because the meaning of {rhs} is completely different from other :map commands.
      Message 2 of 17 , Oct 1 4:32 PM
        On Fri, 02 Oct 2009 06:46:13 +0900, Hari Krishna Dara <hari.vim@...> 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
        -~----------~----~----~----~------~----~------~--~---
      • Hari Krishna Dara
        ... 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
        Message 3 of 17 , Oct 2 10:17 AM
          On Thu, Oct 1, 2009 at 4:32 PM, Kana Natsuno <kana@...> wrote:
          >
          > On Fri, 02 Oct 2009 06:46:13 +0900, Hari Krishna Dara <hari.vim@...> 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
          -~----------~----~----~----~------~----~------~--~---
        • Andy Wokula
          ... 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 , ,
          Message 4 of 17 , Oct 3 1:51 AM
            Hari Krishna Dara schrieb:
            > On Thu, Oct 1, 2009 at 4:03 PM, Andy Wokula <anwoku@...> wrote:
            >> Hari Krishna Dara schrieb:
            >>> On Wed, Sep 30, 2009 at 2:27 AM, Andy Wokula <anwoku@...> wrote:
            >>>> Hari Krishna Dara schrieb:
            >>>>> On Tue, Sep 29, 2009 at 5:35 PM, Kana Natsuno <kana@...> 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
            -~----------~----~----~----~------~----~------~--~---
          • Andy Wokula
            ... 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
            Message 5 of 17 , Oct 21 2:55 PM
              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
              -~----------~----~----~----~------~----~------~--~---
            Your message has been successfully submitted and would be delivered to recipients shortly.