From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ship Mints Newsgroups: gmane.emacs.devel Subject: Re: Emacs graphical frontends / responsiveness Date: Sun, 20 Oct 2024 17:49:31 -0400 Message-ID: References: <6cadfc93-3fc5-4fcf-b0a6-f54774c36f43@wz.ht> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000818ef60624ef8342" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19232"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: jc+o.emacs@wz.ht Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 20 23:50:41 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 1t2dou-0004sF-ME for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Oct 2024 23:50:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t2do6-0005B3-DN; Sun, 20 Oct 2024 17:49:50 -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 1t2do4-0005An-E3 for emacs-devel@gnu.org; Sun, 20 Oct 2024 17:49:48 -0400 Original-Received: from mail-vs1-xe2c.google.com ([2607:f8b0:4864:20::e2c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t2do2-0004s2-2x for emacs-devel@gnu.org; Sun, 20 Oct 2024 17:49:48 -0400 Original-Received: by mail-vs1-xe2c.google.com with SMTP id ada2fe7eead31-4a4861a689eso892143137.2 for ; Sun, 20 Oct 2024 14:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729460982; x=1730065782; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=es4z5i2VA7quYaXtlh0eA1zThhARimPzgPdmb8bD7Tc=; b=iDoWhbJwRwELRxuCalkj97TE+cubxSMZ0HVd0+LtN7029rQCpn2uVi+R4drtVB70Nx Bfk/Q73ssifltmPk1SnjsfFG90CbCwFR8koxrN6OOAg+xuKZC2k+C9syBJsZpS8zpSqw 9UrT6jIZafbptzeENTfzCq2rGxUWk+wzNSvRL/GDjpSIvW80oS4PPMArukYM+n8lWaT8 IKoFXLv8cfgXFRmBjZPXTMpOzTlihXaMeWCPpOcejSk2PMtzzgmiYZAD2CPIXaGWh1b1 5wDUtXRQT0KI9n9y/Pf1OTyPzPmxIARoCvmFlk95Pqlf2e3xp98Ki0HuTD4C+7WEFS8V thcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729460982; x=1730065782; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=es4z5i2VA7quYaXtlh0eA1zThhARimPzgPdmb8bD7Tc=; b=FWWbAIuxvzH00wzWJEuy3LJNAZ+/bj718lxv3X8yeWvkx8SEKbiHSCYhbgB83AoAAE u0VEJ4LoQeUZwohVvmKnf8BJe44pJo8BPUNpCsRZth9v6nBPimIEhRsYPY+Eyrchby0b 1skMT1h22pOEFSexMcf8n68iBqlpTfZ5j5N5pnUqCCqBSVLwzve8WkxXHdCsDcBnBb/P 1C8+Wu2wHQDh5j1OacT7ulUwPo9bnaYFoWCt8L2E58qw32Y78qhGRUJ2dM7D+p2tqtso rDxD1P3uD51OIzs8Se5oXu1VK9V/8PzoLp4HUF1syPqv4KElo+EevjU+FTsgESzF3CrM 1FpQ== X-Gm-Message-State: AOJu0YyMcL2BqGg92Ss1fvgkzcDO05oVh5rqW2JmyPgmrzwS/QV4lRsq LwmaSIFEv0PLYvo49VU/svERAWM36Or6uaA9ZO49AFVwsMdTKbH6YzY5sOJDtgWVCPah3m43Nhd isbjvEOXmFOVNZIVnaJtNaZTudePx+bl8 X-Google-Smtp-Source: AGHT+IHwvAhlYwAMl6aYHvSlcjqL6CNXG9OmfZ7gOtDgtKzvDAeAc2E58ppgEno8UtZg0cJiJCG7vIx99VUsI7w77vU= X-Received: by 2002:a05:6102:956:b0:4a4:97d1:aea0 with SMTP id ada2fe7eead31-4a5d6a92561mr8012407137.11.1729460982351; Sun, 20 Oct 2024 14:49:42 -0700 (PDT) In-Reply-To: <6cadfc93-3fc5-4fcf-b0a6-f54774c36f43@wz.ht> Received-SPF: pass client-ip=2607:f8b0:4864:20::e2c; envelope-from=shipmints@gmail.com; helo=mail-vs1-xe2c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:324693 Archived-At: --000000000000818ef60624ef8342 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If you're on a Mac, which I'm guessing, and, if by chance you are using this build https://emacsformacosx.com/, I highly suggest that you try this one instead https://github.com/jimeh/emacs-builds/releases/tag/Emacs-29.4. It is much, much faster and exhibits correct behavior with code that previously misbehaved and has a few patches applied that correct some GUI features (internal-border colors, for example). I've been using the jimeh build successfully for a while now after much frustration of my own this summer. Pretty much all resolved and I have a lot of customizations. On gotcha is that the jimeh build directly packages the gcc support needed for native packages which is great BUT it is missing one component during trampoline bootstrap (jimeh is aware) so start it once from the command line and let it "warm up," and assuming you have gcc somewhere on your path (via homebrew or somewhere else), thereafter it's fine launched from Spotlight or wherever. I noticed the following in what might be your init.el, though not directly performance related, just FYI: ;; Make native compilation silent and prune its cache. (when (native-comp-available-p) (setq native-comp-async-report-warnings-errors 'silent) (setq native-compile-prune-cache t)) ; <-- this is a function not a variable Take some care with your mode-line entries such as display-battery-mode as I believe it will get queried during every mode-line refresh. Also take some care with post-command-hook. Check to see what's on the hook is what you need and nothing more. These get called after every character you type (as Eli explained, they're all implemented via commands, though the main "hot path" commands are in C, as you'd expect). Run M-x list-timers and see if there are any timers running very frequently on short intervals that you didn't expect. I took a quick peek to see if you'd experience issues with some of the caching challenges using project.el, tramp, etc. and nothing jumped out at me. If there were calls to project-current / project-name on your mode-line or tab-bar customizations, those could get in the way. We're all in the same boat and happy to help. I speak for everyone as I've observed the sheer amount of consideration, work, and thoughtful feedback that goes into Emacs as a platform on a continual basis. On Sun, Oct 20, 2024 at 2:48=E2=80=AFPM Jordan Ellis Coppard wrote: > Hello friends, > > > I've been using Emacs as properly as I can for the past year-ish (read: > all-in instead of bailing out constantly) after circling around the edge > of the pool for a few years. > > Overall I think I like it, although I am still less productive than I > would be in say an IDE from JetBrains or Helix (a TUI editor). I'm sure > I can close that gap as I tinker with Emacs more and more. > > One thing that bothers me without fail is how slow, visually, Emacs is. > 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. > > 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`). Often times I can > type faster than the minibuffer input area can handle when filtering > completion candidates e.g. `C-h o`. > > 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. 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. I understand if I provide some input that > I may be asking it to do heavy lifting and that eventually it will get > back to me with the result (that's fine), but blocking everything else > while that happens is frustrating as I have described above. > > 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. > > 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. > > 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 ask as a "please do this for me". > > I'll get involved but if the answer ahead of time is a "no it's never > going to happen even with a completely working patch in future" then I > think it'd best for me to abandon Emacs. I have ADHD and the visual > hitching and lack of responsiveness to input drives me insane. I fear > it's something I'll never be able to get over and in a world of less > configurable vs. visually hitching and slow I would rather take the forme= r. > > I realise this email has been fairly critical so far. I have said all of > this without malice, I just feel it prudent to describe how important > this is (at least to me) by not mincing words. > > 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. > > But as I've said this behaviour (of Emacs) ruins it for me and I don't > think I'll ever be able to get over it so at this juncture I'd rather > help contribute and improve Emacs for myself and others and I hope > that's something this email can be the genesis of. > > > Regards, > Jordan > > --000000000000818ef60624ef8342 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you're on a Mac, which I'm guessing, and, if by chance you ar= e using this build=C2=A0https://ema= csformacosx.com/,=C2=A0I highly suggest that you try this one instead= =C2=A0https://github.com/jimeh/emacs-builds/releases/tag/Emacs-29.4. It = is much, much faster and exhibits correct behavior with code that previousl= y misbehaved and has a few patches applied that=C2=A0correct some GUI featu= res (internal-border colors, for example). I've been using the jimeh bu= ild successfully for a while now after much frustration of my own this summ= er. Pretty much all resolved and I have a lot of customizations. On gotcha = is that the jimeh build directly packages the gcc support needed for native= packages which is great BUT it is missing one component during trampoline = bootstrap (jimeh is aware) so start it once from the command line and let i= t "warm up," and assuming you have gcc somewhere on your path (vi= a homebrew or somewhere else), thereafter it's fine launched from Spotl= ight or wherever.

I noticed the following in what might be your init.el, though not dire= ctly performance related, just FYI:

;; Make native compilation silent and prune its cach= e.
(when (native-comp-available-p)
=C2=A0 (setq native-comp-async-rep= ort-warnings-errors 'silent)
=C2=A0 (setq native-compile-prune-cache= t)) ; <-- this is a function not a variable

Take some care with your mode-line entri= es such as display-battery-mode as I believe it will get queried during eve= ry mode-line refresh.

Also take some care with post-command-hook. Check to see what'= s on the hook is what you need and nothing more. These get called after=C2= =A0every character you type (as Eli explained, they're all implemented = via commands, though the main "hot=C2=A0path" commands are in C, = as you'd expect). Run M-x list-timers and see if there are any timers r= unning very frequently on short intervals that you didn't expect.
=

I took a quick pee= k to see if you'd experience issues with some of the caching challenges= using project.el, tramp, etc. and nothing jumped out at me. If there were = calls to project-current / project-name on your mode-line or tab-bar custom= izations, those could get in the way.

We're all in the same boat and happy to help= . I speak for everyone as I've observed the sheer amount of considerati= on, work, and thoughtful feedback that goes into Emacs as a platform on a c= ontinual basis.

On Sun, Oct 20, 2024 at 2:48=E2=80=AFPM Jordan Ellis C= oppard <jc+o.emacs@wz.ht> w= rote:
Hello frie= nds,


I've been using Emacs as properly as I can for the past year-ish (read:=
all-in instead of bailing out constantly) after circling around the edge of the pool for a few years.

Overall I think I like it, although I am still less productive than I
would be in say an IDE from JetBrains or Helix (a TUI editor). I'm sure=
I can close that gap as I tinker with Emacs more and more.

One thing that bothers me without fail is how slow, visually, Emacs is. 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.

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`). Often times I can type faster than the minibuffer input area can handle when filtering
completion candidates e.g. `C-h o`.

I don't want my editor (or whatever specific title you'd like to ap= ply)
to EVER not immediately respond to input unless it's crashed. 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. I understand if I provide some input tha= t
I may be asking it to do heavy lifting and that eventually it will get
back to me with the result (that's fine), but blocking everything else =
while that happens is frustrating as I have described above.

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.

I also recently read this post:
https://gist.github.com/ghosty141/= c93f21d6cd476417d4a9814eb71dd46e=C2=A0 --
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.

So I ask: is it possible that Emacs' GUI be decoupled from the lisp cor= e
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 ask as a "please do this for me".

I'll get involved but if the answer ahead of time is a "no it'= s never
going to happen even with a completely working patch in future" then I=
think it'd best for me to abandon Emacs. I have ADHD and the visual hitching and lack of responsiveness to input drives me insane. I fear
it's something I'll never be able to get over and in a world of les= s
configurable vs. visually hitching and slow I would rather take the former.=

I realise this email has been fairly critical so far. I have said all of this without malice, I just feel it prudent to describe how important
this is (at least to me) by not mincing words.

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.

But as I've said this behaviour (of Emacs) ruins it for me and I don= 9;t
think I'll ever be able to get over it so at this juncture I'd rath= er
help contribute and improve Emacs for myself and others and I hope
that's something this email can be the genesis of.


Regards,
Jordan

--000000000000818ef60624ef8342--