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

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

Expand Messages
  • Ingo Karkat
    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.
    • Show all 19 messages in this topic