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

Patch 7.3.1179

Expand Messages
  • Bram Moolenaar
    Patch 7.3.1179 Problem: When a global mapping starts with the same characters as a buffer-local mapping Vim waits for a character to be typed to find out
    Message 1 of 7 , Jun 12, 2013
    • 0 Attachment
      Patch 7.3.1179
      Problem: When a global mapping starts with the same characters as a
      buffer-local mapping Vim waits for a character to be typed to find
      out whether the global mapping is to be used. (Andy Wokula)
      Solution: Use the local mapping without waiting. (Michael Henry)
      Files: runtime/doc/map.txt, src/getchar.c


      *** ../vim-7.3.1178/runtime/doc/map.txt 2013-06-08 15:24:41.000000000 +0200
      --- runtime/doc/map.txt 2013-06-12 20:50:01.000000000 +0200
      ***************
      *** 107,112 ****
      --- 107,114 ----
      :cmapc[lear] |mapmode-c| *:cmapc* *:cmapclear*
      Remove ALL mappings for the modes where the map
      command applies. {not in Vi}
      + Use the <buffer> argument to remove buffer-local
      + mappings |:map-<buffer>|
      Warning: This also removes the default mappings.

      :map |mapmode-nvo|
      ***************
      *** 173,178 ****
      --- 175,181 ----
      :mapclear <buffer>
      Local mappings are also cleared when a buffer is deleted, but not when it is
      unloaded. Just like local option values.
      + Also see |map-precedence|.

      *:map-<silent>* *:map-silent*
      To define a mapping which will not be echoed on the command line, add
      ***************
      *** 644,649 ****
      --- 655,672 ----
      you type slowly, or your system is slow, reset the 'timeout' option. Then you
      might want to set the 'ttimeout' option.

      + *map-precedence*
      + Buffer-local mappings (defined using |:map-<buffer>|) take precedence over
      + global mappings. When a buffer-local mapping is the same as a global mapping,
      + Vim will use the buffer-local mapping. In addition, Vim will use a complete
      + buffer-local mapping immediately, even if a longer global mapping has the
      + buffer-local mapping as a prefix. For example, given the following two
      + mappings: >
      + :map <buffer> \a :echo "Local \a"<CR>
      + :map \abc :echo "Global \abc"<CR>
      + The buffer-local mapping \a will be used immediately. Vim will not wait for
      + more characters to see if the user might be typing \abc.
      +
      *map-keys-fails*
      There are situations where key codes might not be recognized:
      - Vim can only read part of the key code. Mostly this is only the first
      *** ../vim-7.3.1178/src/getchar.c 2013-05-06 05:50:22.000000000 +0200
      --- src/getchar.c 2013-06-12 20:52:49.000000000 +0200
      ***************
      *** 1924,1929 ****
      --- 1924,1930 ----
      mapblock_T *mp;
      #ifdef FEAT_LOCALMAP
      mapblock_T *mp2;
      + int expecting_global_mappings;
      #endif
      mapblock_T *mp_match;
      int mp_match_len = 0;
      ***************
      *** 2105,2110 ****
      --- 2106,2112 ----
      /* First try buffer-local mappings. */
      mp = curbuf->b_maphash[MAP_HASH(local_State, c1)];
      mp2 = maphash[MAP_HASH(local_State, c1)];
      + expecting_global_mappings = (mp && mp2);
      if (mp == NULL)
      {
      mp = mp2;
      ***************
      *** 2128,2133 ****
      --- 2130,2145 ----
      #endif
      (mp = mp->m_next))
      {
      + #ifdef FEAT_LOCALMAP
      + if (expecting_global_mappings && mp2 == NULL)
      + {
      + /* This is the first global mapping. If we've
      + * got a complete buffer-local match, use it. */
      + if (mp_match)
      + break;
      + expecting_global_mappings = FALSE;
      + }
      + #endif
      /*
      * Only consider an entry if the first character
      * matches and it is for the current state.
      *** ../vim-7.3.1178/src/version.c 2013-06-12 20:35:46.000000000 +0200
      --- src/version.c 2013-06-12 20:56:36.000000000 +0200
      ***************
      *** 730,731 ****
      --- 730,733 ----
      { /* Add new patch number below this line */
      + /**/
      + 1179,
      /**/

      --
      If Apple would build a car...
      ... it would be powered by the sun, be reliable, five times
      as fast and twice as easy to drive; but would only run on
      five percent of the roads.

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ an exciting new programming language -- http://www.Zimbu.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • ZyX
      How to disable this behavior? I have a bunch of global mappings starting with comma and translit3 plugin which translates things like “,,” into “„”
      Message 2 of 7 , Jun 22, 2013
      • 0 Attachment
        How to disable this behavior? I have a bunch of global mappings starting with comma and translit3 plugin which translates things like “,,” into “„” in an IMAP-like fashion (translation is done only when last character of sequence is typed; preceding characters found in the buffer are used to check whether something is to be translated). Translit3 plugin is enabled only for specific buffers and thus is using <buffer> mappings. Thus I am completely against new behavior.

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Bram Moolenaar
        ... If you have a local mapping for ,, and a global mapping for ,k , then nothing should have changed. Only when you have a global mapping like ,,k it
        Message 3 of 7 , Jun 22, 2013
        • 0 Attachment
          ZyX wrote:

          > How to disable this behavior? I have a bunch of global mappings
          > starting with comma and translit3 plugin which translates things like
          > “,,” into “„” in an IMAP-like fashion (translation is
          > done only when last character of sequence is typed; preceding
          > characters found in the buffer are used to check whether something is
          > to be translated). Translit3 plugin is enabled only for specific
          > buffers and thus is using <buffer> mappings. Thus I am completely
          > against new behavior.

          If you have a local mapping for ",," and a global mapping for ",k", then
          nothing should have changed. Only when you have a global mapping like
          ",,k" it would kick in, but then the local mapping for ",," does not
          work well since you need to type something else than "k" after ",," to
          trigger it.

          So what is your problem really?

          --
          Women are probably the main cause of free software starvation.

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ an exciting new programming language -- http://www.Zimbu.org ///
          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Amadeus Demarzi
          As per the reply in my issue I raised, I think this causes problems as specified here: https://groups.google.com/forum/#!topic/vim_dev/SIUBjOVmJx4 Is there any
          Message 4 of 7 , Jun 24, 2013
          • 0 Attachment
            As per the reply in my issue I raised, I think this causes problems as specified here:

            https://groups.google.com/forum/#!topic/vim_dev/SIUBjOVmJx4

            Is there any way to work around this?

            On Saturday, June 22, 2013 1:52:22 PM UTC-7, Bram Moolenaar wrote:
            > ZyX wrote:
            >
            >
            >
            > > How to disable this behavior? I have a bunch of global mappings
            >
            > > starting with comma and translit3 plugin which translates things like
            >
            > > �,,� into ��� in an IMAP-like fashion (translation is
            >
            > > done only when last character of sequence is typed; preceding
            >
            > > characters found in the buffer are used to check whether something is
            >
            > > to be translated). Translit3 plugin is enabled only for specific
            >
            > > buffers and thus is using <buffer> mappings. Thus I am completely
            >
            > > against new behavior.
            >
            >
            >
            > If you have a local mapping for ",," and a global mapping for ",k", then
            >
            > nothing should have changed. Only when you have a global mapping like
            >
            > ",,k" it would kick in, but then the local mapping for ",," does not
            >
            > work well since you need to type something else than "k" after ",," to
            >
            > trigger it.
            >
            >
            >
            > So what is your problem really?
            >
            >
            >
            > --
            >
            > Women are probably the main cause of free software starvation.
            >
            >
            >
            > /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            >
            > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            >
            > \\\ an exciting new programming language -- http://www.Zimbu.org ///
            >
            > \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

            --
            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Nikolay Pavlov
            There is another victim now: ... they stopped working. ... keymap=hebrew, that map no longer works. I tried changing the imap to the actual characters entered
            Message 5 of 7 , Jun 28, 2013
            • 0 Attachment

              There is another victim now:

              On Jun 28, 2013 8:52 AM, "Ron Aaron" <ronware.org@...> wrote:
              >
              > They have always worked before, but in one of the fairly recent builds they stopped working.
              >
              > I have an input map of `h  to something.  When I have a rl window and keymap=hebrew, that map no longer works.  I tried changing the imap to the actual characters entered by the keymap, e.g. ;י ... but it also does not work.

              On Jun 12, 2013 11:00 PM, "Bram Moolenaar" <Bram@...> wrote:
              >
              >
              > Patch 7.3.1179
              > Problem:    When a global mapping starts with the same characters as a
              >             buffer-local mapping Vim waits for a character to be typed to find
              >             out whether the global mapping is to be used. (Andy Wokula)
              > Solution:   Use the local mapping without waiting. (Michael Henry)
              > Files:      runtime/doc/map.txt, src/getchar.c
              >
              >
              > *** ../vim-7.3.1178/runtime/doc/map.txt 2013-06-08 15:24:41.000000000 +0200
              > --- runtime/doc/map.txt 2013-06-12 20:50:01.000000000 +0200
              > ***************
              > *** 107,112 ****
              > --- 107,114 ----
              >   :cmapc[lear]                  |mapmode-c|             *:cmapc*  *:cmapclear*
              >                         Remove ALL mappings for the modes where the map
              >                         command applies.  {not in Vi}
              > +                       Use the <buffer> argument to remove buffer-local
              > +                       mappings |:map-<buffer>|
              >                         Warning: This also removes the default mappings.
              >
              >   :map                          |mapmode-nvo|
              > ***************
              > *** 173,178 ****
              > --- 175,181 ----
              >         :mapclear <buffer>
              >   Local mappings are also cleared when a buffer is deleted, but not when it is
              >   unloaded.  Just like local option values.
              > + Also see |map-precedence|.
              >
              >                                                 *:map-<silent>* *:map-silent*
              >   To define a mapping which will not be echoed on the command line, add
              > ***************
              > *** 644,649 ****
              > --- 655,672 ----
              >   you type slowly, or your system is slow, reset the 'timeout' option.  Then you
              >   might want to set the 'ttimeout' option.
              >
              > +                                                       *map-precedence*
              > + Buffer-local mappings (defined using |:map-<buffer>|) take precedence over
              > + global mappings.  When a buffer-local mapping is the same as a global mapping,
              > + Vim will use the buffer-local mapping.  In addition, Vim will use a complete
              > + buffer-local mapping immediately, even if a longer global mapping has the
              > + buffer-local mapping as a prefix.  For example, given the following two
              > + mappings: >
              > +     :map <buffer> \a   :echo "Local \a"<CR>
              > +     :map          \abc :echo "Global \abc"<CR>
              > + The buffer-local mapping \a will be used immediately.  Vim will not wait for
              > + more characters to see if the user might be typing \abc.
              > +
              >                                                         *map-keys-fails*
              >   There are situations where key codes might not be recognized:
              >   - Vim can only read part of the key code.  Mostly this is only the first
              > *** ../vim-7.3.1178/src/getchar.c       2013-05-06 05:50:22.000000000 +0200
              > --- src/getchar.c       2013-06-12 20:52:49.000000000 +0200
              > ***************
              > *** 1924,1929 ****
              > --- 1924,1930 ----
              >       mapblock_T        *mp;
              >   #ifdef FEAT_LOCALMAP
              >       mapblock_T        *mp2;
              > +     int               expecting_global_mappings;
              >   #endif
              >       mapblock_T        *mp_match;
              >       int               mp_match_len = 0;
              > ***************
              > *** 2105,2110 ****
              > --- 2106,2112 ----
              >                         /* First try buffer-local mappings. */
              >                         mp = curbuf->b_maphash[MAP_HASH(local_State, c1)];
              >                         mp2 = maphash[MAP_HASH(local_State, c1)];
              > +                       expecting_global_mappings = (mp && mp2);
              >                         if (mp == NULL)
              >                         {
              >                             mp = mp2;
              > ***************
              > *** 2128,2133 ****
              > --- 2130,2145 ----
              >   #endif
              >                                 (mp = mp->m_next))
              >                         {
              > + #ifdef FEAT_LOCALMAP
              > +                           if (expecting_global_mappings && mp2 == NULL)
              > +                           {
              > +                               /* This is the first global mapping. If we've
              > +                                * got a complete buffer-local match, use it. */
              > +                               if (mp_match)
              > +                                   break;
              > +                               expecting_global_mappings = FALSE;
              > +                           }
              > + #endif
              >                             /*
              >                              * Only consider an entry if the first character
              >                              * matches and it is for the current state.
              > *** ../vim-7.3.1178/src/version.c       2013-06-12 20:35:46.000000000 +0200
              > --- src/version.c       2013-06-12 20:56:36.000000000 +0200
              > ***************
              > *** 730,731 ****
              > --- 730,733 ----
              >   {   /* Add new patch number below this line */
              > + /**/
              > +     1179,
              >   /**/
              >
              > --
              > If Apple would build a car...
              > ... it would be powered by the sun, be reliable, five times
              > as fast and twice as easy to drive; but would only run on
              > five percent of the roads.
              >
              >  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
              > ///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              > \\\  an exciting new programming language -- http://www.Zimbu.org        ///
              >  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///
              >
              > --
              > --
              > You received this message from the "vim_dev" maillist.
              > Do not top-post! Type your reply below the text you are replying to.
              > For more information, visit http://www.vim.org/maillist.php
              >
              > ---
              > You received this message because you are subscribed to the Google Groups "vim_dev" group.
              > To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              > For more options, visit https://groups.google.com/groups/opt_out.
              >
              >

              --
              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php
               
              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
               
               
            • Nikolay Pavlov
              ... they stopped working. ... keymap=hebrew, that map no longer works. I tried changing the imap to the actual characters entered by the keymap, e.g. ;י ...
              Message 6 of 7 , Jun 28, 2013
              • 0 Attachment


                On Jun 28, 2013 3:09 PM, "Nikolay Pavlov" <zyx.vim@...> wrote:
                >
                > There is another victim now:
                >
                > On Jun 28, 2013 8:52 AM, "Ron Aaron" <ronware.org@...> wrote:
                > >
                > > They have always worked before, but in one of the fairly recent builds they stopped working.
                > >
                > > I have an input map of `h  to something.  When I have a rl window and keymap=hebrew, that map no longer works.  I tried changing the imap to the actual characters entered by the keymap, e.g. ;י ... but it also does not work.

                It looks now like it is better to revert it or add an option with new behavior *disabled* by default. If it conflicts with keymaps then it means almost any global mapping is disabled when keymap is active. This is obviously not standable.

                --
                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php
                 
                ---
                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
                 
                 
              • Andy Wokula
                ... There was a good reason for the new behavior. Overview about discussion so far: Initial discussion: vim_use, Jan 2013: Buffer-local unmap of global
                Message 7 of 7 , Jun 28, 2013
                • 0 Attachment
                  Am 22.06.2013 14:37, schrieb ZyX:
                  > How to disable this behavior? I have a bunch of global mappings
                  > starting with comma and translit3 plugin which translates things like
                  > “,,” into “„” in an IMAP-like fashion (translation is done only when
                  > last character of sequence is typed; preceding characters found in the
                  > buffer are used to check whether something is to be translated).
                  > Translit3 plugin is enabled only for specific buffers and thus is
                  > using <buffer> mappings. Thus I am completely against new behavior.

                  There was a good reason for the new behavior. Overview about discussion
                  so far:

                  Initial discussion:
                  vim_use, Jan 2013: Buffer-local unmap of global mapping
                  vim_dev, Jan 2013: Prioritize buffer-local mappings over global ones (with patch)

                  (This) Patch:
                  vim_dev: Patch 7.3.1179

                  Problems with the patch:
                  vim_dev: Quick Fix/No File Buffers and the q key
                  vim_dev: imaps don't work with keymap=hebrew

                  ZyX' patch:
                  vim_dev: [PATCH] Add 'waitforglobalmap' option

                  --
                  Andy

                  --
                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                Your message has been successfully submitted and would be delivered to recipients shortly.