From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: as the accident occued... long lines in emacs buffers. Date: Fri, 13 Nov 2015 17:40:02 +0100 Message-ID: <87wptln999.fsf@fencepost.gnu.org> References: <87k2q1xsg9.fsf@gmail.com> <1446668449.11811.11.camel@invergo.net> <87mvupvonu.fsf@gmail.com> <1447368233.11811.52.camel@invergo.net> <87wptmyaml.fsf@gmail.com> <1447409234.32571.1.camel@invergo.net> <87si49udez.fsf@gmail.com> <87h9kp7tm3.fsf_-_@gmail.com> <871tbtoo49.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1447433271 24717 80.91.229.3 (13 Nov 2015 16:47:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2015 16:47:51 +0000 (UTC) Cc: John Wiegley , Brandon Invergo , emacs-devel@gnu.org To: Alin Soare Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 13 17:47:49 2015 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 1ZxHVr-0002QO-US for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2015 17:47:48 +0100 Original-Received: from localhost ([::1]:53992 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxHVr-0001Hd-HP for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2015 11:47:47 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49279) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxHVQ-0001Cf-VX for emacs-devel@gnu.org; Fri, 13 Nov 2015 11:47:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxHVQ-0006aC-0z for emacs-devel@gnu.org; Fri, 13 Nov 2015 11:47:20 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58001) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxHVH-0006ZG-Rp; Fri, 13 Nov 2015 11:47:11 -0500 Original-Received: from localhost ([127.0.0.1]:43587 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZxHVH-0006EH-81; Fri, 13 Nov 2015 11:47:11 -0500 Original-Received: by lola (Postfix, from userid 1000) id 20F08DF908; Fri, 13 Nov 2015 17:40:02 +0100 (CET) In-Reply-To: <871tbtoo49.fsf@fencepost.gnu.org> (David Kastrup's message of "Fri, 13 Nov 2015 17:33:42 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:194391 Archived-At: David Kastrup writes: > Alin Soare writes: > >> Hi Emacs Devel. >> >> I have just sent on emacs devel a message that was destinated elsewhere. >> >> Because the accident occurred, I want to remember you that I intend to >> solve the issue of long lines in emacs, by replacing the linear buffer >> with red-black trees that keep the lines. >> >> This will make emacs work incredible fast with long lines. > > I'll settle for "as fast as one would expect given its behavior on short > lines". Though purportedly this should have been somewhat addressed by cache-long-scans is a variable defined in =E2=80=98C source code=E2=80=99. Its value is t Automatically becomes buffer-local when set. Documentation: Non-nil means that Emacs should use caches in attempt to speedup buffer sca= ns. There is no reason to set this to nil except for debugging purposes. Normally, the line-motion functions work by scanning the buffer for newlines. Columnar operations (like =E2=80=98move-to-column=E2=80=99 and =E2=80=98compute-motion=E2=80=99) also work by scanning the buffer, summing= character widths as they go. This works well for ordinary text, but if the buffer=E2=80=99s lines are very long (say, more than 500 characters), these motion functions will take longer to execute. Emacs may also take longer to update the display. If =E2=80=98cache-long-scans=E2=80=99 is non-nil, these motion functions ca= che the results of their scans, and consult the cache to avoid rescanning regions of the buffer until the text is modified. The caches are most beneficial when they prevent the most searching---that is, when the buffer contains long lines and large regions of characters with the same, fixed screen width. When =E2=80=98cache-long-scans=E2=80=99 is non-nil, processing short lines = will become slightly slower (because of the overhead of consulting the cache), and the caches will use memory roughly proportional to the number of newlines and characters whose screen width varies. Bidirectional editing also requires buffer scans to find paragraph separators. If you have large paragraphs or no paragraph separators at all, these scans may be slow. If =E2=80=98cache-long-scans=E2=80=99 is = non-nil, results of these scans are cached. This doesn=E2=80=99t help too much if paragraphs are of the reasonable (few thousands of characters) size. The caches require no explicit maintenance; their accuracy is maintained internally by the Emacs primitives. Enabling or disabling the cache should not affect the behavior of any of the motion functions; it should only affect their performance. [back] --=20 David Kastrup