Re: [Bug-zile] Zile Lua: Gary, please feel free to look after the branch for now

[Reuben Thomas]

On 9 August 2011 14:11, Brian Maher <address@hidden> wrote:
>
> In many respects, I think the Achilles heel of GNU emacs is the fact
> that it can't deal with excessively long lines or largish files.  I
> believe both of these issues are because of the chosen data-
> structure.

That's partly true. The chosen data structure is the split buffer
(effectively two strings), which is what C Zile now uses. C Zile is
very fast to load long files, whereas Emacs is not; the reason is that
Emacs recodes the files it loads, whereas Zile doesn't.

As to long lines, Zile does not cope gracefully with those, but it
doesn't seem to matter on a typical binary file (which contains enough
\n bytes to avoid really long lines). On a specially constructed file
(say, megabytes without any \n bytes) it would suffer badly.

Neither of these really has much to do with using ropes rather than
storing the buffer as a long string. Splitting the buffer string into
2 at point reduces the amount of copying needed on insertion or
deletion by amortizing it. Since in an interactive editor you're
mainly editing at point, using ropes is not a big win over this much
simpler data structure.

However, if you want to solve the performance problems mentioned above
(and considering that for sophisticated treatment of character
encodings, a standard internal encoding is arguably the way to go),
then using ropes allows you to process input files lazily (as Tatham's
code does).

-- 
http://rrt.sc3d.org