Making vterm snappy by setting "vterm-timer-delay" to nil

Vterm in emacs is awesome, except I've always felt a "tiny" lag between pressing a command (like "ls") and the results showing up. I thought it was just an inevitable drawback of emulating a terminal in Emacs, **until today I discovered that "vterm-timer-delay"'s default value is 0.1.** Setting it to **nil** makes vterm as **snappy** as any other external emulators I've used. *Does anybody know why it's set to 0.1 by default? Prevent performance issues?*

From the doc strting: > A larger delary improves performance when receiving large bursts of data.

Hmm i wonder if there is a similar variable to set for global emacs to make it feel more snappy

Native comp has been pretty good

Roughly speaking, vterm has a terminal emulator as a separate (binary) library (libvterm), a bit of emacs-specific binary code to enable that code to communicate with emacs, and a bit of emacs lisp to tell your emacs process how to talk to that binary terminal. Semantically, it’s close to two separate programs that talk to each other. If the code that bridges these two parts were to send every tiny bit of information back and forth as soon as it could, the actual pieces of information it would say each time would be very small, and the combination of emacs+libvterm would spend a lot of time and effort on the overhead of “hey, tell emacs this” and “ok, now tell libvterm this”. On the other hand, if the bridge code waited a very long time, there would be relatively little overhead — each part would spend most of its time doing the thing it’s best at, and occasionally they’d talk back and forth, then get back to doing their thing. This is especially good if either side wants to do it’s own thing for a while — like vterm scrolling a giant log file or emacs parsing a big C++ buffer. The downside here is that the longer the bridge waits to relay, the longer you wait to see the results of what you’re doing — the other side literally doesn’t know that you’ve told it to do something, or that there’s something new to show you, etc. Somebody picked 0.1 as a default delay for the bridge to wait and gather data before it switches to talking back and forth. Generally, this is a pretty good number, as humans generally perceive systems that respond very close to one-tenth of a second or less as instantaneous. This doesn’t mean that people never notice “lag” that high, but that if the system usually responds that fast or faster, humans generally don’t notice it in most situations. Some people are more sensitive, and some systems have their own added overhead (for example, if your computer is otherwise busy, emacs+vterm might be sharing enough cpu time with other processes that the effective delay goes above the notice threshold). On the other hand, emacs (and vterm) spend the majority of their time, as measured by the clock on the wall, waiting for the user to do something. Also, people who use vterm tend to care more about the terminal performance part than most emacs users (who can instead use one of the pure-emacs terminal packages that come built-in), so some percentage of them want the terminal-focused parts to be able to do their terminal-focused things as fast as possible, which means fewer interruptions to sync back and forth. Hope that helps!

me using native comp with pgtk but still kinda feels a tad bit laggy compared to neovim in alacritty

You might get the same benefit from 0.01 with a lot less resource usage.