nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] aggressive C color highlighting


From: Alexey Toptygin
Subject: Re: [Nano-devel] aggressive C color highlighting
Date: Fri, 4 Aug 2006 01:44:16 +0000 (UTC)

On Thu, 3 Aug 2006, David Lawrence Ramsey wrote:

1) Apply all expressions to the current character pointer and
increment to the end of the match or to the next character when there
is no match. This method is quite simple and will give a significant
speed boost.

2) Use the same technique as in the first method but store all matches
in a list and colorize the text using the list. The list must be
rebuilt each time the file is modified. This method uses more memory
to store the list but gives a huge speed increase when only viewing a
file and no loss in speed compared to the first method.

I'm a bit nervous about method 2, as one of the limitations of the
current code is that responsiveness is a lot lower when modifying a
heavily colorized file, and from your description, it sounds as though
it'd make things worse.  Or am I misunderstanding something, since I'm
not exactly a guru when it comes to the color code?

2 should be faster than 1 even when editing, but slower than no coloring. If you can search the list quickly by line number, you only need to re-apply regexes to the text starting at the end of the last matched area that was entirely before the edited area, and ending at the end of the first matched area that is both a) entirely after the edited area and b) identical before and after the edit.

For most edits, this means only 1-2 matched areas need to be updated in the list. The same quick list search can be used to get the matched areas that need to be highlighted on the screen about to be drawn. Finally, you can choose not to populate the list for areas after the one under edit.

The only thing that is still slow is starting to edit at the end of a long file - you need to scan linearly from the start or you're not guaranteed to get the propper matches. If this ever gets really terrible, we can give it a timeout, and then ask the user whether to continue or abort, like less does when counting line numbers.

                        Alexey




reply via email to

[Prev in Thread] Current Thread [Next in Thread]