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 design and architecture (was: Shrinking the C core) Date: Fri, 15 Sep 2023 08:50:08 +0300 Message-ID: <83a5tokmsv.fsf@gnu.org> References: <877cpfybhf.fsf@yahoo.com> <873503y66i.fsf@yahoo.com> <87fs3ur9u8.fsf@dataswamp.org> <875y4moiiq.fsf@dataswamp.org> <83r0n4rj78.fsf@gnu.org> <83cyynpmvd.fsf@gnu.org> <838r99mh40.fsf@gnu.org> <83h6nwlmt4.fsf@gnu.org> <456d12ac-ecf4-3de4-56bb-a2440580777f@gutov.dev> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9524"; mail-complaints-to="usenet@ciao.gmane.io" Cc: owinebar@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 15 07:51:43 2023 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 1qh1jy-0002E6-39 for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Sep 2023 07:51:42 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qh1j6-0000Yq-9I; Fri, 15 Sep 2023 01:50:48 -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 1qh1j4-0000YY-1j for emacs-devel@gnu.org; Fri, 15 Sep 2023 01:50:46 -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 1qh1j3-0006M5-PW; Fri, 15 Sep 2023 01:50:45 -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=5ovi113xs8vMpNH264jU1GB9ntzjJ3v4M/L3rCNS0f4=; b=IXevRk6G39qp eZKOk17v/DW2sSvsXvLmiS8mGb3pnwu9mJm180fCWHmviChUY3f78e/XvF/ivKN6Hud8ckJE0iU3Z y5OP+bEScR+Qybyd7cGL7zlotGqIxwhWif4WQkfp2qdV3D5VdlzyrRR7V6Y928QQo06zTM6PpQvm+ Y+bWhWiS1zhd23MAMn6OiraJQjjagbb1o8BEegyMKhCcGYtZNS4GzSSH9UlXm1lknOOEJ/r1vfZIa ulqIgDxaAstecXup4ArY7OrC49TWqyp82c0HjALTK2ypeold/n/XbNapD419GKHxaVSEDK4yilH+u yi1Z+iBwjiP1H2/OqdiBOA==; In-Reply-To: <456d12ac-ecf4-3de4-56bb-a2440580777f@gutov.dev> (message from Dmitry Gutov on Fri, 15 Sep 2023 00:35:12 +0300) 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:310589 Archived-At: > Date: Fri, 15 Sep 2023 00:35:12 +0300 > Cc: rms@gnu.org, emacs-devel@gnu.org > From: Dmitry Gutov > > On 14/09/2023 19:52, Eli Zaretskii wrote: > >> For the other, it sounds like you'd like to have more GUI primitive > >> type operations available on the canvas directly, without having to > >> use explicit GUI objects like child frames. > > We cannot draw on the canvas directly without making the display > > engine aware of what we are drawing and where, because the display > > engine is responsible for updating the display when something changes. > > So what we need is to be able to place a glyph using arbitrary 3D > > coordinates (the 3rd coordinate for overlaying stuff on top of what's > > already displayed), instead of having to work with rows of glyphs. > > > > Again, studying what others do in this area would be useful, I think. > > Perhaps the classic case is the Mozilla browser, which has from the > beginning implemented its browser UI (chrome) using an HTML-like > technology called XUL which also uses CSS and JavaScript for styling > (colors, size, alignment, positioning) and scripting. Except XUL > provided access to the platform widgets, graphical elements, menus, > dialogs, etc. Still, it's like a web page for displaying web pages, in a > sense. > > Not sure how relevant that is for Emacs: doing a wrapper for an OS > toolkit is a lot of work. One of the important aspects to keep in mind in this regard is that Emacs must give Lisp programs dynamic control of how stuff is displayed, and should be able to exercise that control at high frequency (a trivial example: pulse.el). So I'm not sure CSS is the right means for this job to begin with, although it perhaps could take care of rarely-changing defaults. Another thing to keep in mind is that there should be an efficient way of telling the display back-end which portions of a window to redraw given some changes in the text and display-related data structures. (Of course, if the display back-end is so efficient that it can redisplay everything fast enough, even if displaying across a network on a different terminal, this aspect might be a non-issue.)