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: Gap buffer problem? Date: Wed, 11 Dec 2024 22:26:18 +0200 Message-ID: <867c862cgl.fsf@gnu.org> References: <87ttbal9qx.fsf@protonmail.com> <877c86l1aj.fsf@protonmail.com> <86o71i2m2e.fsf@gnu.org> <87v7vqjexy.fsf@protonmail.com> <86cyhy2g97.fsf@gnu.org> <87ldwmj8sw.fsf@protonmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8960"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org, ofv@wanadoo.es To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 11 21:27:22 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 1tLTIn-00029Z-UU for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Dec 2024 21:27:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLTIC-0004ag-N5; Wed, 11 Dec 2024 15:26:44 -0500 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 1tLTIB-0004aE-1x for emacs-devel@gnu.org; Wed, 11 Dec 2024 15:26:43 -0500 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 1tLTIA-0005HI-2a; Wed, 11 Dec 2024 15:26:42 -0500 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=tkKDaBmyNFUxz6C40cm6kPzfrXbih7FBJAekNOX2WlQ=; b=MIM+0BQMtoZZ X+mbFRMonzC1rcEtjp1Wgnae+NDWOdx28oIN3nyC6MgZ5J1Y/dm7JSNCgOK8bYGVqflOA0/Aq6vl7 FGsAL3xBJbW6sBQk0AXZTbcmTB484r5+4hnGFEwGUxm4Te3Lek7V+h/Xg1tirP8Nx89SB6FY/nTpC 2R5ltcqtR5u/o0ZTH/rTHXF3N8y450dba87L14YItg4PwzO5rSdm27IoOruIq1BnCjflhBpNYGyE2 M/F6dc9Z6W7J2lkbh/gJFXRs7TBdh5h4hYXQwQ+fGj1Fz9MQ7rbCr1VsJe1grICj7j8wblzkEDhRR 5yb4E6Tj80wOxVwjTi3wQg==; In-Reply-To: <87ldwmj8sw.fsf@protonmail.com> (message from Pip Cet on Wed, 11 Dec 2024 19:54:07 +0000) 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:326382 Archived-At: > Date: Wed, 11 Dec 2024 19:54:07 +0000 > From: Pip Cet > Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org, ofv@wanadoo.es > > "Eli Zaretskii" writes: > > > Anyway, the fact that redisplay calls Lisp and Lisp calls back into > > redisplay all but kills this idea. Gerd's document has also other > > gotchas. We didn't just give up easily back when we discussed that. > > I don't see why the redisplay process would not be able to call Lisp; > it's a full Emacs process (with a single thread) So you are going to fork on each redisplay? And how will you pass back the results of Lisp evaluation, if the other process meanwhile changes the global state (as it's running concurrently)? > except it doesn't have > an FD or socket for the window system, and has an extra pipe to > communicate with the parent process instead. Do you have an estimation of the throughput that such a pipe will need to handle in order to support GUI display? What will you send through the pipe? If you send only some kind of commands, then the other process will need to generate the font glyphs in some way -- the same glyphs that the "redisplay" process already produced. And if you intend to send the pixels, that would be too much traffic, I think. And again, the global state of the receiving process could have changed, which means any high-level data might be useless (e.g., using a font that was unloaded). > It's true that the side effects of the called Lisp code won't be visible > to the next redisplay process, but such side effects are perilous > anyway, and avoiding them would seem to me to be a feature, not a bug. In Emacs, they are a feature, and are expected to work. You'd be surprised to see how many packages and user code rely on that. > But, to be perfectly honest, I'm not sure redisplay is slowing me down > the way traditional GC is. It's the other way around: the Lisp machine blocks user interaction, including the UI and display.