Actually, the only reason I haven't implemented buffer bounds in CCA
EMACS is that they're somewhat low in priority; they are definitely
on my list to be done, though, and their implementation is
straightforward. If they had been designed-in from the start, they
would have been quite trivial to put in. However, I started out with
Montgomery's EMACS and have had to retrofit a lot of stuff. The same
goes for nondrifting marks; this is also a feature which has recently
been installed.
To determine the relative positions of two points may take two
comparisons in a line-oriented editor compared to one in a buffer gap
editor, but in terms of actual peformance this difference is
insignificant. In actual execution, only one comparison is usually
needed anyway. All in all, I am quite happy with the line oriented
approach, and I think it is a major reason why command execution
speed in CCA EMACS is generally quite fast.
Steve Zimmerman
I do agree though that the problem of comparing positions is one of the
major disadvantages of the linked list approach, making all region hacking
more expensive.
Also, a correction: Gosling's emacs uses the buffer+gap scheme.
It seems to me that other ways of implementing buffer bounds
should exist, but since no one has done so, and because I think
bounds are a real feature, I dislike the linked list of lines
approach.
Also, relocating marks efficiently in a buffer gap scheme is
easy. I have code that anyone can look at if they care.
Marks a certainly NOT a reason for linked lists.
Another interesting possibility is a binary-tree of "text" (which
I prefer to lines for the reasons KLH gives). It is possible to
compare buffer positions in log time using such structures.