From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Thu, 21 Sep 2023 13:36:34 +0300 Message-ID: <44e98df7-f683-ac07-e644-40757f1d26f9@gutov.dev> References: <83ttrreeu0.fsf@gnu.org> <87bkdzeas1.fsf@localhost> <83cyyfe5l8.fsf@gnu.org> <87led2o0nb.fsf@localhost> <83ttrqcpfb.fsf@gnu.org> <877comnv4a.fsf@localhost> <83fs3ackrq.fsf@gnu.org> <99e84ae7-b3aa-a009-5cb8-a75826343196@gutov.dev> <838r92cgxp.fsf@gnu.org> <837comcam8.fsf@gnu.org> <6946e6f0-c6ef-186c-35d4-c09935c05a07@gutov.dev> <83y1h1axtq.fsf@gnu.org> <87sf79rq5o.fsf@yahoo.com> <83fs38c2yv.fsf@gnu.org> <83o7hw9ee1.fsf@gnu.org> <87il84q845.fsf@yahoo.com> <83il849bx6.fsf@gnu.org> <87a5tfri8c.fsf@yahoo.com> <878r8z27cs.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40850"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: Eli Zaretskii , acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org To: Ihor Radchenko , Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 21 15:12:12 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 1qjJTV-000AKP-MB for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Sep 2023 15:12:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjJSv-0005KH-9d; Thu, 21 Sep 2023 09:11:34 -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 1qjJSO-00057h-HS for emacs-devel@gnu.org; Thu, 21 Sep 2023 09:11:01 -0400 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjJSK-0006qA-LH; Thu, 21 Sep 2023 09:10:59 -0400 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 87D455C0283; Thu, 21 Sep 2023 06:36:38 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 21 Sep 2023 06:36:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1695292598; x=1695378998; bh=pD1sBaMPiRE3L+pgJ563VbqtzRsVnvtGjy0 tPeUykoc=; b=ib5LHUY87vUD/IQMdheEMaRkgkv3b57PU/xm2yXPqihw2xi0Jgl Ei58sNDuSCR8eepRyHgC0XsQO7rV7RsXiFYc+5Dg2JBD3PMYBIENoVd5/k2LGQVP 8wvR+mdx2l9Nv+/KlYk0xDFW5mxZ5TpjzRVcCIUhNeQUimzJw8kj0o0C3GAWwBAH T42ZeuQI4nyhhwQkyClkCXR9leYhPvIRqqZO2wQ3nxm5WkXmcjMK9qg52TbtTeWu 9Op6BWcFlhGO71A+Dt9hHKhwG1afIpyGs1cO8HmEpiuVIBlxaGSP4fIEbL1Gs30k dRoGbRkYndVULtLUPf7LFVZCUrh9ulUKDjA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1695292598; x=1695378998; bh=pD1sBaMPiRE3L+pgJ563VbqtzRsVnvtGjy0 tPeUykoc=; b=GIwHRrNXTx8Ux08st0SErDoO3qbK0LEVc07Qs6upDTpkynU7MOZ CAGoZ1cI2ryjf2iQg/wLqfDmhQ9qAVCLptbLwXR6sX/c6HsgH6z2sXBxIZ6Q9COB rxfP/dinqAuHpPvPfY0Oq9kIjFXDys1fABmqdRRG5b17+8LYQsjT8+V3q9liAfOH IexfDYqz+0aOFJam+hGO3XwD4wafccG6VaExA5PXA6IcqNu1VMnAlGMHNb3oJ5iY zFQNPuJ0MEsJBKpfs4iZS7jA2f9wLAg1+CofjEYMJRNcgqs7Fp6ABs57iX46Cr6T kR3d1MvAVx1uRjsjXqJKIcJgoLDz4e8qlZA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekiedgvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 21 Sep 2023 06:36:36 -0400 (EDT) Content-Language: en-US In-Reply-To: <878r8z27cs.fsf@localhost> Received-SPF: pass client-ip=66.111.4.25; envelope-from=dmitry@gutov.dev; helo=out1-smtp.messagingengine.com X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 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, NICE_REPLY_A=-1.473, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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:310896 Archived-At: On 21/09/2023 12:39, Ihor Radchenko wrote: > Po Lu writes: > >>> Then try leaning on C-n or C-p_after_ everything is already >>> fontified. You will still see that Emacs sometimes cannot keep up, >>> especially if lines are not too short. >> Long lines are, at worst, infrequently encountered in source code, >> aren't they? And our troubles with long lines are an algorithmic >> impediment, which cannot be ameliorated merely by redisplaying each >> window on a different CPU. > I think that there is at least one way to address long lines using > asynchronous redisplay - put a placeholder on the problematic line and > continue calculating the actual rendering in the background instead. > That will not force us to compromise between rendering time and > accuracy, as we do now, with long-line-threshold. Until you're laid out the long line, you don't know which screen line it will finish at, or at which height specifically (it might have images, or taller text due to faces, etc). So you can't render the remainder of the buffer either. > Similar approach might be used to render mode lines - render a > placeholder until it is fully calculated, keeping Emacs responsive. I hope by "placeholder" you mean the previous rendered image of it. But then the mode-line won't be refreshed at 60fps still, which some said is a good goal? (I tentatively agree).