From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture (was: Shrinking the C core) Date: Thu, 14 Sep 2023 12:30:27 -0400 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37430"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 14 18:31:37 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 1qgpFg-0009Vw-Ie for ged-emacs-devel@m.gmane-mx.org; Thu, 14 Sep 2023 18:31:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgpEr-0007mJ-36; Thu, 14 Sep 2023 12:30:45 -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 1qgpEp-0007lK-BH for emacs-devel@gnu.org; Thu, 14 Sep 2023 12:30:43 -0400 Original-Received: from mail-pj1-x102e.google.com ([2607:f8b0:4864:20::102e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qgpEn-0008AG-KC; Thu, 14 Sep 2023 12:30:43 -0400 Original-Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-2745916f864so961932a91.3; Thu, 14 Sep 2023 09:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694709039; x=1695313839; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=j9HA7Tjfzun0Wu3uTMjb2+jU21lEjcqZAJb6MUgjWLU=; b=KQ9of/R6npNVDTI9wy9cQuZYKdXmmjy6qH2EdX5SFdq9ojU8rceMRXrMMI7+xUsHqj 0nkuZWIKjqhPp8uq3RaMvH02NydnzAKJCQFtq1vX6fpRvjJEf8vmbZ6+ox/MFyLpBWTP n+w/OQFF7+0T48voCoD2eBjBqifOdOCKKvUgcG1SNn+o045+xFBzA2TpOWdXRqc9Dyfc uDDEITY1yupj21PqjHSesmtTvTLGQTrhYHasoWHMxyxh2eRuXIrliPGMZ9cdWb7AfD1R dy9a4rtkilpyDDL3N7NnbIs5W/2Fxh3+DWy7PXbkPvHVeL/yJdZhb3wLX9HogCWYJgFM 96wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694709039; x=1695313839; h=content-transfer-encoding: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=j9HA7Tjfzun0Wu3uTMjb2+jU21lEjcqZAJb6MUgjWLU=; b=XmRymJxJAkz+EtepchHWrnOQbriSCjyOIzNx+P+moqr0VgVeROToMhQX/Da8xC7BZH evI8viBgB0DGKtngMWBukagsLmuvRcvMwvTI0x+deFDychg75IBvr1coM+cCisvOwKCd rWGVSgJE9JOguOTNWvlL+5TxPDTdOrRGPuOkYJMOiSHBXif8UoWPB2FCyR0HRVjLPI1l MUCVK1k1Dd+HgCG+/ZujXK0MMTxfQseXCOKAUfOg7Z7EhcgxO4C1KwITqEUcuz/tuEFR u92vZh+zWAV16718UHd1mBUQcEiygd1V8biv6w8aB9Q77Wy7z1PpBQMaSuB1h9yXeUzj hNvg== X-Gm-Message-State: AOJu0YxL3K6TTAxRbaKNlVbxRtEt4u1AjbaznC0uWGSfZ0FMTg9j3Qo0 nNDQUubv6AkAKI/SMO8gZqNA+vBB0mxS3ZLOFvYHrEV3 X-Google-Smtp-Source: AGHT+IEXHpJlvMc4F1tavCNBqBwnwMiGbVZJX4xvK/0IJVt+PYcRqRfe5c5mlDDvoMsfgB8PUYE9wy8N5V5eFL8OiNA= X-Received: by 2002:a17:90b:495:b0:263:1f1c:ef4d with SMTP id bh21-20020a17090b049500b002631f1cef4dmr5487184pjb.10.1694709039070; Thu, 14 Sep 2023 09:30:39 -0700 (PDT) In-Reply-To: <838r99mh40.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::102e; envelope-from=owinebar@gmail.com; helo=mail-pj1-x102e.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, 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:310582 Archived-At: On Thu, Sep 14, 2023 at 1:58=E2=80=AFAM Eli Zaretskii wrote: > > From: Lynn Winebarger > > Date: Wed, 13 Sep 2023 16:52:15 -0400 > > Cc: rms@gnu.org, emacs-devel@gnu.org > > > > I think I was more interested in why you said it would be a > > "text-processing system" rather than an editor or even IDE > > Emacs is more than an editor and an IDE. Gnus (and other MUAs we have > in Emacs) is neither, and neither is Org or ERC or any number of other > Emacs features. That makes sense. The term "text-processing system" just evoked something non-interactive to me, like sed, awk, tex, etc. > > > > . display engine design around the rectangular canvas model and > > > I don't know what the alternative is, exactly. > > Finding that out is part of the job. It's quite likely (I hope) that > the relevant technology already exists, and we don't need to invent > it. > > > VS Code and other IDEs I've used have more varied decorative > > elements and containers, but text is still pretty much presented in > > rectangular containers with sides parallel to the GUI window (frame > > in Emacs terms). > > 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. 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. But I have no idea how far you would want to go in replicating GUI functions in the emacs graphics display. It's just not my area. I'll go out on a limb and say that to be interesting, the additional flexibility in the canvas would have to be programmable from emacs lisp, and that would require emacs lisp to be much faster than it is now, and essentially parallelizable in a way that it is not now? Those are things I can work on, though they are not short term projects. Lynn