dense-analysis / ale

Check syntax in Vim/Neovim asynchronously and fix files, with Language Server Protocol (LSP) support
BSD 2-Clause "Simplified" License
13.58k stars 1.44k forks source link

xxx took too long, syntax highlighting disabled #4838

Open dimaqq opened 1 month ago

dimaqq commented 1 month ago

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/python@3.12/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.

nospam2998 commented 1 month ago

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?

dimaqq commented 1 month ago

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.