ale icon indicating copy to clipboard operation
ale copied to clipboard

xxx took too long, syntax highlighting disabled

Open dimaqq opened this issue 1 year ago • 2 comments

I've found a pathological case where vim becomes almost unusable.

The trick is to open a file that's not really a Python file, but try to syntax highlight it and annotated with pyright errors as if it were Python code.

Note that syntax highlighting alone works well enough.

Information

VIM version

VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Aug 28 2024 20:08:35)
macOS version - arm64
Included patches: 1-700
Compiled by Homebrew
Huge version without GUI.  Features included (+) or not (-):
+acl               +cindent           +cursorshape       +file_in_path      +job               +menu              +mouse_urxvt       +popupwin          +signs             -tag_any_white     +user_commands     +windows
+arabic            -clientserver      +dialog_con        +find_in_path      +jumplist          +mksession         +mouse_xterm       +postscript        +smartindent       -tcl               +vartabs           +writebackup
+autocmd           +clipboard         +diff              +float             +keymap            +modify_fname      +multi_byte        +printer           +sodium            +termguicolors     +vertsplit         -X11
+autochdir         +cmdline_compl     +digraphs          +folding           +lambda            +mouse             +multi_lang        +profile           +sound             +terminal          +vim9script        -xattr
-autoservername    +cmdline_hist      -dnd               -footer            +langmap           -mouseshape        -mzscheme          -python            +spell             +terminfo          +viminfo           -xfontset
-balloon_eval      +cmdline_info      -ebcdic            +fork()            +libcall           +mouse_dec         +netbeans_intg     +python3           +startuptime       +termresponse      +virtualedit       -xim
+balloon_eval_term +comments          +emacs_tags        +gettext           +linebreak         -mouse_gpm         +num64             +quickfix          +statusline        +textobjects       +visual            -xpm
-browse            +conceal           +eval              -hangul_input      +lispindent        -mouse_jsbterm     +packages          +reltime           -sun_workshop      +textprop          +visualextra       -xsmp
++builtin_terms    +cryptv            +ex_extra          +iconv             +listcmds          +mouse_netterm     +path_extra        +rightleft         +syntax            +timers            +vreplace          -xterm_clipboard
+byte_offset       +cscope            +extra_search      +insert_expand     +localmap          +mouse_sgr         +perl              +ruby              +tag_binary        +title             +wildignore        -xterm_save
+channel           +cursorbind        -farsi             +ipv6              +lua               -mouse_sysmouse    +persistent_undo   +scrollbind        -tag_old_static    -toolbar           +wildmenu
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
 3rd user vimrc file: "~/.config/vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/opt/homebrew/share/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DMACOS_X -DMACOS_X_DARWIN -g -O2 -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang -o vim -lm -lncurses -lsodium -liconv -lintl -framework AppKit -L/opt/homebrew/opt/lua/lib -llua5.4 -mmacosx-version-min=14.2 -fstack-protector-strong -L/opt/homebrew/opt/perl/lib/perl5/5.38/darwin-thread-multi-2level/CORE -lperl -L/opt/h
omebrew/opt/[email protected]/Frameworks/Python.framework/Versions/3.12/lib/python3.12/config-3.12-darwin -lpython3.12 -framework CoreFoundation -lruby.3.3 -L/opt/homebrew/Cellar/ruby/3.3.4/lib

Reproducing the bug

Run a virualenv with pyright installed (maybe other tools like ruff of mypy would do as well). Grab https://gist.github.com/dimaqq/925afea05590de55abd49ab631612738 Open it in vim. Wait. Wait some more... Watch the screen fill in slowly with annotations.

dimaqq avatar Oct 02 '24 03:10 dimaqq

I'm tempted to suggest it to be a configuration error to run tools on files not intended for them. Yet if assuming there actually are reasons to have such a setup, could you please consider completing the issue by explaining what you would expect the correct behaviour would be and elaborating on how to achieve a better user experience?

rymdbar avatar Oct 15 '24 15:10 rymdbar

Actually I also experience similar, albeit less extreme, issue when editing a file with a merge conflict -- the >>><<<< markers confuse the linter or static type checker and very many errors/warnings are produced.

Overall, I would like non-blocking behaviour, that is, even if the file is 2,000 lines long, vim+extension doesn't spend excessive time annotating every line (?) or every visible line (?) with errors.

ALE is meant to be asynchronous after all!

I think there may be a bad interaction between annotating the code with "fake" comments and the syntax highlighter.

Perhaps it's worth annotating the buffer in chunks? I'm fine waiting a bit for the errors to show, as it takes a while already. I'd like to be able to edit the code while the errors are being processed.

dimaqq avatar Oct 16 '24 08:10 dimaqq

Please try add these, after syntax enable, set re=0

qlixes avatar Feb 09 '25 12:02 qlixes

As far as I can tell, my config has set re=0 already.

dimaqq avatar Feb 24 '25 11:02 dimaqq