> The buffer is the UI, rendered by Emacs's extremely optimised text display machinery<p>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 long-line issue is real, though my statement was specifically about building UIs with widgets/overlays/text properties - not handling arbitrary files. In that context, Emacs's display engine is genuinely well-optimized: it handles overlays, faces, text properties, and redisplay regions efficiently.<p>When you're building a UI, you control the content. Lines are short by design (form fields, buttons, lists). The pathological case of a 50KB minified JSON line simply doesn't occur.<p>The long-line problem stems from how Emacs calculates display width for bidirectional text and variable-pitch fonts - it needs to scan the entire line. That's orthogonal to rendering widgets or interactive buffers.
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?<p>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.<p>Generally though, for everyday use, Emacs feels a lot snappier than VSCode.
Good point. Though for widget UIs you're typically rendering structured data you control, not parsing arbitrary text files. The syntax highlighting / validation concern applies to editing code, not to building interactive interfaces.<p>> Generally though, for everyday use, Emacs feels a lot snappier than VSCode.<p>+1
<i>The buffer is the UI, rendered by Emacs's extremely optimised text display machinery</i><p>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.
Not every modern editor. Neovim bogs on long lines too.
<a href="https://emacs.stackexchange.com/questions/598/how-do-i-prevent-extremely-long-lines-making-emacs-slow" rel="nofollow">https://emacs.stackexchange.com/questions/598/how-do-i-preve...</a> has some answers (and solutions).