From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: line buffer as Red Black Trees instead of linear Date: Thu, 15 May 2014 23:06:54 +0300 Message-ID: <83mwein6w1.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1400184442 14267 80.91.229.3 (15 May 2014 20:07:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 May 2014 20:07:22 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alin Soare Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 15 22:07:14 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wl1vt-0002IC-RR for ged-emacs-devel@m.gmane.org; Thu, 15 May 2014 22:07:13 +0200 Original-Received: from localhost ([::1]:60272 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wl1vt-0005Hs-5G for ged-emacs-devel@m.gmane.org; Thu, 15 May 2014 16:07:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39868) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wl1vj-0005Db-Ov for emacs-devel@gnu.org; Thu, 15 May 2014 16:07:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wl1vc-0002OY-A1 for emacs-devel@gnu.org; Thu, 15 May 2014 16:07:03 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:35959) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wl1vc-0002OA-2i for emacs-devel@gnu.org; Thu, 15 May 2014 16:06:56 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0N5M00D00SRDNA00@mtaout29.012.net.il> for emacs-devel@gnu.org; Thu, 15 May 2014 23:07:48 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N5M00AFUT90X850@mtaout29.012.net.il>; Thu, 15 May 2014 23:07:48 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.185 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:171863 Archived-At: > Date: Thu, 15 May 2014 22:47:27 +0300 > From: Alin Soare > > > > The major improvement would be the redisplay. > > > > Actually, no. Redisplay scans the buffer linearly, so it would > > be unaffected. > > > > > I did not check recently which operations are called by redisplay, in order > to see exactly where redisplay and other operations get stuck. But emacs > works terrible with long lines. > > Emacs works bad with buffers with long lines. This would work well, and all > the others atomic operations, like random access, search, will preserve the > current speed. You cannot help redisplay with long lines by giving it random access to buffer text. Long lines slow down redisplay because it needs to scan the entire line to see how tall it will be on display. For that, you must scan the line in its entirety, since Emacs supports variable-size fonts and images on the same line, so determining the height of a line requires to find the largest display element (character glyph or image) displayed on that line. How can random access to buffer text help here?