Hey Randy,
On Saturday, April 5, 2008 @ 5:45 PM Randy Kramer wrote:
Anyway, back to the point--I guess there could be about one order of
magnitude difference in the size of expected folds depending on the
use--I guess that could influence the back end design for folding.
I am strong believer in not introducing arbitrary limits for no
good reason. So, it would be my opinion that there should be no
limit to the amount of text folded that isn't also a limit by
virtue of NEdit's basic infrastructure. I do not know how the
buffers are stored, but even if they were stored as strings, and
you used a simple list of pairs telling you what to fold and
what not to fold, there should be no reason for any limits. Just
as an example, even if the text of the file was larger than
could be carried in a single text buffer indexed by a long long,
and you had to use two buffers for that, it still shouldn't
matter, because at least, you ought to be able to specify a
start point for the folder in the first buffer, and then
potentially go across to the whole end of the other buffer if
you wanted to do so.
Just my thoughts, ignorant and independent of the actual
architecture of NEdit underneath the hood.
--
Aaron Hsu <[EMAIL PROTECTED]> | Jabber: [EMAIL PROTECTED]
``Government is the great fiction through which everybody
endeavors to
live at the expense of everybody else.'' - Frederic Bastiat
--
NEdit Develop mailing list - [email protected]
http://www.nedit.org/mailman/listinfo/develop
