From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs graphical frontends / responsiveness Date: Sun, 20 Oct 2024 22:30:15 +0300 Message-ID: <861q0ainco.fsf@gnu.org> References: <6cadfc93-3fc5-4fcf-b0a6-f54774c36f43@wz.ht> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19566"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Jordan Ellis Coppard Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 20 21:31:10 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1t2bdu-0004vH-0I for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Oct 2024 21:31:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t2bdI-00083a-Ix; Sun, 20 Oct 2024 15:30:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t2bd7-000831-TK for emacs-devel@gnu.org; Sun, 20 Oct 2024 15:30:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t2bd6-0000wb-VC; Sun, 20 Oct 2024 15:30:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=TEeoX2TqjCI3kjkLqEjESD5RtbmkmU2G6dpwR/i23gY=; b=Evq5iFpJB1YJ RSUV4QmCGinoaetJWU1MsSoMOjlY/q8xrRG7auFMgzJe3T9O95UZFEk+E9H/jfyES9zWOzsE7A4qE X+cQ69GwkRzplP7hpVN7lnW7mRfm7gh02HLcXK7xfVL2uKkmNtvFpL/AAaYw/qXK8IdkQvSaA1rj5 7BhyxCdk3DTNYJPNaLAtiYNSBLpTngYSmgktGs+ZT756FZfkKCv0RyR1P7GSXQ7k536MlxDL4RQxH HPpVjucvbGxqqJE49m6DXreTqzhxarR/ZNIptDJRGIGA5sPnEOyRVSq2+dtfVvxPeVZOQkn5ySZsR L/dbg/3FZRz5oOtNu8eVlg==; In-Reply-To: <6cadfc93-3fc5-4fcf-b0a6-f54774c36f43@wz.ht> (message from Jordan Ellis Coppard on Mon, 21 Oct 2024 03:46:05 +0900) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:324692 Archived-At: > Date: Mon, 21 Oct 2024 03:46:05 +0900 > From: Jordan Ellis Coppard > > One thing that bothers me without fail is how slow, visually, Emacs is. This is partly true (but for good reasons, see below), and partly an illusion based on wrong expectations (also see below). > I can often times type faster than the GUI can keep up, with noticeable > hitching and delays from when I have typed a character to the point > where I see it in a buffer and so forth. This is probably one of the > biggest things ruining my experience because no matter how focused I am > on the task at hand seeing this behaviour always rips me out of focus. > That's also why I feel less productive with Emacs. This is too general. Please describe specific situations where this happens, and please accompany that by the list of optional features you have turned ON (or try the experiments in "emacs -Q" and see if the GUI still cannot keep up). As you might know, some optional features work by using a post-command-hook, which basically calls some Lisp when Emacs finishes to process a command. And since each keyboard input event is a command in Emacs, the responsiveness is being slowed by these post-command activities. Turn on too many of such features, and you have a slowly-responding Emacs. > I run a fairly lean Emacs configuration, however even basic behaviour > under `emacs -Q` is slow. Take `show-paren-mode` with `show-paren-delay` > set to 0; Helix, VS Code, Neovim are able to instantly highlight matched > brackets as I move my cursor around. With Emacs there is a noticeable > delay (yes even with a delay of 0 and in `emacs -Q`). show-paren-delay runs off the idle timer, which means it only kicks in when Emacs detects that it's "idle": it processed the last command and has no pending input. Even if you set the delay to zero, the function which looks for and highlights the matching paren will only be called when Emacs is idle. If you type fast enough, it will _never_ be called. This is by design: most of such features (at least those of them that are well-designed) are coded to stay away and not to interfere with the fast typists among us. I guess similar features in Helix, Neovim, etc. are based on different principles. If you want an immediate highlighting of the matching parens in Emacs, you will need a different mode, not show-paren-mode. > Often times I can type faster than the minibuffer input area can > handle when filtering completion candidates e.g. `C-h o`. Once again, tell the details. Depending on the back-end of the completion (i.e. the way completion candidates are generated), this could be slow, indeed. But the basic completion is quite fast. I just typed "C-h o f TAB" and got an immediate popup with the list of candidates -- and that was in an unoptimized debugging build. If you see something else, please tell the details. > I don't want my editor (or whatever specific title you'd like to apply) > to EVER not immediately respond to input unless it's crashed. See above: some interactive features of Emacs are designed to only kick in when Emacs is idle, so as not to slow down fast typists. So what you say above is either an over-generalization, or maybe you don't like this design principle, in which case you will need to look for alternative implementations of the relevant features. > I don't want my editor running locally only accessing local > resources to feel like an ssh connection with 200 ms of latency when > nothing else, nor any other editor I've tried, does. Again: details, please. When taken at face values, the above is simply false, based on 30 years of using Emacs. > I recently saw in this mailing list Yuan benchmark character insertion > into a buffer (with syntax highlighting) at around ~30 ms (if I recall > correctly). That's an update rate of 33 times a second, with presumably > (for benchmarking's sake) nothing else going on; thus one would assume > even lower update rates if you use a few features here and there > built-in or otherwise. Emacs struggling to update display in under 16 ms > was... shocking to see. This part is a price we pay for having such a complete and flexible control on what Emacs does and how it processes and shows stuff. The fact that each input event is bound to a command, the fact that these bindings go through keymaps (which is necessary to allow customizations of the bindings by major and minor modes), the fact that many commands have hooks which can be and are used to customize what the command does and what is done to the editor's state as result of performing a command, the fact that a Lisp extension can create a simple data structure which affects how Emacs displays a certain portion of buffer text (i.e., the display code must consult Lisp data structures and sometimes run Lisp code) -- these and many other features don't come for free. If you want to understand why character insertion with syntax highlighting is so "slow" in Emacs, you need to study the processing triggered by inserting a single character, and realize and appreciate the level of customizability, flexibility, and control a user-defined Lisp program can have on this processing. This is what makes Emacs what it is! This is why people who like Emacs and use it for their production tasks will never agree to have an editor that is less powerful, less flexible, less able to control everything it does. > I also recently read this post: > https://gist.github.com/ghosty141/c93f21d6cd476417d4a9814eb71dd46e -- > which left me feeling quite sad (if it is accurate) regarding the > internals surrounding the GUI and so how apparently needlessly difficult > in today's age it would/will be to improve (over how it currently is). I > understand the historical legacy. That blog wants to make a point by exaggerating some aspects of Emacs and presenting others as hopelessly outdated. I invite you to read the code and make up your own mind. > So I ask: is it possible that Emacs' GUI be decoupled from the lisp core > such that updates can happen as fast as possible (less perceived delay), > and that the (what I gather from the above post) rube goldberg display > internals be remade from scratch, or more likely, a new frontend (from > scratch) as an alternative? I don't know if it's possible. I do know that it is very hard, because Emacs wants to control the GUI completely -- and it must do so to let our users do the crazy, sometimes insane, stuff by writing relatively simple Lisp. If someone knows how to decouple while keeping what makes Emacs Emacs -- such ideas, let alone code, will be very welcome. > Besides the criticisms: Emacs, so far, is amazing. I can make it do > whatever I want, however I want, and mould it to be uniquely my own > which is something I cannot do with anything else. The effort from > scores of people over ~40 years as well as the continued effort shows. I > can't imagine so much effort or such an enduring project. You need to understand that this comes at a price. As the saying goes, "the impossible we do immediately; miracles take a little longer". Eventually, the insane amount of processing Emacs needs to do in order to provide the expected flexibility and control hits the bare machine performance wall. When that happens, my best advice is to buy a faster machine and/or optimize the optional features you turn ON. Happy hacking!