From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Request for pointers and advice: displaying several buffers inside a single window Date: Sat, 11 Apr 2020 11:22:17 +0300 Message-ID: <83y2r2l9dy.fsf@gnu.org> References: <83a73swwd7.fsf@gnu.org> <87wo6nxsjz.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="57879"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dim1212k@gmail.com, adam@alphapapa.net, casouri@gmail.com, yantar92@gmail.com, emacs-devel@gnu.org To: chad Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 11 10:23:16 2020 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 1jNBQ3-000Evh-NV for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Apr 2020 10:23:15 +0200 Original-Received: from localhost ([::1]:49828 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNBQ2-0001OK-Np for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Apr 2020 04:23:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35071) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNBPO-0000mJ-7i for emacs-devel@gnu.org; Sat, 11 Apr 2020 04:22:35 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40741) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jNBPN-00047c-PC; Sat, 11 Apr 2020 04:22:33 -0400 Original-Received: from [176.228.60.248] (port=1248 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jNBPM-0004iC-NU; Sat, 11 Apr 2020 04:22:33 -0400 In-Reply-To: (message from chad on Fri, 10 Apr 2020 17:05:00 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:246825 Archived-At: > From: chad > Date: Fri, 10 Apr 2020 17:05:00 -0700 > Cc: Ihor Radchenko , Adam Porter , Yuan Fu , > Eli Zaretskii , emacs-devel > > In particular, the way the found and added caching of line starts seemed like > something that could help emacs' problems with very long lines, and perhaps also the concerns with parsing > large files for highlighting and indenting. I don't think so, because finding the next newline is not the expensive part of the Emacs redisplay when lines are very long. In fact, we look for newlines by calling the memchr library function, and the result is lightning-fast, because Emacs represents buffer text as linear array of bytes, and memchr expands to a small number of machine instructions in an optimized build. With today's fast CPU clocks, searching for the next newline in even a very large buffer is a non-issue. The expensive part of redisplay is finding the correspondence between buffer positions and screen coordinates. Every display update needs some operation which has to find such correspondence. For example, take the simple C-n key, which by default moves to the next visual line. Long lines are normally wrapped on display, so the character below the current one on the next visual line is likely to be some place in the same physical line, but where exactly is that? What Emacs does internally is traverse all the characters after the current one, calculating their metrics and making pixel-level layout decisions, including the line wrapping, until it gets to the character whose screen coordinates indicate it is directly below the current cursor position. Then Emacs puts point at that place. C-p is similar, but more expensive, because moving back requires to start from the beginning of a physical line (which might be far away). C-v and M-v are also similar, because they need to calculate where to put the window-start to display the next screen-full of text with some overlap with what is currently shown. Etc. etc. -- it is this task of finding what buffer position corresponds to certain screen coordinates is what makes redisplay painfully slow when there are very long lines. Emacs before v21 supported only fixed-pitch fonts, where such calculations were much easier, but we nowadays support variables fonts in the same buffer.