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

Re: Add an option for matchparen to disable it in insert mode

Expand Messages
  • Ingo Karkat
    ... Such a configuration is not trivial to implement (think of compound filetypes like c.doxygen ) and still not the most general. If all this configurability
    Message 1 of 19 , May 1, 2013
      On 01-May-2013 22:29 +0200, Bram Moolenaar wrote:

      > Fanhe Fanhed wrote:
      >
      >> matchparen plugin in CursorMoveI autocmd is too slow while typing. So I
      >> wish disable it in insert mode.
      >
      > I suppose this is because the syntax highlighting for the language is
      > slow. Disabling it for all file types is a bit of a blunt instrument
      > then.
      >
      > How about allowing the user to specify the filetypes for which
      > matchparen works in insert mode? While at it, might as well defined the
      > file types for which it works at all.

      Such a configuration is not trivial to implement (think of compound
      filetypes like "c.doxygen") and still not the most general. If all this
      configurability really has to be there, I'd rather have the script
      observe both buffer-local or global variables, like:

      #v+
      autocmd CursorMovedI *
      \ if exists('b:matchparen_no_insertmode') |
      \ if b:matchparen_no_insertmode |
      \ return |
      \ endif
      \ elseif exists('g:matchparen_no_insertmode') &&
      g:matchparen_no_insertmode |
      \ return |
      \ endif |
      \ ...
      #v-

      This gets you the filetype-specific disabling (in a little more
      roundabout way, by setting b:matchparen_no_insertmode in
      ~/.vim/after/ftplugin/{filetype}.vim), and you can also disable manually
      for the current buffer, for all buffers in a particular subdirectory /
      of a certain file size / matching a certain pattern / etc.

      I use this idiom in a couple of my plugins, and I've found it more
      flexible than a list of configurable filetypes.

      -- regards, ingo

      --
      --
      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
      Hi Ingo! ... Excuse me for chiming in, but I find this construct rather ugly and unreadable. How about this instead: #v+ autocmd CursorMovedI * if get(b:,
      Message 2 of 19 , May 2, 2013
        Hi Ingo!

        On Do, 02 Mai 2013, Ingo Karkat wrote:

        > #v+
        > autocmd CursorMovedI *
        > \ if exists('b:matchparen_no_insertmode') |
        > \ if b:matchparen_no_insertmode |
        > \ return |
        > \ endif
        > \ elseif exists('g:matchparen_no_insertmode') &&
        > g:matchparen_no_insertmode |
        > \ return |
        > \ endif |
        > \ ...
        > #v-

        Excuse me for chiming in, but I find this construct rather ugly and
        unreadable. How about this instead:

        #v+
        autocmd CursorMovedI *
        \ if get(b:, 'matchparen_no_insertmode', 0) ||
        \ get(g:, 'matchparen_no_insertmode', 0)
        \ return |
        \ endif |
        \ ...
        #v-

        regards,
        Christian
        --
        Es ist lange her, daß sich die menschliche Phantasie die Hölle
        ausgemalt hat, aber erst durch ihre jüngst erworbenen Fertigkeiten ist
        sie in die Lage versetzt worden, ihre einstigen Vorstellungen zu
        verwirklichen.
        -- Bertrand A. W. Russell

        --
        --
        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.
      • Ingo Karkat
        ... Hello Christian, I appreciate your critique. I would move the conditionals into the s:Highlight_Matching_Pair() function, too; I just wanted to show the
        Message 3 of 19 , May 2, 2013
          On 02-May-2013 09:11 +0200, Christian Brabandt wrote:

          > Hi Ingo!
          >
          > On Do, 02 Mai 2013, Ingo Karkat wrote:
          >
          >> #v+
          >> autocmd CursorMovedI *
          >> \ if exists('b:matchparen_no_insertmode') |
          >> \ if b:matchparen_no_insertmode |
          >> \ return |
          >> \ endif
          >> \ elseif exists('g:matchparen_no_insertmode') &&
          >> g:matchparen_no_insertmode |
          >> \ return |
          >> \ endif |
          >> \ ...
          >> #v-
          >
          > Excuse me for chiming in, but I find this construct rather ugly and
          > unreadable. How about this instead:
          >
          > #v+
          > autocmd CursorMovedI *
          > \ if get(b:, 'matchparen_no_insertmode', 0) ||
          > \ get(g:, 'matchparen_no_insertmode', 0)
          > \ return |
          > \ endif |
          > \ ...
          > #v-

          Hello Christian,

          I appreciate your critique. I would move the conditionals into the
          s:Highlight_Matching_Pair() function, too; I just wanted to show the
          algorithm with the minimal amount of additional context.

          Your rewrite doesn't correctly capture the fact that the buffer-local
          value takes precedence over the global one; when b:... is 0 and g:... is
          1, insert-mode matching should be ON, whereas your code would :return
          early. Though it may not make that much sense here, I think the
          precedence should be the same as with the built-in global-local options.

          -- regards, ingo

          --
          --
          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
          ... Agreed, using a buffer-local variable is better than trying to use a pattern to match filetypes. -- hundred-and-one symptoms of being an internet addict:
          Message 4 of 19 , May 2, 2013
            Ingo Karkat wrote:

            > On 01-May-2013 22:29 +0200, Bram Moolenaar wrote:
            >
            > > Fanhe Fanhed wrote:
            > >
            > >> matchparen plugin in CursorMoveI autocmd is too slow while typing. So I
            > >> wish disable it in insert mode.
            > >
            > > I suppose this is because the syntax highlighting for the language is
            > > slow. Disabling it for all file types is a bit of a blunt instrument
            > > then.
            > >
            > > How about allowing the user to specify the filetypes for which
            > > matchparen works in insert mode? While at it, might as well defined the
            > > file types for which it works at all.
            >
            > Such a configuration is not trivial to implement (think of compound
            > filetypes like "c.doxygen") and still not the most general. If all this
            > configurability really has to be there, I'd rather have the script
            > observe both buffer-local or global variables, like:
            >
            > #v+
            > autocmd CursorMovedI *
            > \ if exists('b:matchparen_no_insertmode') |
            > \ if b:matchparen_no_insertmode |
            > \ return |
            > \ endif
            > \ elseif exists('g:matchparen_no_insertmode') &&
            > g:matchparen_no_insertmode |
            > \ return |
            > \ endif |
            > \ ...
            > #v-
            >
            > This gets you the filetype-specific disabling (in a little more
            > roundabout way, by setting b:matchparen_no_insertmode in
            > ~/.vim/after/ftplugin/{filetype}.vim), and you can also disable manually
            > for the current buffer, for all buffers in a particular subdirectory /
            > of a certain file size / matching a certain pattern / etc.
            >
            > I use this idiom in a couple of my plugins, and I've found it more
            > flexible than a list of configurable filetypes.

            Agreed, using a buffer-local variable is better than trying to use a
            pattern to match filetypes.

            --
            hundred-and-one symptoms of being an internet addict:
            267. You get an extra phone line so you can get phone calls.

            /// 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.
          • Fanhe Fanhed
            Agreed too. So, Ingo, can you offer a full patch? And please offer a global way to disable matchparen in insert mode. Because I found I really not need it in
            Message 5 of 19 , May 4, 2013
              Agreed too.
              So, Ingo, can you offer a full patch?
              And please offer a global way to disable matchparen in insert mode. Because I found I really not need it in insert mode. :)


              2013/5/3 Bram Moolenaar <Bram@...>

              Ingo Karkat wrote:

              > On 01-May-2013 22:29 +0200, Bram Moolenaar wrote:
              >
              > > Fanhe Fanhed wrote:
              > >
              > >> matchparen plugin in CursorMoveI autocmd is too slow while typing. So I
              > >> wish disable it in insert mode.
              > >
              > > I suppose this is because the syntax highlighting for the language is
              > > slow.  Disabling it for all file types is a bit of a blunt instrument
              > > then.
              > >
              > > How about allowing the user to specify the filetypes for which
              > > matchparen works in insert mode?  While at it, might as well defined the
              > > file types for which it works at all.
              >
              > Such a configuration is not trivial to implement (think of compound
              > filetypes like "c.doxygen") and still not the most general. If all this
              > configurability really has to be there, I'd rather have the script
              > observe both buffer-local or global variables, like:
              >
              > #v+
              >     autocmd CursorMovedI *
              >     \ if exists('b:matchparen_no_insertmode') |
              >     \     if b:matchparen_no_insertmode |
              >     \         return |
              >     \     endif
              >     \ elseif exists('g:matchparen_no_insertmode') &&
              > g:matchparen_no_insertmode |
              >     \     return |
              >     \ endif |
              >     \ ...
              > #v-
              >
              > This gets you the filetype-specific disabling (in a little more
              > roundabout way, by setting b:matchparen_no_insertmode in
              > ~/.vim/after/ftplugin/{filetype}.vim), and you can also disable manually
              > for the current buffer, for all buffers in a particular subdirectory /
              > of a certain file size / matching a certain pattern / etc.
              >
              > I use this idiom in a couple of my plugins, and I've found it more
              > flexible than a list of configurable filetypes.

              Agreed, using a buffer-local variable is better than trying to use a
              pattern to match filetypes.

              --
              hundred-and-one symptoms of being an internet addict:
              267. You get an extra phone line so you can get phone calls.

               /// 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.
               
               
            • Ingo Karkat
              ... After thinking some more about it, I ve come to the conclusion that all attempts so far step around the central issue: The maximum matchparen delay in
              Message 6 of 19 , May 6, 2013
                On 04-May-2013 14:59 +0200, Fanhe Fanhed wrote:

                > Agreed too.
                > So, Ingo, can you offer a full patch?
                > And please offer a global way to disable matchparen in insert mode.
                > Because I found I really not need it in insert mode. :)
                >
                >
                > 2013/5/3 Bram Moolenaar <Bram@... <mailto:Bram@...>>
                >
                >
                > Ingo Karkat wrote:
                >
                > > On 01-May-2013 22:29 +0200, Bram Moolenaar wrote:
                > >
                > > > Fanhe Fanhed wrote:
                > > >
                > > >> matchparen plugin in CursorMoveI autocmd is too slow while
                > typing. So I
                > > >> wish disable it in insert mode.
                > > >
                > > > I suppose this is because the syntax highlighting for the
                > language is
                > > > slow. Disabling it for all file types is a bit of a blunt
                > instrument
                > > > then.
                > > >
                > > > How about allowing the user to specify the filetypes for which
                > > > matchparen works in insert mode? While at it, might as well
                > defined the
                > > > file types for which it works at all.
                > >
                > > Such a configuration is not trivial to implement (think of compound
                > > filetypes like "c.doxygen") and still not the most general. If all
                > this
                > > configurability really has to be there, I'd rather have the script
                > > observe both buffer-local or global variables, like:
                > >
                > > #v+
                > > autocmd CursorMovedI *
                > > \ if exists('b:matchparen_no_insertmode') |
                > > \ if b:matchparen_no_insertmode |
                > > \ return |
                > > \ endif
                > > \ elseif exists('g:matchparen_no_insertmode') &&
                > > g:matchparen_no_insertmode |
                > > \ return |
                > > \ endif |
                > > \ ...
                > > #v-
                > >
                > > This gets you the filetype-specific disabling (in a little more
                > > roundabout way, by setting b:matchparen_no_insertmode in
                > > ~/.vim/after/ftplugin/{filetype}.vim), and you can also disable
                > manually
                > > for the current buffer, for all buffers in a particular subdirectory /
                > > of a certain file size / matching a certain pattern / etc.
                > >
                > > I use this idiom in a couple of my plugins, and I've found it more
                > > flexible than a list of configurable filetypes.
                >
                > Agreed, using a buffer-local variable is better than trying to use a
                > pattern to match filetypes.

                After thinking some more about it, I've come to the conclusion that all
                attempts so far step around the central issue: The maximum matchparen
                delay in insert mode is too large, so that it noticeably affects typing.
                We shouldn't work around this, neither by globally disabling in insert
                mode, nor through any of the proposed filetype- or buffer-local
                configurations.

                Instead, let's just reduce the maximum allowable delay in insert mode,
                as this also is much simpler to do. The plugin contains a hard-coded
                maximum of 300 ms; attached patch reduces that somewhat arbitrarily to a
                fifth, hopefully unnoticeable 60 ms. This way, there's no need to
                configure anything, and you still reap the benefits of matchparen in
                most cases, even for problematic files / file types. This only leaves
                out old Vim versions that don't have the {timeout} argument on
                searchpairpos(), but as you're the first to raise this issue, it may not
                be that widespread to bother.

                -- regards, ingo

                PS: Do not top-post! Type your reply below the text you are replying to.

                --
                --
                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
                ... Thanks, makes sense. So, how do we decide on the timeout? 300 msec is too much, 60 msec is OK? Perhaps we should make this time configurable. -- They now
                Message 7 of 19 , May 6, 2013
                  Ingo Karkat wrote:

                  > On 04-May-2013 14:59 +0200, Fanhe Fanhed wrote:
                  >
                  > > Agreed too.
                  > > So, Ingo, can you offer a full patch?
                  > > And please offer a global way to disable matchparen in insert mode.
                  > > Because I found I really not need it in insert mode. :)
                  > >
                  > >
                  > > 2013/5/3 Bram Moolenaar <Bram@... <mailto:Bram@...>>
                  > >
                  > >
                  > > Ingo Karkat wrote:
                  > >
                  > > > On 01-May-2013 22:29 +0200, Bram Moolenaar wrote:
                  > > >
                  > > > > Fanhe Fanhed wrote:
                  > > > >
                  > > > >> matchparen plugin in CursorMoveI autocmd is too slow while
                  > > typing. So I
                  > > > >> wish disable it in insert mode.
                  > > > >
                  > > > > I suppose this is because the syntax highlighting for the
                  > > language is
                  > > > > slow. Disabling it for all file types is a bit of a blunt
                  > > instrument
                  > > > > then.
                  > > > >
                  > > > > How about allowing the user to specify the filetypes for which
                  > > > > matchparen works in insert mode? While at it, might as well
                  > > defined the
                  > > > > file types for which it works at all.
                  > > >
                  > > > Such a configuration is not trivial to implement (think of compound
                  > > > filetypes like "c.doxygen") and still not the most general. If all
                  > > this
                  > > > configurability really has to be there, I'd rather have the script
                  > > > observe both buffer-local or global variables, like:
                  > > >
                  > > > #v+
                  > > > autocmd CursorMovedI *
                  > > > \ if exists('b:matchparen_no_insertmode') |
                  > > > \ if b:matchparen_no_insertmode |
                  > > > \ return |
                  > > > \ endif
                  > > > \ elseif exists('g:matchparen_no_insertmode') &&
                  > > > g:matchparen_no_insertmode |
                  > > > \ return |
                  > > > \ endif |
                  > > > \ ...
                  > > > #v-
                  > > >
                  > > > This gets you the filetype-specific disabling (in a little more
                  > > > roundabout way, by setting b:matchparen_no_insertmode in
                  > > > ~/.vim/after/ftplugin/{filetype}.vim), and you can also disable
                  > > manually
                  > > > for the current buffer, for all buffers in a particular subdirectory /
                  > > > of a certain file size / matching a certain pattern / etc.
                  > > >
                  > > > I use this idiom in a couple of my plugins, and I've found it more
                  > > > flexible than a list of configurable filetypes.
                  > >
                  > > Agreed, using a buffer-local variable is better than trying to use a
                  > > pattern to match filetypes.
                  >
                  > After thinking some more about it, I've come to the conclusion that all
                  > attempts so far step around the central issue: The maximum matchparen
                  > delay in insert mode is too large, so that it noticeably affects typing.
                  > We shouldn't work around this, neither by globally disabling in insert
                  > mode, nor through any of the proposed filetype- or buffer-local
                  > configurations.
                  >
                  > Instead, let's just reduce the maximum allowable delay in insert mode,
                  > as this also is much simpler to do. The plugin contains a hard-coded
                  > maximum of 300 ms; attached patch reduces that somewhat arbitrarily to a
                  > fifth, hopefully unnoticeable 60 ms. This way, there's no need to
                  > configure anything, and you still reap the benefits of matchparen in
                  > most cases, even for problematic files / file types. This only leaves
                  > out old Vim versions that don't have the {timeout} argument on
                  > searchpairpos(), but as you're the first to raise this issue, it may not
                  > be that widespread to bother.

                  Thanks, makes sense.

                  So, how do we decide on the timeout? 300 msec is too much, 60 msec is
                  OK? Perhaps we should make this time configurable.


                  --
                  They now pass three KNIGHTS impaled to a tree. With their feet off the
                  ground, with one lance through the lot of them, they are skewered up
                  like a barbecue.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                  /// 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.
                • Ingo Karkat
                  ... If Fanhe agrees with the proposed change, I d rather not make it more complex so far. Although I m usually a big proponent of configurability, the values
                  Message 8 of 19 , May 7, 2013
                    On 07-May-2013 05:11 +0200, Bram Moolenaar wrote:

                    > Ingo Karkat wrote:
                    >
                    >> On 04-May-2013 14:59 +0200, Fanhe Fanhed wrote:
                    >>
                    >>> Agreed too.
                    >>> So, Ingo, can you offer a full patch?
                    >>> And please offer a global way to disable matchparen in insert mode.
                    >>> Because I found I really not need it in insert mode. :)
                    >>>
                    >>>
                    >>> 2013/5/3 Bram Moolenaar <Bram@... <mailto:Bram@...>>
                    >>>
                    >>>
                    >>> Ingo Karkat wrote:
                    >>>
                    >>> > On 01-May-2013 22:29 +0200, Bram Moolenaar wrote:
                    >>> >
                    >>> > > Fanhe Fanhed wrote:
                    >>> > >
                    >>> > >> matchparen plugin in CursorMoveI autocmd is too slow while
                    >>> typing. So I
                    >>> > >> wish disable it in insert mode.
                    >>> > >
                    >>> > > I suppose this is because the syntax highlighting for the
                    >>> language is
                    >>> > > slow. Disabling it for all file types is a bit of a blunt
                    >>> instrument
                    >>> > > then.
                    >>> > >
                    >>> > > How about allowing the user to specify the filetypes for which
                    >>> > > matchparen works in insert mode? While at it, might as well
                    >>> defined the
                    >>> > > file types for which it works at all.
                    >>> >
                    >>> > Such a configuration is not trivial to implement (think of compound
                    >>> > filetypes like "c.doxygen") and still not the most general. If all
                    >>> this
                    >>> > configurability really has to be there, I'd rather have the script
                    >>> > observe both buffer-local or global variables, like:
                    >>> >
                    >>> > #v+
                    >>> > autocmd CursorMovedI *
                    >>> > \ if exists('b:matchparen_no_insertmode') |
                    >>> > \ if b:matchparen_no_insertmode |
                    >>> > \ return |
                    >>> > \ endif
                    >>> > \ elseif exists('g:matchparen_no_insertmode') &&
                    >>> > g:matchparen_no_insertmode |
                    >>> > \ return |
                    >>> > \ endif |
                    >>> > \ ...
                    >>> > #v-
                    >>> >
                    >>> > This gets you the filetype-specific disabling (in a little more
                    >>> > roundabout way, by setting b:matchparen_no_insertmode in
                    >>> > ~/.vim/after/ftplugin/{filetype}.vim), and you can also disable
                    >>> manually
                    >>> > for the current buffer, for all buffers in a particular subdirectory /
                    >>> > of a certain file size / matching a certain pattern / etc.
                    >>> >
                    >>> > I use this idiom in a couple of my plugins, and I've found it more
                    >>> > flexible than a list of configurable filetypes.
                    >>>
                    >>> Agreed, using a buffer-local variable is better than trying to use a
                    >>> pattern to match filetypes.
                    >>
                    >> After thinking some more about it, I've come to the conclusion that all
                    >> attempts so far step around the central issue: The maximum matchparen
                    >> delay in insert mode is too large, so that it noticeably affects typing.
                    >> We shouldn't work around this, neither by globally disabling in insert
                    >> mode, nor through any of the proposed filetype- or buffer-local
                    >> configurations.
                    >>
                    >> Instead, let's just reduce the maximum allowable delay in insert mode,
                    >> as this also is much simpler to do. The plugin contains a hard-coded
                    >> maximum of 300 ms; attached patch reduces that somewhat arbitrarily to a
                    >> fifth, hopefully unnoticeable 60 ms. This way, there's no need to
                    >> configure anything, and you still reap the benefits of matchparen in
                    >> most cases, even for problematic files / file types. This only leaves
                    >> out old Vim versions that don't have the {timeout} argument on
                    >> searchpairpos(), but as you're the first to raise this issue, it may not
                    >> be that widespread to bother.
                    >
                    > Thanks, makes sense.
                    >
                    > So, how do we decide on the timeout? 300 msec is too much, 60 msec is
                    > OK? Perhaps we should make this time configurable.

                    If Fanhe agrees with the proposed change, I'd rather not make it more
                    complex so far. Although I'm usually a big proponent of configurability,
                    the values seem to be fine for 99,99% of users, and a maximum, corner
                    case delay of 1/3 s while moving around seems as reasonable as a barely
                    noticeable 60 ms while typing.

                    -- regards, ingo

                    --
                    --
                    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
                    ... It s not so complicated: if !exists( g:matchparen_timeout ) let g:matchparen_timeout = 300 endif if !exists( g:matchparen_insert_timeout ) let
                    Message 9 of 19 , May 7, 2013
                      > Ingo Karkat wrote:
                      >
                      > >> On 04-May-2013 14:59 +0200, Fanhe Fanhed wrote:
                      > >>
                      > >>> Agreed too.
                      > >>> So, Ingo, can you offer a full patch?
                      > >>> And please offer a global way to disable matchparen in insert mode.
                      > >>> Because I found I really not need it in insert mode. :)
                      > >>>
                      > >>>
                      > >>> 2013/5/3 Bram Moolenaar <Bram@... <mailto:Bram@...>>
                      > >>>
                      > >>>
                      > >>> Ingo Karkat wrote:
                      > >>>
                      > >>> > On 01-May-2013 22:29 +0200, Bram Moolenaar wrote:
                      > >>> >
                      > >>> > > Fanhe Fanhed wrote:
                      > >>> > >
                      > >>> > >> matchparen plugin in CursorMoveI autocmd is too slow while
                      > >>> typing. So I
                      > >>> > >> wish disable it in insert mode.
                      > >>> > >
                      > >>> > > I suppose this is because the syntax highlighting for the
                      > >>> language is
                      > >>> > > slow. Disabling it for all file types is a bit of a blunt
                      > >>> instrument
                      > >>> > > then.
                      > >>> > >
                      > >>> > > How about allowing the user to specify the filetypes for which
                      > >>> > > matchparen works in insert mode? While at it, might as well
                      > >>> defined the
                      > >>> > > file types for which it works at all.
                      > >>> >
                      > >>> > Such a configuration is not trivial to implement (think of compound
                      > >>> > filetypes like "c.doxygen") and still not the most general. If all
                      > >>> this
                      > >>> > configurability really has to be there, I'd rather have the script
                      > >>> > observe both buffer-local or global variables, like:
                      > >>> >
                      > >>> > #v+
                      > >>> > autocmd CursorMovedI *
                      > >>> > \ if exists('b:matchparen_no_insertmode') |
                      > >>> > \ if b:matchparen_no_insertmode |
                      > >>> > \ return |
                      > >>> > \ endif
                      > >>> > \ elseif exists('g:matchparen_no_insertmode') &&
                      > >>> > g:matchparen_no_insertmode |
                      > >>> > \ return |
                      > >>> > \ endif |
                      > >>> > \ ...
                      > >>> > #v-
                      > >>> >
                      > >>> > This gets you the filetype-specific disabling (in a little more
                      > >>> > roundabout way, by setting b:matchparen_no_insertmode in
                      > >>> > ~/.vim/after/ftplugin/{filetype}.vim), and you can also disable
                      > >>> manually
                      > >>> > for the current buffer, for all buffers in a particular subdirectory /
                      > >>> > of a certain file size / matching a certain pattern / etc.
                      > >>> >
                      > >>> > I use this idiom in a couple of my plugins, and I've found it more
                      > >>> > flexible than a list of configurable filetypes.
                      > >>>
                      > >>> Agreed, using a buffer-local variable is better than trying to use a
                      > >>> pattern to match filetypes.
                      > >>
                      > >> After thinking some more about it, I've come to the conclusion that all
                      > >> attempts so far step around the central issue: The maximum matchparen
                      > >> delay in insert mode is too large, so that it noticeably affects typing.
                      > >> We shouldn't work around this, neither by globally disabling in insert
                      > >> mode, nor through any of the proposed filetype- or buffer-local
                      > >> configurations.
                      > >>
                      > >> Instead, let's just reduce the maximum allowable delay in insert mode,
                      > >> as this also is much simpler to do. The plugin contains a hard-coded
                      > >> maximum of 300 ms; attached patch reduces that somewhat arbitrarily to a
                      > >> fifth, hopefully unnoticeable 60 ms. This way, there's no need to
                      > >> configure anything, and you still reap the benefits of matchparen in
                      > >> most cases, even for problematic files / file types. This only leaves
                      > >> out old Vim versions that don't have the {timeout} argument on
                      > >> searchpairpos(), but as you're the first to raise this issue, it may not
                      > >> be that widespread to bother.
                      > >
                      > > Thanks, makes sense.
                      > >
                      > > So, how do we decide on the timeout? 300 msec is too much, 60 msec is
                      > > OK? Perhaps we should make this time configurable.
                      >
                      > If Fanhe agrees with the proposed change, I'd rather not make it more
                      > complex so far. Although I'm usually a big proponent of configurability,
                      > the values seem to be fine for 99,99% of users, and a maximum, corner
                      > case delay of 1/3 s while moving around seems as reasonable as a barely
                      > noticeable 60 ms while typing.

                      It's not so complicated:

                      if !exists("g:matchparen_timeout")
                      let g:matchparen_timeout = 300
                      endif
                      if !exists("g:matchparen_insert_timeout")
                      let g:matchparen_insert_timeout = 60
                      endif

                      ...


                      if mode() == 'i' || mode() == 'R'
                      let timeout = exists("b:matchparen_insert_timeout") ? b:matchparen_insert_timeout : g:matchparen_insert_timeout
                      else
                      let timeout = exists("b:matchparen_timeout") ? b:matchparen_timeout : g:matchparen_timeout
                      endif

                      --
                      ZOOT: I'm afraid our life must seem very dull and quiet compared to yours.
                      We are but eightscore young blondes, all between sixteen and
                      nineteen-and-a-half, cut off in this castle, with no one to protect us.
                      Oooh. It is a lonely life ... bathing ... dressing ... undressing ...
                      making exciting underwear....
                      "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                      /// 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.
                    • Fanhe Fanhed
                      Agree with Bram. Thanks all. 2013/5/8 Bram Moolenaar ... -- -- You received this message from the vim_dev maillist. Do not top-post!
                      Message 10 of 19 , May 13, 2013
                        Agree with Bram.
                        Thanks all.


                        2013/5/8 Bram Moolenaar <Bram@...>

                        > Ingo Karkat wrote:
                        >
                        > >> On 04-May-2013 14:59 +0200, Fanhe Fanhed wrote:
                        > >>
                        > >>> Agreed too.
                        > >>> So, Ingo, can you offer a full patch?
                        > >>> And please offer a global way to disable matchparen in insert mode.
                        > >>> Because I found I really not need it in insert mode. :)
                        > >>>
                        > >>>
                        > >>> 2013/5/3 Bram Moolenaar <Bram@... <mailto:Bram@...>>
                        > >>>
                        > >>>
                        > >>>     Ingo Karkat wrote:
                        > >>>
                        > >>>     > On 01-May-2013 22:29 +0200, Bram Moolenaar wrote:
                        > >>>     >
                        > >>>     > > Fanhe Fanhed wrote:
                        > >>>     > >
                        > >>>     > >> matchparen plugin in CursorMoveI autocmd is too slow while
                        > >>>     typing. So I
                        > >>>     > >> wish disable it in insert mode.
                        > >>>     > >
                        > >>>     > > I suppose this is because the syntax highlighting for the
                        > >>>     language is
                        > >>>     > > slow.  Disabling it for all file types is a bit of a blunt
                        > >>>     instrument
                        > >>>     > > then.
                        > >>>     > >
                        > >>>     > > How about allowing the user to specify the filetypes for which
                        > >>>     > > matchparen works in insert mode?  While at it, might as well
                        > >>>     defined the
                        > >>>     > > file types for which it works at all.
                        > >>>     >
                        > >>>     > Such a configuration is not trivial to implement (think of compound
                        > >>>     > filetypes like "c.doxygen") and still not the most general. If all
                        > >>>     this
                        > >>>     > configurability really has to be there, I'd rather have the script
                        > >>>     > observe both buffer-local or global variables, like:
                        > >>>     >
                        > >>>     > #v+
                        > >>>     >     autocmd CursorMovedI *
                        > >>>     >     \ if exists('b:matchparen_no_insertmode') |
                        > >>>     >     \     if b:matchparen_no_insertmode |
                        > >>>     >     \         return |
                        > >>>     >     \     endif
                        > >>>     >     \ elseif exists('g:matchparen_no_insertmode') &&
                        > >>>     > g:matchparen_no_insertmode |
                        > >>>     >     \     return |
                        > >>>     >     \ endif |
                        > >>>     >     \ ...
                        > >>>     > #v-
                        > >>>     >
                        > >>>     > This gets you the filetype-specific disabling (in a little more
                        > >>>     > roundabout way, by setting b:matchparen_no_insertmode in
                        > >>>     > ~/.vim/after/ftplugin/{filetype}.vim), and you can also disable
                        > >>>     manually
                        > >>>     > for the current buffer, for all buffers in a particular subdirectory /
                        > >>>     > of a certain file size / matching a certain pattern / etc.
                        > >>>     >
                        > >>>     > I use this idiom in a couple of my plugins, and I've found it more
                        > >>>     > flexible than a list of configurable filetypes.
                        > >>>
                        > >>>     Agreed, using a buffer-local variable is better than trying to use a
                        > >>>     pattern to match filetypes.
                        > >>
                        > >> After thinking some more about it, I've come to the conclusion that all
                        > >> attempts so far step around the central issue: The maximum matchparen
                        > >> delay in insert mode is too large, so that it noticeably affects typing.
                        > >> We shouldn't work around this, neither by globally disabling in insert
                        > >> mode, nor through any of the proposed filetype- or buffer-local
                        > >> configurations.
                        > >>
                        > >> Instead, let's just reduce the maximum allowable delay in insert mode,
                        > >> as this also is much simpler to do. The plugin contains a hard-coded
                        > >> maximum of 300 ms; attached patch reduces that somewhat arbitrarily to a
                        > >> fifth, hopefully unnoticeable 60 ms. This way, there's no need to
                        > >> configure anything, and you still reap the benefits of matchparen in
                        > >> most cases, even for problematic files / file types. This only leaves
                        > >> out old Vim versions that don't have the {timeout} argument on
                        > >> searchpairpos(), but as you're the first to raise this issue, it may not
                        > >> be that widespread to bother.
                        > >
                        > > Thanks, makes sense.
                        > >
                        > > So, how do we decide on the timeout?  300 msec is too much, 60 msec is
                        > > OK?  Perhaps we should make this time configurable.
                        >
                        > If Fanhe agrees with the proposed change, I'd rather not make it more
                        > complex so far. Although I'm usually a big proponent of configurability,
                        > the values seem to be fine for 99,99% of users, and a maximum, corner
                        > case delay of 1/3 s while moving around seems as reasonable as a barely
                        > noticeable 60 ms while typing.

                        It's not so complicated:

                        if !exists("g:matchparen_timeout")
                          let g:matchparen_timeout = 300
                        endif
                        if !exists("g:matchparen_insert_timeout")
                          let g:matchparen_insert_timeout = 60
                        endif

                        ...


                          if mode() == 'i' || mode() == 'R'
                            let timeout = exists("b:matchparen_insert_timeout") ? b:matchparen_insert_timeout : g:matchparen_insert_timeout
                          else
                            let timeout = exists("b:matchparen_timeout") ? b:matchparen_timeout : g:matchparen_timeout
                          endif

                        --
                        ZOOT:  I'm afraid our life must seem very dull and quiet compared to yours.
                               We are but eightscore young blondes, all between sixteen and
                               nineteen-and-a-half, cut off in this castle, with no one to protect us.
                               Oooh.  It is a lonely life ... bathing ...  dressing ... undressing ...
                               making exciting underwear....
                                         "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                         /// 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.
                         
                         
                      Your message has been successfully submitted and would be delivered to recipients shortly.