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: Tick Reduction Date: Fri, 19 Nov 2021 20:53:42 +0200 Message-ID: <831r3cugcp.fsf@gnu.org> References: <87bl2hyzca.fsf@gnus.org> <835ysoursn.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34294"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 19 19:54:27 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 1mo91n-0008k7-Iw for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Nov 2021 19:54:27 +0100 Original-Received: from localhost ([::1]:37514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mo91m-0007pi-Ky for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Nov 2021 13:54:26 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:46666) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mo916-0006WR-H5 for emacs-devel@gnu.org; Fri, 19 Nov 2021 13:53:44 -0500 Original-Received: from [2001:470:142:3::e] (port=51086 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 1mo915-0004vk-G9; Fri, 19 Nov 2021 13:53: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=Fta+dMuo1gT0cW8HZjGvbMiHnzqaDsHt5LFRX5zTVB4=; b=e9SguELLuiM+ QLqNkUVtp9esbda6HPzXd6aLi0q+0qzgSdIUx5+zowfY+8P9444rIzwJp9/HUD4FV8EN/qAuLNGT2 2ohLXRFozs/dgIRwm5lrUZdAfjS8F5vDlyyLVf53RToglNPepnJ4XrIfWKY5vMIU4LdURD8fXdMmG 8vtkmUgKiiAlBWsh+rP1fsK1CuKLZjXnCeNPHNDjPlh5ZQVKnqj6fONDIzFRp3XoWFXSzt5gjz6UV qpoVcP0yaMJm7bvWVlAOQwPEk8eTcMqfTyHo7B39iUEBVMW3M4fohAa/RYDFHX4ap45woINCpzxWe PZDtdn+WrHdSGYV5zzb52w==; Original-Received: from [87.69.77.57] (port=4826 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 1mo915-0007TS-5j; Fri, 19 Nov 2021 13:53:43 -0500 In-Reply-To: (message from Stefan Monnier on Fri, 19 Nov 2021 13:22:16 -0500) 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:279770 Archived-At: > From: Stefan Monnier > Cc: larsi@gnus.org, emacs-devel@gnu.org > Date: Fri, 19 Nov 2021 13:22:16 -0500 > > >> Clearly, we would benefit from a formal markup language (and one which > >> includes some way to align text into columns). > > > > AFAIU, markup is generally separate from layout, so aligning text is > > not part of what markup is supposed to solve. > > Not sure what you mean: in order to know that the columns need to be > aligned, the code that does the layout will need to be told about it by > some markup. What I mean is that markup generally tells nothing about layout, and alignment is part of layout. > > it examines text one character at a time and makes layout > > decisions as part of that examination. What you want would AFAIU > > require the display engine perform layout of the entire window above > > the line currently being laid out, before the layout of the current > > line can be performed. > > AFAIK, the way the display engine works currently, when we process > a given char at POS, we have already processed all the chars between > `window-start` and POS That is only true when the window is redisplayed in its entirety, top to bottom. This happens relatively rarely, because the display engine tries very hard not to redisplay much more than absolutely necessary. These redisplay optimizations are generally structure as follows: . find the beginning and the end of the part of the buffer that needs to be redisplayed . redisplay that part starting at its beginning and going to its end This could result in redisplaying just one line, for example, or all lines between N and M. Which means that redisplay of a window can start at some arbitrary point in the middle of the window, without knowing anything about the preceding lines, except that they weren't changed on the glass. Basically any display engine algorithm is required to support a redisplay that begins at an arbitrary point in the buffer, and not rely on the glyph matrices to be up-to-date. > so I think we could handle the case of "align > with some previous line" (with some non-trivial caveats since it means > that future changes in that previous line would need to cause POS to be > re-processed, which may require disabling some optimizations). What you want would require every redisplay to always redraw the entire window. IOW, disable _all_ redisplay optimizations. > Of course, to really auto-align columns, we can't just "align > with some previous line", but we'd also need to align with some > subsequent line, which means it can't be done in a single pass. Ouch!