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: Thu, 14 Sep 2023 19:52:23 +0300 Message-ID: <83h6nwlmt4.fsf@gnu.org> References: <87ledwx7sh.fsf@yahoo.com> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28975"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, emacs-devel@gnu.org To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 14 18:53:15 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 1qgpad-0007L4-CK for ged-emacs-devel@m.gmane-mx.org; Thu, 14 Sep 2023 18:53:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgpaG-0005ui-Ls; Thu, 14 Sep 2023 12:52:52 -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 1qgpaF-0005uT-Rx for emacs-devel@gnu.org; Thu, 14 Sep 2023 12:52:51 -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 1qgpaF-0004UU-Hv; Thu, 14 Sep 2023 12:52:51 -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=dEjTHANLBaJIeVOTwKrWxO7SKEbSokaSQN2TSOcpSqM=; b=aYbcOf7MXquB gUmZTqgzZegctn+MmFO34PDpn6vxnbo/8gfJZ1S7uMIKOUE6xW/1bsKfquddKjm3/f+9O1WNShBz/ o46Qhf13ChL2/+t5lPneP2Pa+vBiYT6RsidhJ1/bzhZFr/Te6jNQ/ZHKqbaWCL5mKUvMs0GaHbr2I QN1Wf3To0RY4dSsw0dv9zwM338qZCg6jZ0pAMzUBcIxx0YzxIcvp8FfNluwOHEfTJxl5K7r5Y8rNO T/j3hdRBN25MwPns24ChIruunu0xBZJozKvnFPEyAIwQgs4HulaViqRfbJP5FGIX2p9n3lU9Idi9U ja8qd3lY9kdaWYD31h95Ow==; In-Reply-To: (message from Lynn Winebarger on Thu, 14 Sep 2023 12:30:27 -0400) 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:310584 Archived-At: > From: Lynn Winebarger > Date: Thu, 14 Sep 2023 12:30:27 -0400 > Cc: rms@gnu.org, emacs-devel@gnu.org > > > You misunderstood what I meant by "rectangular canvas model", I think. > > In Emacs, every screen line is represented as a "glyph row", a linear > > array of glyphs, and the window's display is represented as a liner > > array of glyph rows. This is why we cannot (easily) have an image > > that spans more than one screen line, and why we cannot have display > > elements (like images or text boxes) overlaid on top of buffer text. > > Could this be subdivided into two design issues: > * Decoupling the display (or view?) from the buffer being displayed > * Providing a more flexible canvas > > So under the first would be doing something like interposing objects > representing syntactic entities in between the display and the buffer, > so the user could interact directly with those objects, as opposed to > having those objects attached to text intervals or overlays, and > having the interaction backed into. How is this different from display properties, overlays and images, which we already have? The problem is not to display objects that don't come from buffer text: we already have that. The problem is that our layout engine cannot superimpose one object on top of the other, and the geometry of the layout is hard-coded as "glyph rows". IOW, it's a pure display layout problem, not a problem with decoupling display from buffers. > 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.