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

Re: imaps don't work with keymap=hebrew

Expand Messages
  • Nikolay Pavlov
    ... $ i,, e ) ... +0200 ... we ve ... it. */ ... we ve ... is ... == 0) ... This won t work if I have two *maps: buffer-local and global. One example is
    Message 1 of 12 , Jun 28, 2013
    • 0 Attachment


      On Jun 29, 2013 1:04 AM, "Bram Moolenaar" <Bram@...> wrote:
      >
      >
      > ZyX wrote:
      >
      > > Steps to reproduce:
      > >
      > >     vim -u NONE -c 'set keymap=hebrew' -c 'inoremap ,, \' -s <(<<< $'i,,\e')
      > >
      > > . Expected output is
      > >
      > >     \
      > >
      > > in buffer, actually seen
      > >
      > >     תת
      > >
      > > . If you use my patch and add `-c 'set wgm'` you will see what was
      > > expected. Likely the same prior to vim-7.3.1179.
      >
      >
      > So the problem is that you have both:
      >
      >         :imap ,
      >         i  ,,          * '
      >         :lmap ,
      >         l  ,           *@ת
      >
      > If you remove the last then the other works again:
      >
      >         :lunmap <buffer> ,
      >
      > So, you have conflicting mappings.  The problem is that you didn't
      > explicitly specify one of them.  We could not do this for lmaps.
      >
      > Try this patch:
      >
      > *** ../vim-7.3.1257/src/getchar.c       2013-06-12 21:00:18.000000000 +0200
      > --- src/getchar.c       2013-06-28 21:29:14.000000000 +0200
      > ***************
      > *** 2134,2141 ****
      >                             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;
      >                             }
      > --- 2135,2144 ----
      >                             if (expecting_global_mappings && mp2 == NULL)
      >                             {
      >                                 /* This is the first global mapping. If we've
      > !                                * got a complete buffer-local match that is
      > !                                * not from lmap, use it. */
      > !                               if (mp_match != NULL
      > !                                        && (mp_match->m_mode & LANGMAP) == 0)
      >                                     break;
      >                                 expecting_global_mappings = FALSE;
      >                             }

      This won't work if I have two *maps: buffer-local and global. One example is translit3 and various leader mappings (translit3 maps nearly any ASCII printable character including backslash and comma). Second is using quickfix and q as a leader. Guess more will emerge as users update.

      We do need an option.

      > --
      > 'I generally avoid temptation unless I can't resist it."
      >                 -- Mae West
      >
      >  /// 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.
       
       
    • ZyX
      ... I mean, maps of the same type: directly the situation this patch should work with. ... -- -- You received this message from the vim_dev maillist. Do not
      Message 2 of 12 , Jun 29, 2013
      • 0 Attachment
        > This won't work if I have two *maps: buffer-local and global.

        I mean, maps of the same type: directly the situation this patch should work with.

        > One example is translit3 and various leader mappings (translit3 maps nearly any ASCII printable character including backslash and comma). Second is using quickfix and q as a leader. Guess more will emerge as users update.
        >
        >
        > We do need an option.

        --
        --
        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
        ... An option won t work to solve these problems and still have buffer-local mappings work properly. We need an argument on the mapping itself. After all, the
        Message 3 of 12 , Jun 29, 2013
        • 0 Attachment
          Nikolay Pavlov wrote:

          > On Jun 29, 2013 1:04 AM, "Bram Moolenaar" <Bram@...> wrote:
          > >
          > >
          > > ZyX wrote:
          > >
          > > > Steps to reproduce:
          > > >
          > > > vim -u NONE -c 'set keymap=hebrew' -c 'inoremap ,, \' -s <(<<< $'i,,\e')
          > > >
          > > > . Expected output is
          > > >
          > > > \
          > > >
          > > > in buffer, actually seen
          > > >
          > > > תת
          > > >
          > > > . If you use my patch and add `-c 'set wgm'` you will see what was
          > > > expected. Likely the same prior to vim-7.3.1179.
          > >
          > >
          > > So the problem is that you have both:
          > >
          > > :imap ,
          > > i ,, * '
          > > :lmap ,
          > > l , *@ת
          > >
          > > If you remove the last then the other works again:
          > >
          > > :lunmap <buffer> ,
          > >
          > > So, you have conflicting mappings. The problem is that you didn't
          > > explicitly specify one of them. We could not do this for lmaps.
          > >
          > > Try this patch:
          > >
          > > *** ../vim-7.3.1257/src/getchar.c 2013-06-12 21:00:18.000000000 +0200
          > > --- src/getchar.c 2013-06-28 21:29:14.000000000 +0200
          > > ***************
          > > *** 2134,2141 ****
          > > 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;
          > > }
          > > --- 2135,2144 ----
          > > if (expecting_global_mappings && mp2 == NULL)
          > > {
          > > /* This is the first global mapping. If we've
          > > ! * got a complete buffer-local match that is
          > > ! * not from lmap, use it. */
          > > ! if (mp_match != NULL
          > > ! && (mp_match->m_mode & LANGMAP) == 0)
          > > break;
          > > expecting_global_mappings = FALSE;
          > > }
          >
          > This won't work if I have two *maps: buffer-local and global. One example
          > is translit3 and various leader mappings (translit3 maps nearly any ASCII
          > printable character including backslash and comma). Second is using
          > quickfix and q as a leader. Guess more will emerge as users update.
          >
          > We do need an option.

          An option won't work to solve these problems and still have buffer-local
          mappings work properly. We need an argument on the mapping itself.
          After all, the problem to be solved is that some buffer-local mappings
          don't take effect until another character is typed.

          --
          I still remember when I gave up Smoking, Drinking and Sex. It was the
          most *horrifying* hour of my life!

          /// 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
          ... $ i,, e ) ... +0200 ... NULL) ... If we ve ... use it. */ ... NULL) ... If we ve ... that is ... LANGMAP) == 0) ... example ... ASCII ... Is not it solved
          Message 4 of 12 , Jun 29, 2013
          • 0 Attachment


            On Jun 29, 2013 3:59 PM, "Bram Moolenaar" <Bram@...> wrote:
            >
            >
            > Nikolay Pavlov wrote:
            >
            > > On Jun 29, 2013 1:04 AM, "Bram Moolenaar" <Bram@...> wrote:
            > > >
            > > >
            > > > ZyX wrote:
            > > >
            > > > > Steps to reproduce:
            > > > >
            > > > >     vim -u NONE -c 'set keymap=hebrew' -c 'inoremap ,, \' -s <(<<< $'i,,\e')
            > > > >
            > > > > . Expected output is
            > > > >
            > > > >     \
            > > > >
            > > > > in buffer, actually seen
            > > > >
            > > > >     תת
            > > > >
            > > > > . If you use my patch and add `-c 'set wgm'` you will see what was
            > > > > expected. Likely the same prior to vim-7.3.1179.
            > > >
            > > >
            > > > So the problem is that you have both:
            > > >
            > > >         :imap ,
            > > >         i  ,,          * '
            > > >         :lmap ,
            > > >         l  ,           *@ת
            > > >
            > > > If you remove the last then the other works again:
            > > >
            > > >         :lunmap <buffer> ,
            > > >
            > > > So, you have conflicting mappings.  The problem is that you didn't
            > > > explicitly specify one of them.  We could not do this for lmaps.
            > > >
            > > > Try this patch:
            > > >
            > > > *** ../vim-7.3.1257/src/getchar.c       2013-06-12 21:00:18.000000000 +0200
            > > > --- src/getchar.c       2013-06-28 21:29:14.000000000 +0200
            > > > ***************
            > > > *** 2134,2141 ****
            > > >                             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;
            > > >                             }
            > > > --- 2135,2144 ----
            > > >                             if (expecting_global_mappings && mp2 == NULL)
            > > >                             {
            > > >                                 /* This is the first global mapping. If we've
            > > > !                                * got a complete buffer-local match that is
            > > > !                                * not from lmap, use it. */
            > > > !                               if (mp_match != NULL
            > > > !                                        && (mp_match->m_mode & LANGMAP) == 0)
            > > >                                     break;
            > > >                                 expecting_global_mappings = FALSE;
            > > >                             }
            > >
            > > This won't work if I have two *maps: buffer-local and global. One example
            > > is translit3 and various leader mappings (translit3 maps nearly any ASCII
            > > printable character including backslash and comma). Second is using
            > > quickfix and q as a leader. Guess more will emerge as users update.
            > >
            > > We do need an option.
            >
            > An option won't work to solve these problems and still have buffer-local
            > mappings work properly.  We need an argument on the mapping itself.
            > After all, the problem to be solved is that some buffer-local mappings
            > don't take effect until another character is typed.

            Is not it solved with timeout* setting?

            I do not see any problems here: *any* mapping does not take effect until the next character is typed if it prefixes another mapping. Why buffer-local mappings always do not have to wait? Using timeout with the problem described in initial discussion is better solution then current state. I can additionally suggest to create :map-<final> (same as current variant, but applies to one mapping only) or repeat the suggestion for making my option buffer-local. But the current state is not a fix.

            > --
            > I still remember when I gave up Smoking, Drinking and Sex.  It was the
            > most *horrifying* hour of my life!
            >
            >  /// 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
            ...
            Message 5 of 12 , Jun 29, 2013
            • 0 Attachment


              On Jun 29, 2013 5:14 PM, "Nikolay Pavlov" <zyx.vim@...> wrote:
              >
              >
              > On Jun 29, 2013 3:59 PM, "Bram Moolenaar" <Bram@...> wrote:
              > >
              > >
              > > Nikolay Pavlov wrote:
              > >
              > > > On Jun 29, 2013 1:04 AM, "Bram Moolenaar" <Bram@...> wrote:
              > > > >
              > > > >
              > > > > ZyX wrote:
              > > > >
              > > > > > Steps to reproduce:
              > > > > >
              > > > > >     vim -u NONE -c 'set keymap=hebrew' -c 'inoremap ,, \' -s <(<<< $'i,,\e')
              > > > > >
              > > > > > . Expected output is
              > > > > >
              > > > > >     \
              > > > > >
              > > > > > in buffer, actually seen
              > > > > >
              > > > > >     תת
              > > > > >
              > > > > > . If you use my patch and add `-c 'set wgm'` you will see what was
              > > > > > expected. Likely the same prior to vim-7.3.1179.
              > > > >
              > > > >
              > > > > So the problem is that you have both:
              > > > >
              > > > >         :imap ,
              > > > >         i  ,,          * '
              > > > >         :lmap ,
              > > > >         l  ,           *@ת
              > > > >
              > > > > If you remove the last then the other works again:
              > > > >
              > > > >         :lunmap <buffer> ,
              > > > >
              > > > > So, you have conflicting mappings.  The problem is that you didn't
              > > > > explicitly specify one of them.  We could not do this for lmaps.
              > > > >
              > > > > Try this patch:
              > > > >
              > > > > *** ../vim-7.3.1257/src/getchar.c       2013-06-12 21:00:18.000000000 +0200
              > > > > --- src/getchar.c       2013-06-28 21:29:14.000000000 +0200
              > > > > ***************
              > > > > *** 2134,2141 ****
              > > > >                             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;
              > > > >                             }
              > > > > --- 2135,2144 ----
              > > > >                             if (expecting_global_mappings && mp2 == NULL)
              > > > >                             {
              > > > >                                 /* This is the first global mapping. If we've
              > > > > !                                * got a complete buffer-local match that is
              > > > > !                                * not from lmap, use it. */
              > > > > !                               if (mp_match != NULL
              > > > > !                                        && (mp_match->m_mode & LANGMAP) == 0)
              > > > >                                     break;
              > > > >                                 expecting_global_mappings = FALSE;
              > > > >                             }
              > > >
              > > > This won't work if I have two *maps: buffer-local and global. One example
              > > > is translit3 and various leader mappings (translit3 maps nearly any ASCII
              > > > printable character including backslash and comma). Second is using
              > > > quickfix and q as a leader. Guess more will emerge as users update.
              > > >
              > > > We do need an option.
              > >
              > > An option won't work to solve these problems and still have buffer-local
              > > mappings work properly.  We need an argument on the mapping itself.
              > > After all, the problem to be solved is that some buffer-local mappings
              > > don't take effect until another character is typed.
              >
              > Is not it solved with timeout* setting?
              >
              > I do not see any problems here: *any* mapping does not take effect until the next character is typed if it prefixes another mapping. Why buffer-local mappings always do not have to wait? Using timeout with the problem described in initial discussion is better solution then current state. I can additionally suggest to create :map-<final> (same as current variant, but applies to one mapping only) or repeat the suggestion for making my option buffer-local. But the current state is not a fix.

              I see the first suggestion already implemented in place of the previous variant. Thanks!

              >
              > > --
              > > I still remember when I gave up Smoking, Drinking and Sex.  It was the
              > > most *horrifying* hour of my life!
              > >
              > >  /// 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.
               
               
            • Ron Aaron
              Patchlevel 1270 works great again. thanks! -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you
              Message 6 of 12 , Jun 29, 2013
              • 0 Attachment
                Patchlevel 1270 works great again. thanks!

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