Re: as the accident occued... long lines in emacs buffers.

[David Kastrup <dak@gnu.org>]

David Kastrup <dak@gnu.org> writes:

> Alin Soare <as1789@gmail.com> 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 ‘C source code’.
Its value is t

  Automatically becomes buffer-local when set.

Documentation:
Non-nil means that Emacs should use caches in attempt to speedup buffer scans.

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 ‘move-to-column’ and
‘compute-motion’) also work by scanning the buffer, summing character
widths as they go.  This works well for ordinary text, but if the
buffer’s 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 ‘cache-long-scans’ is non-nil, these motion functions cache 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 ‘cache-long-scans’ 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 ‘cache-long-scans’ is non-nil,
results of these scans are cached.  This doesn’t 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]

-- 
David Kastrup