4 ms·

If Vim isn’t responsive in a machine with hundreds of MHz something is very wrong with your setup. Vim was fast on machines with dozens of MHz. Either a bad te

If Vim isn’t responsive in a machine with hundreds of MHz something is very wrong with your setup. Vim was fast on machines with dozens of MHz. Either a bad terminal emulator or some plugin making it slow, I’d guess.

pclmulqdq 4y ago
It's probably a plugin. A lot of them are very slow.
- 3np 4y ago
  As far as I understand, neovim has multithreading where vim doesn't here, making heavy and bad plugins have less impact.
pmontra 4y ago
Not vim but vi, it was fast enough for me on machines with less than a dozen MHz, probably high single digit. However we have many more layers now. I had a 80x24 serial tty exchanging ASCII characters with the computer back then.
- gonzo 4y ago
  Yes, but at what baud?
  - pmontra 4y ago
    Probably 4 digits. I was young and not a very fast typer yet. Zenith green phosphor terminals with a repeat key. This one or very similar https://commons.wikimedia.org/wiki/File:Zenith_Z-19_Terminal.jpg https://commons.wikimedia.org/wiki/File:Zenith_Z-19_Terminal... According to https://vt100.net/heath/z19-om.pdf https://vt100.net/heath/z19-om.pdf it can do 110 to 9600 baud. It was connected to some Z8000 based Onyx server. It was generally good but incredibly slow when more than four or five of us were compiling code for the tests at university class. Pascal, Berkeley p system or something with a similar name.
bee_rider 4y ago
So there are two problems I guess, user-based and technical. User problem: since I use Vim for everything, my expectations as far as responsiveness goes are probably not calibrated correctly. It is almost always very good, so the moments of badness are noticeable. The user (me) is unreasonably picky. Technical: LaTeX syntax highlighting. It is I’m pretty sure, generally known to be a bit of a pain. Lots of nested environments that can go back dozens of lines and change how commands are interpreted. It is happy in a decent (not huge or anything) sized Fortran code, so I think config is mostly OK. Maybe I should look around and see if there’s a nice LaTeX plugin out there.
- tambourine_man 4y ago
  I think you found the culprit. Syntax highlighters are notoriously slow. You have every right to have high expectations for performance with Vim
- celrod 4y ago
  Perhaps tree sitter can help the syntax highlighting? https://github.com/latex-lsp/tree-sitter-latex https://github.com/latex-lsp/tree-sitter-latex
  - lhl 4y ago
    Related, but Neovim has experimental treesitter support (w/ Latex) built in these days: https://github.com/nvim-treesitter/nvim-treesitter https://github.com/nvim-treesitter/nvim-treesitter Depending on how hard you push it, Neovim can also be noticeably faster than Vim (notably Lua/LuaJIT being much faster than VimScript)
- pletnes 4y ago
  Some vim plugins are slow. Fortran highlighting used to be super slow for certain use cases 10 years ago. I think there were some bad regexes. Latex documents are often long (cf other code) and the syntax rules are complex.
ObscureScience 4y ago
It's not vim, but the OS/graphical system that you are most likely using underneath. While having Firefox/Chromium open for reference to what you are working on.
- 3np 4y ago
  Specifically worth comparing terminal emulator performance. I noticed that for example (not surprisingly I guess) alacritty has been both the worst and the best depending on the setup.
pengaru 4y ago
There are definitely some pathological situations where vim becomes unresponsive even on a beefy box. Usually there's exceptionally long lines of text involved, esp. with syntax highlighting/:setf active IME. Furthermore there's the whole intentional delay on ESC exit from modes like an aborted search query... that can make it feel unresponsive but it's just a timeout. Try it, hit '/' in vim, then ESC to abort the search, count a full second of unresponsiveness. This blog speaks to such ESC delays one encounters in vim: https://www.johnhawthorn.com/2012/09/vi-escape-delays/ https://www.johnhawthorn.com/2012/09/vi-escape-delays/

pclmulqdq 4y ago

It's probably a plugin. A lot of them are very slow.

3np 4y ago
As far as I understand, neovim has multithreading where vim doesn't here, making heavy and bad plugins have less impact.

pmontra 4y ago

Not vim but vi, it was fast enough for me on machines with less than a dozen MHz, probably high single digit. However we have many more layers now. I had a 80x24 serial tty exchanging ASCII characters with the computer back then.

gonzo 4y ago
Yes, but at what baud?
- pmontra 4y ago
  Probably 4 digits. I was young and not a very fast typer yet. Zenith green phosphor terminals with a repeat key. This one or very similar https://commons.wikimedia.org/wiki/File:Zenith_Z-19_Terminal.jpg https://commons.wikimedia.org/wiki/File:Zenith_Z-19_Terminal... According to https://vt100.net/heath/z19-om.pdf https://vt100.net/heath/z19-om.pdf it can do 110 to 9600 baud. It was connected to some Z8000 based Onyx server. It was generally good but incredibly slow when more than four or five of us were compiling code for the tests at university class. Pascal, Berkeley p system or something with a similar name.

bee_rider 4y ago

So there are two problems I guess, user-based and technical. User problem: since I use Vim for everything, my expectations as far as responsiveness goes are probably not calibrated correctly. It is almost always very good, so the moments of badness are noticeable. The user (me) is unreasonably picky. Technical: LaTeX syntax highlighting. It is I’m pretty sure, generally known to be a bit of a pain. Lots of nested environments that can go back dozens of lines and change how commands are interpreted. It is happy in a decent (not huge or anything) sized Fortran code, so I think config is mostly OK. Maybe I should look around and see if there’s a nice LaTeX plugin out there.

tambourine_man 4y ago
I think you found the culprit. Syntax highlighters are notoriously slow. You have every right to have high expectations for performance with Vim
celrod 4y ago
Perhaps tree sitter can help the syntax highlighting? https://github.com/latex-lsp/tree-sitter-latex https://github.com/latex-lsp/tree-sitter-latex
- lhl 4y ago
  Related, but Neovim has experimental treesitter support (w/ Latex) built in these days: https://github.com/nvim-treesitter/nvim-treesitter https://github.com/nvim-treesitter/nvim-treesitter Depending on how hard you push it, Neovim can also be noticeably faster than Vim (notably Lua/LuaJIT being much faster than VimScript)
pletnes 4y ago
Some vim plugins are slow. Fortran highlighting used to be super slow for certain use cases 10 years ago. I think there were some bad regexes. Latex documents are often long (cf other code) and the syntax rules are complex.

ObscureScience 4y ago

It's not vim, but the OS/graphical system that you are most likely using underneath. While having Firefox/Chromium open for reference to what you are working on.

3np 4y ago
Specifically worth comparing terminal emulator performance. I noticed that for example (not surprisingly I guess) alacritty has been both the worst and the best depending on the setup.

pengaru 4y ago

There are definitely some pathological situations where vim becomes unresponsive even on a beefy box. Usually there's exceptionally long lines of text involved, esp. with syntax highlighting/:setf active IME. Furthermore there's the whole intentional delay on ESC exit from modes like an aborted search query... that can make it feel unresponsive but it's just a timeout. Try it, hit '/' in vim, then ESC to abort the search, count a full second of unresponsiveness. This blog speaks to such ESC delays one encounters in vim: https://www.johnhawthorn.com/2012/09/vi-escape-delays/ https://www.johnhawthorn.com/2012/09/vi-escape-delays/