Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xxx took too long, syntax highlighting disabled #4838

Open
dimaqq opened this issue Oct 2, 2024 · 2 comments
Open

xxx took too long, syntax highlighting disabled #4838

dimaqq opened this issue Oct 2, 2024 · 2 comments
Labels

Comments

@dimaqq
Copy link

dimaqq commented Oct 2, 2024

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 dimaqq added the bug label Oct 2, 2024
@nospam2998
Copy link
Contributor

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
Copy link
Author

dimaqq commented Oct 16, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants