| ▲ | seanw444 5 days ago |
| > it does not take full advantage of how good computers are today, e.g. gpu rendering or multicore Why does Emacs need that though? I hear people say this all the time and I don't get it. Multicore kind of works against the structure that Emacs touts as a feature. And GPU rendering? In many applications, I totally agree with these complaints. But it's a text editor. I tried Zed myself, and it's good. But it doesn't dethrone Emacs (for me personally). |
|
| ▲ | vinkelhake 5 days ago | parent | next [-] |
| > But it's a text editor. Long time emacs user here (+20 years, yikes). I've used it on all kinds of computers during this time. Even a relatively modest computer from 2024 is an absolute beast compared to something from the year 2000. With that said, there are text editing operations that can cause it to grind to a complete halt, especially working with large files (or very long lines). And it shouldn't, you know? I think emacs users sort of internalize which operations they should avoid. It's kind of ridiculous to have to do that in a text editor with the massive amounts of compute that our computers have today. |
| |
| ▲ | donio 5 days ago | parent [-] | | > (or very long lines) Long line handling has greatly improved in emacs-29. Multi-megabyte lines are not a problem anymore. | | |
| ▲ | canucker2016 5 days ago | parent [-] | | from Emacs 29.1 NEWS file, https://raw.githubusercontent.com/emacs-mirror/emacs/refs/he... ** Emacs is now capable of editing files with very long lines.
The display of long lines has been optimized, and Emacs should no
longer choke when a buffer on display contains long lines. The
variable 'long-line-threshold' controls whether and when these display
optimizations are in effect.
A companion variable 'large-hscroll-threshold' controls when another
set of display optimizations are in effect, which are aimed
specifically at speeding up display of long lines that are truncated
on display.
|
|
|
|
| ▲ | PittleyDunkin 5 days ago | parent | prev | next [-] |
| > Multicore kind of works against the structure that Emacs touts as a feature. I have consistent issues with emacs locking up when executing network requests. I'm sure there's a specific bug that could be hunted down and addressed, but this sort of thing shouldn't happen much in an editor that's multicore by default. I'm not trying to dismiss emacs' reasoning, of course, but I can understand being disgruntled with it. The actual rendering I've been quite please by, though! |
| |
| ▲ | rgrmrts 5 days ago | parent [-] | | Yeah this is one reason, or Emacs freezing for up to a minute when updating packages. Also when using an LSP I notice latency. I use Emacs GUI (outside of the terminal) and comparing performance for rending to something like Zed or Sublime is definitely noticeable. It’s great that Emacs is so resource efficient but sometimes I wish it used more of my beefy computer(s). Like I said I still love Emacs and it’s okay for it to make a different set of trade-offs. I honestly didn’t think I’d ever switch editors but here we are! | | |
| ▲ | karthink 5 days ago | parent | next [-] | | Removing the interpreter lock for a few specialized tasks (without sweeping runtime changes to Emacs) would be enough to fix most of these issues -- parsing JSON from process output into lisp data in a background thread is one candidate. [1] Installing packages does not need to block either, there is no architectural limitation here. The Elpaca package manager for Emacs provides async, parallel package updates. Loading packages into the Lisp image will block though, there's no way around that. The other big source of input lag is garbage collection, and there are some ongoing efforts to use the MPS library in Emacs for a copying, concurrent GC. This is a big change and I don't know if this experiment will go anywhere, but Eli Zaretskii and co are trying. [1]: https://github.com/emacs-lsp/emacs | | | |
| ▲ | seanw444 5 days ago | parent | prev [-] | | That's fair I guess. In the case of IO that can be an issue. When I hear multicore, I assume we're talking about parallelism, not concurrency. As for LSP, other than the Nim langserver, I've been quite satisfied with Eglot's performance. I'm curious what your setup is like. To be fair, I'm running a highly customized Doom Emacs config, so it's possible I inherited some non-vanilla optimizations I'm not aware of. | | |
| ▲ | PittleyDunkin 5 days ago | parent [-] | | > When I hear multicore, I assume we're talking about parallelism, not concurrency. Parallelism trivially enables concurrency. The lack of parallelism magnifies the issues emacs has with concurrency. |
|
|
|
|
| ▲ | DrBenCarson 5 days ago | parent | prev | next [-] |
| “Need” is strong but using GPU rendering is definitely better than CPU rendering and makes things feel very snappy Most new TTY projects use GPUs for that reason |
|
| ▲ | kevin_thibedeau 5 days ago | parent | prev [-] |
| GPU rendering simplifies smooth text scrolling which used to be a thing on some dumb terminals and microcomputers like Amiga that supported it in hardware. Most emulators are locking character cells on a fixed grid and we miss out on such niceties. |
| |
