> The buffer is the UI, rendered by Emacs's extremely optimised text display machinery

Doesn't emacs lag like crazy in files with large lines. Why is this still a problem? Every modern editor handles this gracefully. I remember reading something about using regexes for syntax highlighting. This looks like a problem in the rendering layer which shouldn't be too hard to fix without touching the core engine. Are there any other problems that make it difficult to fix without disabling any useful features?

The buffer is the UI, rendered by Emacs's extremely optimised text display machinery

The author is known in the community as a mere packager whose knowledge of the nitty-gritty derives entirely from hearsay. Perhaps he read the long-winded preamble to xdisp.c written in 1995 boasting of all manner of optimisations. But they were written so long ago, almost no one believes most of them matter anymore, what with thirty years of bitrot.

Right- but if you have a long line that is, for example, a JSON object, then surely it can't be properly be validated or syntax-highlighted before the entire line is scanned?

I do agree that Emacs can be slower than the terminal when handling long lines/files, although (depending on your case) this can be easily mitigated by running a terminal inside of Emacs.

Generally though, for everyday use, Emacs feels a lot snappier than VSCode.

Not every modern editor. Neovim bogs on long lines too.

https://emacs.stackexchange.com/questions/598/how-do-i-preve... has some answers (and solutions).