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: Future of display engine and lines Date: Wed, 10 Nov 2021 21:24:31 +0200 Message-ID: <83a6ib3jbk.fsf@gnu.org> References: <2108181.AU8Z245p1N@galex-713.eu> <834k952tti.fsf@gnu.org> <2364365.nKfNrZnynm@galex-713.eu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3485"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, rms@gnu.org, galex-713@galex-713.eu, emacs-devel@gnu.org To: chad Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 10 20:25:37 2021 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 1mktE1-0000iP-DQ for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Nov 2021 20:25:37 +0100 Original-Received: from localhost ([::1]:56952 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mktE0-00088v-9x for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Nov 2021 14:25:36 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43232) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mktDA-0007LB-IZ for emacs-devel@gnu.org; Wed, 10 Nov 2021 14:24:48 -0500 Original-Received: from [2001:470:142:3::e] (port=47800 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mktD9-0004oM-Aj; Wed, 10 Nov 2021 14:24:44 -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=cej4WcCoQ1dCqHqPH6XqQ/yKRnWGKVwlb3RrgIvTvwc=; b=PVibVDEOZMF/ xF6UJRcO9S1NnBBhTCbIWnrg9c1nZa/orxLuhSrIV8tqMooLtfLpuTWf5MzjuVxF6gwJZ3KKV8iQV pYYA3EGn3L9dB7GzchfmdNLRTUwHRK5/DyKz1dMFHeemB00BnuTAmmuZ1ho2za23SSQXSzAWolYdh ebghIijO0X3KZv/Leqhpsa8F60KAOdaQCyc6X1nIOAkCSKjc/sc/OMMaoE3GAQC48IWzMg+sm2QWB F/awyPOHHTkAA5QbSBxlEWTrdNupRgemxLIEdN1BCORUAgXoKMtDJwfaeuz11WBE8hAIJStUvvrZX USIbro8Z9KFKvi94TE9Y8A==; Original-Received: from [87.69.77.57] (port=1334 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mktD1-0004KR-Ma; Wed, 10 Nov 2021 14:24:36 -0500 In-Reply-To: (message from chad on Tue, 9 Nov 2021 15:13:28 -0800) 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" Xref: news.gmane.io gmane.emacs.devel:279196 Archived-At: > From: chad > Date: Tue, 9 Nov 2021 15:13:28 -0800 > Cc: Richard Stallman , Eli Zaretskii , Lars Ingebrigtsen , > EMACS development team > > The question is not to have multiple gaps (although that would actually be > useful for some extensions like multiple-cursors (which btw is pretty nice > and emacs is the only editor to support that)), > > I think I might misunderstand you, because, if I recall correctly, Emacs' multiple-cursor support is a port of > the concept from Atom, which borrowed it from Sublime Text. In any case, at this point multiple-cursor > support (perhaps under varying names) exists in several commonly used editors, including gedit and > vscode. In any case, I don't think multiple-cursors have necessarily anything to do with the way we store and process buffer text. It's a display feature, not necessarily a text-editing feature. > In principle there might be a more efficient representation of > buffers. But I am skeptical about that. When I tried to look for a > better representation that would allow for multiple gaps, I couldn't > see a good answer about how to use them and gain any benefits. > > It's been a few years since I last looked at this, but if anyone is {seriously,academically} interested in > changing Emacs' underlying buffer representation, I recommend looking closely at ropes: > > https://en.wikipedia.org/wiki/Rope_(data_structure) > > I've been away from these academic circles for a while now, so it's possible that this recommendation is out > of date; I would love to see (a pointer to) an update if anyone has such a thing. I think if we ever seriously consider changing the representation of buffer text, we should consider first what will benefit faster display operations, not the efficiency of insertions and deletions. Because without well-known display problems, we won't have a good enough reason to change the buffer text representation in the first place. And it must be a very good reason, because the job of changing that representation is not a trivial one.