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

Prioritize buffer-local mappings over global ones (with patch)

Expand Messages
  • Michael Henry
    All, Andy Wokula suggested a solution to the problem that buffer-local mappings have to wait if they are prefixes of global mappings. Below is a patch that
    Message 1 of 10 , Jan 29, 2013
    View Source
    • 0 Attachment
      All,

      Andy Wokula suggested a solution to the problem that
      buffer-local mappings have to wait if they are prefixes of
      global mappings. Below is a patch that implements his
      suggestion.

      A new 'localmaplinger' option is introduced. When set (the
      default), Vim behaves in the traditional way. When reset,
      complete buffer-local mappings will be accepted immediately
      without waiting for incomplete global mappings.

      As I'd commented in a previous thread, it's hard to know what
      name to choose for this option; improvements to the name are
      welcome.

      The patch includes documentation along with the minor code
      change. I didn't know how to implement a test for this
      functionality. If anyone has a suggestion on that front, I'd be
      happy to try to implement something.

      Michael Henry

      diff -r 274c841f033a runtime/doc/map.txt
      --- a/runtime/doc/map.txt Fri Jan 25 20:11:01 2013 +0100
      +++ b/runtime/doc/map.txt Tue Jan 29 08:26:29 2013 -0500
      @@ -654,6 +654,15 @@
      you type slowly, or your system is slow, reset the 'timeout' option.
      Then you
      might want to set the 'ttimeout' option.

      + *map-linger*
      +By default, the presence of any incomplete matches will cause Vim to
      wait for
      +more input, as described above in |map-typing|. This can be undesirable
      +when a short buffer-local mapping is a prefix of a longer global mapping,
      +since it's likely that the user wants the specialized local mapping to
      +be used right away. To cause Vim to accept complete buffer-local mappings
      +immediately despite the presence of incomplete global mappings, reset the
      +'localmaplinger' option.
      +
      *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
      diff -r 274c841f033a runtime/doc/options.txt
      --- a/runtime/doc/options.txt Fri Jan 25 20:11:01 2013 +0100
      +++ b/runtime/doc/options.txt Tue Jan 29 08:26:29 2013 -0500
      @@ -4649,6 +4649,26 @@
      Note that using the "-u NONE" and "--noplugin" command line arguments
      reset this option. |-u| |--noplugin|

      + *'localmaplinger'* *'nolocalmaplinger'*
      +'localmaplinger' boolean (default on)
      + global
      + {not in Vi}
      + When 'localmaplinger' is set (the default), Vim gives equal
      priority
      + to buffer-local and global mappings in the traditional way. As
      + explained in |map-typing|, it compares what you type against all
      + mapped sequences. If it finds at least one incomplete match,
      it will
      + get more characters until no more incomplete matches exist,
      then use
      + the longest complete match it has found (if any).
      +
      + When 'localmaplinger' is reset, Vim will treat buffer-local
      mappings
      + as more important than global mappings. When it finds a complete
      + match for a buffer-local mapping with no incomplete buffer-local
      + matches, it will not wait for any incomplete matches of global
      + mappings. This is useful for plugins that make buffer-local
      mappings
      + which are prefixes of longer global mappings, resulting in forced
      + delays of 'timeoutlen' before the incomplete global mapping
      times out
      + and allows the local mapping to take effect.
      +
      *'macatsui'* *'nomacatsui'*
      'macatsui' boolean (default on)
      global
      diff -r 274c841f033a src/getchar.c
      --- a/src/getchar.c Fri Jan 25 20:11:01 2013 +0100
      +++ b/src/getchar.c Tue Jan 29 08:26:29 2013 -0500
      @@ -1912,6 +1912,7 @@
      mapblock_T *mp;
      #ifdef FEAT_LOCALMAP
      mapblock_T *mp2;
      + int expecting_global_mappings;
      #endif
      mapblock_T *mp_match;
      int mp_match_len = 0;
      @@ -2093,6 +2094,7 @@
      /* 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;
      @@ -2116,6 +2118,22 @@
      #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 and we
      + * shouldn't linger for a longer global match,
      + * use the current match.
      + */
      + if (mp_match && !p_lmlinger)
      + {
      + break;
      + }
      + expecting_global_mappings = FALSE;
      + }
      +#endif
      /*
      * Only consider an entry if the first character
      * matches and it is for the current state.
      diff -r 274c841f033a src/option.c
      --- a/src/option.c Fri Jan 25 20:11:01 2013 +0100
      +++ b/src/option.c Tue Jan 29 08:26:29 2013 -0500
      @@ -1706,6 +1706,11 @@
      {"loadplugins", "lpl", P_BOOL|P_VI_DEF,
      (char_u *)&p_lpl, PV_NONE,
      {(char_u *)TRUE, (char_u *)0L} SCRIPTID_INIT},
      +#ifdef FEAT_LOCALMAP
      + {"localmaplinger",NULL, P_BOOL|P_VI_DEF,
      + (char_u *)&p_lmlinger, PV_NONE,
      + {(char_u *)TRUE, (char_u *)0L} SCRIPTID_INIT},
      +#endif
      #ifdef FEAT_GUI_MAC
      {"macatsui", NULL, P_BOOL|P_VI_DEF|P_RCLR,
      (char_u *)&p_macatsui, PV_NONE,
      diff -r 274c841f033a src/option.h
      --- a/src/option.h Fri Jan 25 20:11:01 2013 +0100
      +++ b/src/option.h Tue Jan 29 08:26:29 2013 -0500
      @@ -592,6 +592,9 @@

      EXTERN int p_lz; /* 'lazyredraw' */
      EXTERN int p_lpl; /* 'loadplugins' */
      +#ifdef FEAT_LOCALMAP
      +EXTERN int p_lmlinger; /* 'localmaplinger' */
      +#endif
      #ifdef FEAT_GUI_MAC
      EXTERN int p_macatsui; /* 'macatsui' */
      #endif

      --
      --
      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
      ... Interesting! My attention stopped at the option name though ... Other suggestions: bufmapsonly bmo with default off hideglobalmaps hgm with
      Message 2 of 10 , Jan 29, 2013
      View Source
      • 0 Attachment
        Am 29.01.2013 14:28, schrieb Michael Henry:
        > All,
        >
        > Andy Wokula suggested a solution to the problem that
        > buffer-local mappings have to wait if they are prefixes of
        > global mappings. Below is a patch that implements his
        > suggestion.
        >
        > A new 'localmaplinger' option is introduced. When set (the
        > default), Vim behaves in the traditional way. When reset,
        > complete buffer-local mappings will be accepted immediately
        > without waiting for incomplete global mappings.
        >
        > As I'd commented in a previous thread, it's hard to know what
        > name to choose for this option; improvements to the name are
        > welcome.

        Interesting! My attention stopped at the option name though ...
        Other suggestions:
        'bufmapsonly' 'bmo' with default off
        'hideglobalmaps' 'hgm' with default off
        'disableglobalmaps'
        ('noglobalmaps' <= maybe the option should not start with "no")
        ...

        I think turning the option *on* should make a difference.

        --
        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.
      • Christian Brabandt
        ... Or perhaps priorizelocalmaps (plm) or localmappriority (lmp)? regards, Christian -- -- You received this message from the vim_dev maillist. Do not
        Message 3 of 10 , Jan 29, 2013
        View Source
        • 0 Attachment
          On Tue, January 29, 2013 14:55, Andy Wokula wrote:
          > Am 29.01.2013 14:28, schrieb Michael Henry:
          >> All,
          >>
          >> Andy Wokula suggested a solution to the problem that
          >> buffer-local mappings have to wait if they are prefixes of
          >> global mappings. Below is a patch that implements his
          >> suggestion.
          >>
          >> A new 'localmaplinger' option is introduced. When set (the
          >> default), Vim behaves in the traditional way. When reset,
          >> complete buffer-local mappings will be accepted immediately
          >> without waiting for incomplete global mappings.
          >>
          >> As I'd commented in a previous thread, it's hard to know what
          >> name to choose for this option; improvements to the name are
          >> welcome.
          >
          > Interesting! My attention stopped at the option name though ...
          > Other suggestions:
          > 'bufmapsonly' 'bmo' with default off
          > 'hideglobalmaps' 'hgm' with default off
          > 'disableglobalmaps'
          > ('noglobalmaps' <= maybe the option should not start with "no")
          > ...
          >
          > I think turning the option *on* should make a difference.

          Or perhaps 'priorizelocalmaps' (plm) or 'localmappriority' (lmp)?

          regards,
          Christian

          --
          --
          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
          ... Sorry, I didn t read the patch :-/ Ok, global mappings will still be available! Hmm, I think priority in the name is slightly ... misleading. Other
          Message 4 of 10 , Jan 29, 2013
          View Source
          • 0 Attachment
            Am 29.01.2013 15:32, schrieb Christian Brabandt:
            > On Tue, January 29, 2013 14:55, Andy Wokula wrote:
            >> Am 29.01.2013 14:28, schrieb Michael Henry:
            >>> All,
            >>>
            >>> Andy Wokula suggested a solution to the problem that
            >>> buffer-local mappings have to wait if they are prefixes of
            >>> global mappings. Below is a patch that implements his
            >>> suggestion.
            >>>
            >>> A new 'localmaplinger' option is introduced. When set (the
            >>> default), Vim behaves in the traditional way. When reset,
            >>> complete buffer-local mappings will be accepted immediately
            >>> without waiting for incomplete global mappings.
            >>>
            >>> As I'd commented in a previous thread, it's hard to know what
            >>> name to choose for this option; improvements to the name are
            >>> welcome.
            >>
            >> Interesting! My attention stopped at the option name though ...
            >> Other suggestions:
            >> 'bufmapsonly' 'bmo' with default off
            >> 'hideglobalmaps' 'hgm' with default off
            >> 'disableglobalmaps'
            >> ('noglobalmaps' <= maybe the option should not start with "no")
            >> ...
            >>
            >> I think turning the option *on* should make a difference.
            >
            > Or perhaps 'priorizelocalmaps' (plm) or 'localmappriority' (lmp)?

            Sorry, I didn't read the patch :-/
            Ok, global mappings will still be available!

            Hmm, I think "priority" in the name is slightly ... misleading.

            Other suggestions:
            'onlywaitforbufmaps'
            'solebufmapswait'

            'solelocaltimeout'
            'localtimeoutonly'
            'localtimeout' 'ltm'
            'buflocaltimeout' 'blt'

            ...

            --
            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.
          • Bram Moolenaar
            ... I do not like the behavior to depend on timing. I would prefer the local mapping to always take precedence, also when another character was already typed
            Message 5 of 10 , Jan 29, 2013
            View Source
            • 0 Attachment
              Michael Henry wrote:

              > Andy Wokula suggested a solution to the problem that
              > buffer-local mappings have to wait if they are prefixes of
              > global mappings. Below is a patch that implements his
              > suggestion.
              >
              > A new 'localmaplinger' option is introduced. When set (the
              > default), Vim behaves in the traditional way. When reset,
              > complete buffer-local mappings will be accepted immediately
              > without waiting for incomplete global mappings.
              >
              > As I'd commented in a previous thread, it's hard to know what
              > name to choose for this option; improvements to the name are
              > welcome.
              >
              > The patch includes documentation along with the minor code
              > change. I didn't know how to implement a test for this
              > functionality. If anyone has a suggestion on that front, I'd be
              > happy to try to implement something.

              I do not like the behavior to depend on timing. I would prefer the
              local mapping to always take precedence, also when another character was
              already typed that causes a global mapping to match. Otherwise the
              behavior depends on how busy your computer is, or the remote connection.

              Even better would be if we do not need an option at all. Every option
              makes it more difficult for a Vim user to understand what's happening.

              So would it be "the right thing to do" to always let local mappings
              overrule any matching global mapping? It's a slightly incompatible
              change though. But the current behavior is bad enough to accept that
              (you need to type another chacter to stop waiting for the possibility
              that the global mapping would match).


              --
              With sufficient thrust, pigs fly just fine.
              -- RFC 1925

              /// 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.
            • Andy Wokula
              Am 29.01.2013 22:33, schrieb Bram Moolenaar: ... Solution : another option shorttimeoutlen , next to timeoutlen and ttimeoutlen . Defines how long to
              Message 6 of 10 , Jan 29, 2013
              View Source
              • 0 Attachment
                Am 29.01.2013 22:33, schrieb Bram Moolenaar:>
                > Michael Henry wrote:
                >
                >> Andy Wokula suggested a solution to the problem that
                >> buffer-local mappings have to wait if they are prefixes of
                >> global mappings. Below is a patch that implements his
                >> suggestion.
                >>
                >> A new 'localmaplinger' option is introduced. When set (the
                >> default), Vim behaves in the traditional way. When reset,
                >> complete buffer-local mappings will be accepted immediately
                >> without waiting for incomplete global mappings.
                >>
                >> As I'd commented in a previous thread, it's hard to know what
                >> name to choose for this option; improvements to the name are
                >> welcome.
                >>
                >> The patch includes documentation along with the minor code
                >> change. I didn't know how to implement a test for this
                >> functionality. If anyone has a suggestion on that front, I'd be
                >> happy to try to implement something.
                >
                > I do not like the behavior to depend on timing. I would prefer the
                > local mapping to always take precedence, also when another character
                > was already typed that causes a global mapping to match. Otherwise
                > the behavior depends on how busy your computer is, or the remote
                > connection.

                "Solution": another option 'shorttimeoutlen', next to 'timeoutlen' and
                'ttimeoutlen'. Defines how long to wait for an "atomic" key sequence.
                Ok, just kidding, this is crap.

                > Even better would be if we do not need an option at all. Every option
                > makes it more difficult for a Vim user to understand what's happening.

                No problem with that!

                > So would it be "the right thing to do" to always let local mappings
                > overrule any matching global mapping? It's a slightly incompatible
                > change though. But the current behavior is bad enough to accept that
                > (you need to type another character to stop waiting for the
                > possibility that the global mapping would match).

                I think it's the right thing.

                Then one can no longer map reliably to the {lhs} of a global mapping,
                but it's a good habit anyway to always map to the {rhs}.

                --
                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.
              • Michael Henry
                ... Agreed. The patch eliminates the dependence on timing, which I see as a good thing, too. ... Agreed. ... I d be in favor of making the behavior
                Message 7 of 10 , Jan 30, 2013
                View Source
                • 0 Attachment
                  On 01/29/2013 04:33 PM, Bram Moolenaar wrote:
                  > I do not like the behavior to depend on timing. I would prefer the
                  > local mapping to always take precedence, also when another character was
                  > already typed that causes a global mapping to match. Otherwise the
                  > behavior depends on how busy your computer is, or the remote connection.

                  Agreed. The patch eliminates the dependence on timing, which I
                  see as a good thing, too.

                  > Even better would be if we do not need an option at all. Every option
                  > makes it more difficult for a Vim user to understand what's happening.

                  Agreed.

                  > So would it be "the right thing to do" to always let local mappings
                  > overrule any matching global mapping? It's a slightly incompatible
                  > change though. But the current behavior is bad enough to accept that
                  > (you need to type another chacter to stop waiting for the possibility
                  > that the global mapping would match).

                  I'd be in favor of making the behavior non-optional. Here is a
                  modification to the patch that removes the option.

                  Michael Henry

                  diff -r 274c841f033a runtime/doc/map.txt
                  --- a/runtime/doc/map.txt Fri Jan 25 20:11:01 2013 +0100
                  +++ b/runtime/doc/map.txt Wed Jan 30 09:13:18 2013 -0500
                  @@ -654,6 +654,18 @@
                  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
                  diff -r 274c841f033a src/getchar.c
                  --- a/src/getchar.c Fri Jan 25 20:11:01 2013 +0100
                  +++ b/src/getchar.c Wed Jan 30 09:13:18 2013 -0500
                  @@ -1912,6 +1912,7 @@
                  mapblock_T *mp;
                  #ifdef FEAT_LOCALMAP
                  mapblock_T *mp2;
                  + int expecting_global_mappings;
                  #endif
                  mapblock_T *mp_match;
                  int mp_match_len = 0;
                  @@ -2093,6 +2094,7 @@
                  /* 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;
                  @@ -2116,6 +2118,20 @@
                  #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.

                  --
                  --
                  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.
                • Michael Henry
                  Bram, Life s been a bit hectic lately (as I m sure you d find familiar ... various options for the idea below. The original patch provided a Vim option to
                  Message 8 of 10 , Feb 15, 2013
                  View Source
                  • 0 Attachment
                    Bram,

                    Life's been a bit hectic lately (as I'm sure you'd find familiar
                    :-)), and I haven't had a chance to follow up regarding the
                    various options for the idea below. The original patch provided
                    a Vim option to control the behavior of buffer-local mappings
                    that have global mappings as prefixes. The modified patch below
                    removed the idea of a new Vim option.

                    If there is anything you'd like me to adjust about either patch
                    to make the change suitable for inclusion, please let me know.

                    Thanks,
                    Michael Henry

                    On 01/30/2013 09:14 AM, Michael Henry wrote:
                    > On 01/29/2013 04:33 PM, Bram Moolenaar wrote:
                    >> I do not like the behavior to depend on timing. I would prefer the
                    >> local mapping to always take precedence, also when another character was
                    >> already typed that causes a global mapping to match. Otherwise the
                    >> behavior depends on how busy your computer is, or the remote connection.
                    >
                    > Agreed. The patch eliminates the dependence on timing, which I
                    > see as a good thing, too.
                    >
                    >> Even better would be if we do not need an option at all. Every option
                    >> makes it more difficult for a Vim user to understand what's happening.
                    >
                    > Agreed.
                    >
                    >> So would it be "the right thing to do" to always let local mappings
                    >> overrule any matching global mapping? It's a slightly incompatible
                    >> change though. But the current behavior is bad enough to accept that
                    >> (you need to type another chacter to stop waiting for the possibility
                    >> that the global mapping would match).
                    >
                    > I'd be in favor of making the behavior non-optional. Here is a
                    > modification to the patch that removes the option.
                    >
                    > Michael Henry
                    >
                    > diff -r 274c841f033a runtime/doc/map.txt
                    > --- a/runtime/doc/map.txt Fri Jan 25 20:11:01 2013 +0100
                    > +++ b/runtime/doc/map.txt Wed Jan 30 09:13:18 2013 -0500
                    > @@ -654,6 +654,18 @@
                    > 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
                    > diff -r 274c841f033a src/getchar.c
                    > --- a/src/getchar.c Fri Jan 25 20:11:01 2013 +0100
                    > +++ b/src/getchar.c Wed Jan 30 09:13:18 2013 -0500
                    > @@ -1912,6 +1912,7 @@
                    > mapblock_T *mp;
                    > #ifdef FEAT_LOCALMAP
                    > mapblock_T *mp2;
                    > + int expecting_global_mappings;
                    > #endif
                    > mapblock_T *mp_match;
                    > int mp_match_len = 0;
                    > @@ -2093,6 +2094,7 @@
                    > /* 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;
                    > @@ -2116,6 +2118,20 @@
                    > #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.
                    >


                    --
                    --
                    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
                    Michael - ... Thanks for the patch. Bug fixes go first, thus it s somewhere down in the todo list. - Bram -- ./configure Checking whether build environment is
                    Message 9 of 10 , Feb 17, 2013
                    View Source
                    • 0 Attachment
                      Michael -

                      > Life's been a bit hectic lately (as I'm sure you'd find familiar
                      > :-)), and I haven't had a chance to follow up regarding the
                      > various options for the idea below. The original patch provided
                      > a Vim option to control the behavior of buffer-local mappings
                      > that have global mappings as prefixes. The modified patch below
                      > removed the idea of a new Vim option.
                      >
                      > If there is anything you'd like me to adjust about either patch
                      > to make the change suitable for inclusion, please let me know.

                      Thanks for the patch. Bug fixes go first, thus it's somewhere down in
                      the todo list.

                      - Bram

                      --
                      ./configure
                      Checking whether build environment is sane ...
                      build environment is grinning and holding a spatula. Guess not.

                      /// 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.
                    • Michael Henry
                      ... That s great - thanks! I didn t think to check the TODO list, but I see it s there. I d thought there might something more I should be doing here, but I
                      Message 10 of 10 , Feb 17, 2013
                      View Source
                      • 0 Attachment
                        On 02/17/2013 12:11 PM, Bram Moolenaar wrote:
                        > On 02/15/2013 05:57 PM, Michael Henry wrote:
                        >> If there is anything you'd like me to adjust about either patch
                        >> to make the change suitable for inclusion, please let me know.
                        >
                        > Thanks for the patch. Bug fixes go first, thus it's somewhere down in
                        > the todo list.

                        That's great - thanks! I didn't think to check the TODO list,
                        but I see it's there. I'd thought there might something more I
                        should be doing here, but I certainly agree with fixing bugs
                        before adding features.

                        Michael Henry

                        --
                        --
                        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.