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
    ... 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 1 of 19 , May 7, 2013
    • 0 Attachment
      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 2 of 19 , May 7, 2013
      • 0 Attachment
        > 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 3 of 19 , May 13, 2013
        • 0 Attachment
          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.