RE: Syntax Coloring...
RE: Syntax Coloring...
- Subject: RE: Syntax Coloring...
- From: "Josh Ferguson" <email@hidden>
- Date: Mon, 10 Jun 2002 11:27:07 -0500
- Thread-topic: Syntax Coloring...
Charles,
I really appreciate your input on this. I do make use of the textDidChange delegate for some other things in my program. The reason I'm using textView:shouldChangeTextInRange:replacementString (whew that's a mouthful) is because it already has a NSRange that I can use. Is using the -editedRange method any more efficient? I suppose it would be if it meant I only needed to use textDidChange:. As far as not using an incremental approach, the main problem is speed here. I don't know if I'm doing something wrong, but to get the coloring to work properly, I first have to reset everything to black, then run through and recolor everything. Just setting a large set of text (we'll say somewhere around 5,000 lines of code) to black causes a noticeable delay (I use [textView setTextColor:forRange:], should I not be using this?). When you do this every time a key is pressed, then it gets REALLY slow as you get towards the bottom of the document. I'm always going to have a dynamic dictionary of "tokens" (like int, float, etc.), and rather than searching through the text for each of these tokens, I would think it would be much faster to determine the last word that was typed, then search the dictionary of tokens for that word. The exact problems I run into right now are:
If you have a line with only a "//" comment, then delete the entire line and begin typing again, then line will retain the comment coloring. This is why I reset everything to being black before running through my coloring again. I'm sure there's a more efficient way of doing this, but it wouldn't be a concern if I use a smaller section of text.
If you have a multiple line comment using "/**/", then you have to search through a larger block of text to find the location of the "/*" and "*/". This is why I'm doing the incremental approach. If I didn't have to color "/**/", it wouldn't even be a problem! ARGH!
After thinking it a bit more, I think I agree that finding the text range in the scroll view is not going to be the answer here. I just haven't decided what right answer is going to be. I prefer a simple, black and white, algorithmic approach, and I don't think I'm going to get that here =(.
-----Original Message-----
From: Charles Jolley [
mailto:email@hidden]
Sent: Monday, June 10, 2002 11:09 AM
To: Josh Ferguson
Cc: email@hidden
Subject: Re: Syntax Coloring...
Josh:
If you are using a network of text view objects, let me suggest a couple
of different changes to your approach you might want to consider:
1. Consider using the textDidChange: delegate method and finding the
edited range using textStorage's -editedRange method. This may be a bad
way of doing it though, I would invite anyone else with some thoughts to
chime in.
2. Rather than try to develop an incremental approach based on text
entered, etc. it is probably simpler just to search the text for the
markers and set the relevant text coloring attributes or temporary
attributes. (You are using text color attributes to do this coloring,
right?) Given how complicated an incremental approach is likely to get,
this simpler approach may still just as fast. Even if it isn't, my
experience has been that the difference in speed will not be great
enough to justify the extra effort.
3. Marking large sections of text with a new color attribute is not a
very expensive operation. The text system in Cocoa is very efficient.
Don't worry about changing color attributes in large sections of text.
Cocoa will at most redisplay only the visible portion.
4. Rather than worrying about the visible range of text, let the layout
manager do that for you. See the -invalidateDisplayForCharacterRange:
method (or something like that). Again, this is very efficient.
Anything you write yourself will basically do the same thing this method
will do.
That being said, here is what you would have to do to find the smallest
range of characters to completely include the visible portion of your
text view:
1. Find the visible portion of your text view(s). (see NSView's
visibleRect method).
2. Convert that rect to the text container rect (probably the same
thing. see NSTextView's textContainerOrigin method)
3. Use NSLayoutManager's -glyphRangeForBoundingRect:inTextContainer:
(see also the "withoutAdditionalLayout" variety)
4. convert the glyphRange to the characterRange. (see NSLayoutManagers
characterRangeForGlyphRange:actualGlyphRange: method.)
Well, that's all I know. Hope it helps a little bit.
-Charles
On Monday, June 10, 2002, at 10:28 AM, Josh Ferguson wrote:
>
Ok, this is probably a pretty basic question, but I've searched through
>
the docs and haven't found an answer. I'm creating a basic text editor
>
that supports syntax coloring (I know, novel idea...). In an effort to
>
keep it running speedy (which is the reason I created it in the first
>
place), I'm trying to keep the range of text that gets colored to a
>
minimum. My problem is with "/**/" comments, as that's the only item
>
that I'm coloring that will span multiple lines (otherwise I would just
>
color one line at a time).
>
>
When the user types any input, I get the location for that input, then
>
search backwards from that location for the nearest "/*", then just run
>
my syntax coloring method from there. I then do a forward search for
>
the first "*/" to determine where to end my coloring. This obviously
>
isn't foolproof, as this doesn't take into consideration the fact that
>
the text they're editing may not be a comment at all, and if the code
>
has very few "/**/" comments, then the range being colored is going to
>
be unnecessarily large. I determine what's being changed by using the
>
textView:shouldChangeTextInRange:replacementString delegate method. If
>
the user is deleting text, is there any way to check what character the
>
user has deleted (that way I could just check to see if the user
>
delete "/" and save myself a big headache)? If not, how do you get the
>
range of text that's being displayed in the Scroll View (that way, I
>
could just make sure that this text is always up to date).
>
>
I'm sorry if this seems stupid, I'm just kind of working from the
>
ground up here, and I'm getting to the point where I think I need a
>
fresh perspective. Feel free to criticize.
>
>
Josh Ferguson
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.