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

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

Expand Messages
  • Hari Krishna Dara
    ... 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 ... If you capture
    Message 1 of 17 , Oct 1, 2009
      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. 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
      -~----------~----~----~----~------~----~------~--~---
    • Andy Wokula
      ... Not only an ( actually), but also the script-ID. ... (sorry these examples hurt the eyes ...) I m pretty much aware of that ... you pointed out
      Message 2 of 17 , Oct 1, 2009
        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?

        > 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
        -~----------~----~----~----~------~----~------~--~---
      • 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 3 of 17 , Oct 1, 2009
          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 4 of 17 , Oct 1, 2009
            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 5 of 17 , Oct 2, 2009
              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 6 of 17 , Oct 3, 2009
                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 7 of 17 , Oct 21, 2009
                  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.