Describe the bug
When editing a markdown file, which usually have long lines, I get the following error when I want to type the square bracket when editing my text (i.e. I am in insert mode).
Error detected while processing function 15_Highlight_Matching_Pair:
line 107
E363: pattern uses more memory than maxmempattern.
To Reproduce
Not sure. A markdown file of 200KB with at least 2323 lines. See more details later.
Expected behavior
I expect no error to occur and no funky cursor behavior.
Environment (please complete the following information):
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Mar 3 2020 21:29:07)
macOS version
Included patches: 1-319
Compiled by Homebrew
Huge version with MacVim GUI. Features included (+) or not (-):
+acl +file_in_path +mouse_urxvt -tag_any_white
+arabic +find_in_path +mouse_xterm -tcl
+autocmd +float +multi_byte +termguicolors
+autochdir +folding +multi_lang +terminal
-autoservername -footer -mzscheme +terminfo
+balloon_eval +fork() +netbeans_intg +termresponse
+balloon_eval_term +fullscreen +num64 +textobjects
+browse -gettext +odbeditor +textprop
++builtin_terms -hangul_input +packages +timers
+byte_offset +iconv +path_extra +title
+channel +insert_expand +perl +toolbar
+cindent +job +persistent_undo +transparency
+clientserver +jumplist +popupwin +user_commands
+clipboard +keymap +postscript +vartabs
+cmdline_compl +lambda +printer +vertsplit
+cmdline_hist +langmap +profile +virtualedit
+cmdline_info +libcall -python +visual
+comments +linebreak +python3 +visualextra
+conceal +lispindent +quickfix +viminfo
+cryptv +listcmds +reltime +vreplace
+cscope +localmap +rightleft +wildignore
+cursorbind +lua +ruby +wildmenu
+cursorshape +menu +scrollbind +windows
+dialog_con_gui +mksession +signs +writebackup
+diff +modify_fname +smartindent -X11
+digraphs +mouse -sound -xfontset
+dnd +mouseshape +spell +xim
-ebcdic +mouse_dec +startuptime -xpm
+emacs_tags -mouse_gpm +statusline -xsmp
+eval -mouse_jsbterm -sun_workshop -xterm_clipboard
+ex_extra +mouse_netterm +syntax -xterm_save
+extra_search +mouse_sgr +tag_binary
-farsi -mouse_sysmouse -tag_old_static
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "/.vim/vimrc"/.vim/gvimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "
defaults file: "$VIMRUNTIME/defaults.vim"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/Applications/MacVim.app/Contents/Resources/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe -DMACOS_X -DMACOS_X_DARWIN -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang -L. -fstack-protector-strong -L/usr/local/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/openssl@1.1/lib -L/usr/local/opt/readline/lib -L. -fstack-protector-strong -L/usr/local/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/openssl@1.1/lib -L/usr/local/opt/readline/lib -L/usr/local/lib -o Vim -framework Cocoa -framework Carbon -lm -lncurses -liconv -framework AppKit -L/usr/local/opt/lua/lib -llua5.3 -fstack-protector -L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE -lperl -L/usr/local/opt/python/Frameworks/Python.framework/Versions/3.7/lib/python3.7/config-3.7m-darwin -lpython3.7m -framework CoreFoundation -lruby.2.7
Additional context
File is slightly over 200KB. It is a markdown file. Problem started appearing as I was typing. I wanted to use the markdown notation: . But the second I hit the '[' keyboard button, this error popped up with funky cursor behavior. If I save the file which has only the [ character and open it back up, the error reappears when the file is re-opened. It seems like I hit some error where the file size is too big but not sure what the problem is.
Also, the problem seems to only appear in the middle of the file (i.e not the very beginning or the very end) but if I start modifying text in line 282 of 2323 lines markdown text file, the misbehavior is seen.
Any ideas? Is VIM not capable of handling that much text?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.![]()
Also, here is my .gvimrc:
syntax on
set nocompatible
set tabstop=2
set autoindent
set smartindent
set mousemodel=extend
set incsearch
set showcmd
set cindent
set history=1000
set guioptions+=a
set hlsearch
set shiftwidth=2
set laststatus=2
Thanks for any assistance you can provide.
I had to set maxmempattern to 100,000 for the problem to go away. I did not know how much memory I needed but I only tried 5,000, 10,000 and 100,000.
Why do I need to do this? And is this the correct solution? I may hit the limit again if I type more text.
Why do I need to do this?
It seems the error comes from the matchparen plugin. Specifically, from this line:
https://github.com/vim/vim/blob/ec792290eb902e01c9edfc0cb71e5235833df56a/runtime/plugin/matchparen.vim#L144
:h E363 suggests that either the pattern c passed to searchpos() is too inefficient/complex, or it's used against very long lines.
And is this the correct solution?
There are other solutions:
you could hard wrap the lines earlier, to avoid the buffer having very long lines
you could toggle the matchparen plugin in markdown files
au DisableMatchParenInMarkdownFiles | au!
au BufEnter * if &ft ==# 'markdown' | exe 'NoMatchParen' | else | exe 'DoMatchParen' | endif
augroup END
you could use an alternative plugin to the builtin matchparen, hoping that one of them is more efficient:
matchparen module from vim-matchupI'll leave it to you to decide which of these solutions is the correct one.
I had to set maxmempattern to 100,000 for the problem to go away. I did not know how much memory I needed but I only tried 5,000, 10,000 and 100,000.
[...]
I may hit the limit again if I type more text.
100,000 is still well below the maximum limit of 2,000,000. It should be ok to increase it more if needed.
If you don't like increasing the option permanently, you could increase it only in markdown files:
au IncreaseMmpInMarkdownFiles | au!
au BufEnter * if &ft ==# 'markdown' | set mmp = 100000 | else | set mmp&vim | endif
augroup END
You could even write something more sophisticated, so that the option is only increased when the buffer contains very long lines. If you're interested, ask how to do it on vi.stackexchange.com.
Btw, :DoMatchParen and :NoMatchParen would benefit from being defined with the -bar argument so that we can execute them in if condition | exe 'NoMatchParen' | endif, without the awkward :exe:
diff --git a/runtime/plugin/matchparen.vim b/runtime/plugin/matchparen.vim index 162430ecd..d7dbfa710 100644 --- a/runtime/plugin/matchparen.vim +++ b/runtime/plugin/matchparen.vim @@ -202,8 +202,8 @@ endfunc " Define commands that will disable and enable the plugin. -command DoMatchParen call s:DoMatchParen() -command NoMatchParen call s:NoMatchParen() +command -bar DoMatchParen call s:DoMatchParen() +command -bar NoMatchParen call s:NoMatchParen() func s:NoMatchParen() let w = winnr()
In any case, this is a valid error, not an internal one. And it is expected to be sometimes raised, especially when working on files with very long lines. So, I don't think it's a bug.
I just want to point out that it also happens in Python
https://vi.stackexchange.com/questions/48672/how-to-fix-error-e363-that-causes-the-code-to-go-black-white
There's also steps to reproduce in the post above
virtualenv venv
$ ./venv/bin/pip3 install mako
$ vi venv/lib/python3.14/site-packages/mako/exceptions.py
Start editing right after the lines
from mako import compat
from mako import util
print(f"{ <= this is where the error occurs
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.![]()
Regardless, in today's AI code, where the AI write a giant file App.tsx, i just vi the file and receive a slowness like hell, very quickly i'm receiving tons of errors and I just move to SublimeText.
I think this is something that should be looked into, otherwise, I can't work with VI ...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
I am guessing you are using MacOS Vim version. Please verify with latest master version
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
I am closing this one here, it seems to have stalled. If you still encounter it, please give a reproducible example using vim --clean and show the complete version output.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
I am guessing you are using MacOS Vim version. Please verify with latest master version. Please always provide full version number
Yes
$ vim --version
VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Apr 18 2026 20:29:32)
macOS version - arm64
Included patches: 1-1752
Compiled by ro...@apple.com
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()