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

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

Expand Messages
  • 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 1 of 10 , Feb 15, 2013
      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 2 of 10 , Feb 17, 2013
        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 3 of 10 , Feb 17, 2013
          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.