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

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

Expand Messages
  • 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 1 of 19 , May 7 8:22 PM
      > 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 2 of 19 , May 13 7:03 AM
        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.