3 ms·

I don't care that much about the implementation, but I would like to see an emacs environment with: - instant startup - blazingly fast scrolling - minimal ke

I don't care that much about the implementation, but I would like to see an emacs environment with: - instant startup - blazingly fast scrolling - minimal keypress-to-display latency I have written a lot of elisp (and had to deal with with buffer variables, dynamic scope, etc.), but aligning with modern scheme or lisp (if it can be kept compact and efficient) probably makes sense at this point. (Current emacs should provide backward compatibility as needed.) Since so many people use emacs as an IDE, I think having an official emacs co-project/subproject focusing on a standard, extensible IDE framework (perhaps for other apps as well) would make sense. It still seems like a pain to display graphics in emacs in various terminal apps. This should be easy, fast, and standardized. As others have noted, supply chain attacks against open source are rampant, so vetting and sandboxing packages seems to be more important now.

lysace 2y ago
I'm confused. On the modern devices I've recently used emacs on (including very low-powered raspberry pi devices), all of your three criteria are already true. What kind of HW are you running emacs on where this isn't the case?
- arghnoname 2y ago
  Emacs pauses are almost always due to some operation blocking in the main thread. It's pretty annoying and is mostly a consequence to a lot of things effectively being single-threaded. Stock emacs doesn't do this very often, but third party packages that might do expensive tasks often do
  - lysace 2y ago
    Ah. A case of "don't do that, then".
  - iLemming 2y ago
    a) Build it with native-compilation flag b) Use https://github.com/blahgeek/emacs-lsp-booster https://github.com/blahgeek/emacs-lsp-booster c) Tweak GC vars, see: https://emacs-lsp.github.io/lsp-mode/page/performance/ https://emacs-lsp.github.io/lsp-mode/page/performance/ d) Use plists for deserialization (described in the previous link) e) Learn how to use built-in profiler and don't hesitate to launch it, sometimes simply disabling some minor-mode in specific setting is all it takes f) Current state of Tree-sitter in Emacs is a mixed bag - for some modes you get huge improvements, for others it's the opposite. YMMV.
- musicale 2y ago
  This is from 2015, but emacs still has higher typing latency than vim in 2024. https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/ If you have better numbers and comparisons for emacs keypress-to-pixel latency, etc. I'd be interested. Note classic vi started up faster than vim. Device makes little to no difference: Raspberry Pi 5, MacBook Pro M1, ThinkPad P1, etc. - emacs is clunky on all of them. I like emacs and it's my daily driver. But it isn't fast. see also: "Computer latency: 1997-2017" https://danluu.com/input-lag/ https://danluu.com/input-lag/ "Measuring keyboard-to-photon latency with a light sensor" https://thume.ca/2020/05/20/making-a-latency-tester/ https://thume.ca/2020/05/20/making-a-latency-tester/
  - znpy 2y ago
    I have often see some fellow coworkers start up their fairly complex vim/neovim/other-vim setups and quite frankly… they ended up recreating a poor emacs implementation. Yeah it’s faster at starting up but it’s worse in pretty much everything else. Oh and they end up typing Ctrl-this Ctrl-that anyway. Might as well use gnu emacs.
- hollerith 2y ago
  Receiving output from a process, as is done for example by shell mode and (I guess, but have not verified) compilation mode, is slow in Emacs because all output is run through comint-carriage-motion and ansi-color-filter-region (which does nothing but throw color information away IIRC) which are written in Elisp. If you don't run the output through those 2 functions, then non-printing characters remain in the output that severely undermine legibility. C programmers tend to develop the ability to glean information from the voluminous output of build processes as it goes whizzing by on a terminal, so they find compilation mode frustratingly slow. Or at least that is my guess as to what happens.
wging 2y ago
For instant startup I recommend daemon mode and emacsclient. Start emacs via emacs --daemon, open windows (in the terminal or otherwise) via `emacsclient` / `emacsclient -nc` (I use aliases for these).
- musicale 2y ago
  Yep, warm start is the only way to go unfortunately. But I want a fast start from cold boot like classic vi.
  - sping 2y ago
    Though trying to run Emacs like vi is a pitfall in itself. Clunking around the terminal summoning Emacs to edit files is really not a particularly effective way to use it. Emacs is not vi, and using Emacs like Emacs makes more sense. Most users explore your filesystem and spawn and monitor processes from within Emacs, rather than from a terminal. Not that you can't work that way (and using `emacsclient` is the way to do it), but you're losing out by trying to shoe-horn usage patterns familiar from other toolchains onto Emacs. Emacs is not a text editor, it's a text manipulation platform that includes an editor - a number of editors in fact, including a vim clone.
  - rbc 2y ago
    I think running daemon mode has significant advantages. You can have frames running on multiple virtual desktops for different uses. You can also step away from a buffer, and return to it, maybe from some other location on a different computer.
- perihelions 2y ago
  I wrap my slow .emacs loads inside #'run-with-idle-timer so they run when I'm not looking, and not likely to notice.
  - andbberger 2y ago
    what is this point of this, when would you not be using emacs?
iLemming 2y ago
> instant startup My config is Doom-based. I use about 300 different third-party packages, and I don't even know how many built-in ones. It takes about 1.3s to start. Wishing for it to start even faster is like wanting my microwave to warm my tortilla in 5 seconds instead of 30. I don't restart Emacs every day, nor do I eat tortillas daily. Use a modern package-manager, and defer the loading of packages, it will start very fast - just like 'emacs -q' does. > minimal keypress-to-display latency A lot of times, setting keyboard rate is all it takes to make it nice, On Linux: xset r rate 170 80 On Mac: defaults write NSGlobalDomain KeyRepeat -int 1 defaults write NSGlobalDomain InitialKeyRepeat -int 10

lysace 2y ago

I'm confused. On the modern devices I've recently used emacs on (including very low-powered raspberry pi devices), all of your three criteria are already true. What kind of HW are you running emacs on where this isn't the case?

arghnoname 2y ago
Emacs pauses are almost always due to some operation blocking in the main thread. It's pretty annoying and is mostly a consequence to a lot of things effectively being single-threaded. Stock emacs doesn't do this very often, but third party packages that might do expensive tasks often do
- lysace 2y ago
  Ah. A case of "don't do that, then".
- iLemming 2y ago
  a) Build it with native-compilation flag b) Use https://github.com/blahgeek/emacs-lsp-booster https://github.com/blahgeek/emacs-lsp-booster c) Tweak GC vars, see: https://emacs-lsp.github.io/lsp-mode/page/performance/ https://emacs-lsp.github.io/lsp-mode/page/performance/ d) Use plists for deserialization (described in the previous link) e) Learn how to use built-in profiler and don't hesitate to launch it, sometimes simply disabling some minor-mode in specific setting is all it takes f) Current state of Tree-sitter in Emacs is a mixed bag - for some modes you get huge improvements, for others it's the opposite. YMMV.
musicale 2y ago
This is from 2015, but emacs still has higher typing latency than vim in 2024. https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/ If you have better numbers and comparisons for emacs keypress-to-pixel latency, etc. I'd be interested. Note classic vi started up faster than vim. Device makes little to no difference: Raspberry Pi 5, MacBook Pro M1, ThinkPad P1, etc. - emacs is clunky on all of them. I like emacs and it's my daily driver. But it isn't fast. see also: "Computer latency: 1997-2017" https://danluu.com/input-lag/ https://danluu.com/input-lag/ "Measuring keyboard-to-photon latency with a light sensor" https://thume.ca/2020/05/20/making-a-latency-tester/ https://thume.ca/2020/05/20/making-a-latency-tester/
- znpy 2y ago
  I have often see some fellow coworkers start up their fairly complex vim/neovim/other-vim setups and quite frankly… they ended up recreating a poor emacs implementation. Yeah it’s faster at starting up but it’s worse in pretty much everything else. Oh and they end up typing Ctrl-this Ctrl-that anyway. Might as well use gnu emacs.
hollerith 2y ago
Receiving output from a process, as is done for example by shell mode and (I guess, but have not verified) compilation mode, is slow in Emacs because all output is run through comint-carriage-motion and ansi-color-filter-region (which does nothing but throw color information away IIRC) which are written in Elisp. If you don't run the output through those 2 functions, then non-printing characters remain in the output that severely undermine legibility. C programmers tend to develop the ability to glean information from the voluminous output of build processes as it goes whizzing by on a terminal, so they find compilation mode frustratingly slow. Or at least that is my guess as to what happens.

wging 2y ago

For instant startup I recommend daemon mode and emacsclient. Start emacs via emacs --daemon, open windows (in the terminal or otherwise) via `emacsclient` / `emacsclient -nc` (I use aliases for these).

musicale 2y ago
Yep, warm start is the only way to go unfortunately. But I want a fast start from cold boot like classic vi.
- sping 2y ago
  Though trying to run Emacs like vi is a pitfall in itself. Clunking around the terminal summoning Emacs to edit files is really not a particularly effective way to use it. Emacs is not vi, and using Emacs like Emacs makes more sense. Most users explore your filesystem and spawn and monitor processes from within Emacs, rather than from a terminal. Not that you can't work that way (and using `emacsclient` is the way to do it), but you're losing out by trying to shoe-horn usage patterns familiar from other toolchains onto Emacs. Emacs is not a text editor, it's a text manipulation platform that includes an editor - a number of editors in fact, including a vim clone.
- rbc 2y ago
  I think running daemon mode has significant advantages. You can have frames running on multiple virtual desktops for different uses. You can also step away from a buffer, and return to it, maybe from some other location on a different computer.
perihelions 2y ago
I wrap my slow .emacs loads inside #'run-with-idle-timer so they run when I'm not looking, and not likely to notice.
- andbberger 2y ago
  what is this point of this, when would you not be using emacs?

iLemming 2y ago

> instant startup My config is Doom-based. I use about 300 different third-party packages, and I don't even know how many built-in ones. It takes about 1.3s to start. Wishing for it to start even faster is like wanting my microwave to warm my tortilla in 5 seconds instead of 30. I don't restart Emacs every day, nor do I eat tortillas daily. Use a modern package-manager, and defer the loading of packages, it will start very fast - just like 'emacs -q' does. > minimal keypress-to-display latency A lot of times, setting keyboard rate is all it takes to make it nice, On Linux: xset r rate 170 80 On Mac: defaults write NSGlobalDomain KeyRepeat -int 1 defaults write NSGlobalDomain InitialKeyRepeat -int 10