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

copy a map (in order to restore it later)

Expand Messages
  • Hari Krishna Dara
    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
    Message 1 of 17 , Sep 26, 2009
    • 0 Attachment
      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
      -~----------~----~----~----~------~----~------~--~---
    • Kana Natsuno
      ... 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
      Message 2 of 17 , Sep 27, 2009
      • 0 Attachment
        On Sun, 27 Sep 2009 14:58:25 +0900, Hari Krishna Dara <hari.vim@...> 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
        -~----------~----~----~----~------~----~------~--~---
      • Andy Wokula
        ... +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
        Message 3 of 17 , Sep 29, 2009
        • 0 Attachment
          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
          -~----------~----~----~----~------~----~------~--~---
        • Hari Krishna Dara
          ... Very well said and accurate to the point. I didn t realize that ... option. Not surprisingly, the below two appear the same in the ... I think this
          Message 4 of 17 , Sep 29, 2009
          • 0 Attachment
            On Sun, Sep 27, 2009 at 3:04 PM, Kana Natsuno <kana@...> wrote:
            >
            > On Sun, 27 Sep 2009 14:58:25 +0900, Hari Krishna Dara <hari.vim@...> 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
            -~----------~----~----~----~------~----~------~--~---
          • Yakov Lerner
            ... Following commands saving mappings into file, ... Maybe you can manipulate their options to save *only*mappings ? Or extract mappings from theiroutput
            Message 5 of 17 , Sep 29, 2009
            • 0 Attachment
              On Sun, Sep 27, 2009 at 08:58, Hari Krishna Dara <hari.vim@...> 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
              -~----------~----~----~----~------~----~------~--~---
            • Charles E Campbell Jr
              ... You could see if cecutil s SaveUserMaps() and RestoreUserMaps() functions that I wrote will help you. In particular: SaveUserMaps( n , , , hkd )
              Message 6 of 17 , Sep 29, 2009
              • 0 Attachment
                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
                -~----------~----~----~----~------~----~------~--~---
              • Kana Natsuno
                ... 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
                Message 7 of 17 , Sep 29, 2009
                • 0 Attachment
                  On Wed, 30 Sep 2009 09:23:56 +0900, Charles E Campbell Jr <drchip@...> 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
                  -~----------~----~----~----~------~----~------~--~---
                • Hari Krishna Dara
                  ... I also noticed that map and maparg() fail to even give the right ... ... i *@ You get indistinguishable results. Regarding the
                  Message 8 of 17 , Sep 29, 2009
                  • 0 Attachment
                    On Tue, Sep 29, 2009 at 5:35 PM, Kana Natsuno <kana@...> wrote:
                    >
                    > On Wed, 30 Sep 2009 09:23:56 +0900, Charles E Campbell Jr <drchip@...> 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
                    -~----------~----~----~----~------~----~------~--~---
                  • Kana Natsuno
                    ... 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
                    Message 9 of 17 , Sep 29, 2009
                    • 0 Attachment
                      On Wed, 30 Sep 2009 02:50:25 +0900, Hari Krishna Dara <hari.vim@...> 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
                      -~----------~----~----~----~------~----~------~--~---
                    • Andy Wokula
                      ... At least ... prints all my mappings, which include the script numbers, and I can do e.g. ... at the command line to re-execute what was previously
                      Message 10 of 17 , Sep 30, 2009
                      • 0 Attachment
                        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>

                        > 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
                        -~----------~----~----~----~------~----~------~--~---
                      • 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 11 of 17 , Oct 1, 2009
                        • 0 Attachment
                          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 12 of 17 , Oct 1, 2009
                          • 0 Attachment
                            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 13 of 17 , Oct 1, 2009
                            • 0 Attachment
                              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 14 of 17 , Oct 1, 2009
                              • 0 Attachment
                                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 15 of 17 , Oct 2, 2009
                                • 0 Attachment
                                  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 16 of 17 , Oct 3, 2009
                                  • 0 Attachment
                                    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 17 of 17 , Oct 21, 2009
                                    • 0 Attachment
                                      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.