This is indeed an issue with the text system (trying to pre-heat the inserted text range for various text checking tasks). Please file a bug.
> 4. As a workaround, could you use underscore characters instead of hyphens? I > tried using en dash and got the same result as hyphens. > > 5. May I suggest that it might not be meaningful to present 70 thousand > characters, comprising only ACTG and -, in one scrolling text view? Mightn't > you present only a snippet at a time, rather than the entire sequence? Just a > thought. These suggestions should be able to help implementing workarounds for the issue. Thanks !! Aki On 2010/07/13, at 16:34, Ross Carter wrote: > I don't think it has anything to do with wrapping. AFAICT, layout is complete > before the delay begins. I think this is a bug that you need to report. Maybe > Doug or Aki can chime in with a solution. > > Here are some things that I found: > > 1. The problem is indeed the hyphen characters. Replace all the - with + or _ > and everything works fine. > > 2. The NSTypesetter method -endParagraph, and the NSLayoutManager delegate > method textContainer:didCompleteLayout:.... both fire quickly, as they > should. That's why I think layout is already over by the time the delay kicks > in. I don't know why -insertText: causes a call to -doubleClickAtIndex: after > the insertion is complete, or why doubleClickAtIndex: takes so long to run. > If you in fact double-click anywhere in the document, it runs instantly. > > 3. My app, Pagehand, handles the test file just fine. I've heavily subclassed > all the components of the text system and I cannot tell what is fixing the > problem. > > 4. As a workaround, could you use underscore characters instead of hyphens? I > tried using en dash and got the same result as hyphens. > > 5. May I suggest that it might not be meaningful to present 70 thousand > characters, comprising only ACTG and -, in one scrolling text view? Mightn't > you present only a snippet at a time, rather than the entire sequence? Just a > thought. > > Hope this helps. > > -Ross > > On Jul 13, 2010, at 3:24 PM, David Swofford wrote: > >> On Jul 13, 2010, at 2:38 PM, Ross Carter wrote: >> >>> Could you post a test file somewhere? I just tried creating 187 pages of >>> repeating ACCGACTACCGACT in TextEdit and it worked fine. >> >> >> Ah... I see a difference, and it's very relevant. My example has a lot of >> hyphen characters in it (FWIW these represent gaps in a sequence alignment >> and are typically common in these kinds of files). Your example was all >> letters. When I substitute all of the gaps in my example to letters, >> TextEdit no longer has this slowdown. It never occurred to me that this >> would matter. >> >> I'm guessing that it has something to do with line/word wrapping, and will >> explore further. >> >> Dave >> >> >> On Jul 13, 2010, at 2:38 PM, Ross Carter wrote: >> >>> On Jul 12, 2010, at 6:01 PM, David Swofford wrote: >>> >>>> I'm beginning the conversion of a scientific app from Carbon to Cocoa, and >>>> have run into a problem with NSTextView. FWIW, I have it embedded in an >>>> NSScrollView that is in turn included as an HICocoaView in a Carbon window >>>> (but I don't think this is relevant to my problem). It works, but I've >>>> run into a glitch that I can't figure out how to solve. In some cases, I >>>> need to be able to edit files containing DNA sequences that look like this: >>>> >>>> sequence-name-1 ACCGACTACCGACT... >>>> sequence-name-2 GACCACTGACCACT... >>>> >>>> The number of characters in the sequences may run into the tens of >>>> thousands, with no spaces or other word breaks. >>>> >>>> If a file like this is opened in TextEdit (or my program, or Smultron, or >>>> TeXShop, or apparently any other NSTextView-based editor with the >>>> exception of SubEthaEdit) and I try to insert a non-space character into >>>> the middle of the DNA sequence, a painfully long pause (e.g., 30 sec) >>>> ensues (with a spinning cursor) before the character appears on the screen >>>> and the app becomes responsive again. Inserting the character into >>>> sequence name or the intervening whitespace works normally, as does >>>> inserting a space character. >>>> >>>> Spin Control indicates that all of this time is being spent in >>>> doubleClickAtIndex (called from NSTextView >>>> insertText:replacementRange:_markTextEditedForRange). I can't figure out >>>> why the typing of a character causes doubleClickAtIndex to be called, but >>>> I wouldn't care if I could just get my editor to stop going AWOL. It does >>>> seem like typing a character triggers some kind of word-boundary >>>> recalculation that is horribly expensive if the "word" is thousands of >>>> characters long. >>>> >>>> I've tried every NSTextView setting I can think of, and that's when I >>>> started looking at other editors to see if they had the same problem as I >>>> was having, and they did (except for SubEthaEdit). >>>> >>>> Is there anything obvious that I might be doing wrong? The fact that the >>>> same problem happens in TextEdit as well as several other editors suggests >>>> that it's a general problem, but the observation that SubEthaEdit >>>> *doesn't* have this problem indicates that there is something I could do >>>> to fix it--I just don't know what. >>>> >>>> Any ideas? I'm really frustrated by this. >>> >>> Could you post a test file somewhere? I just tried creating 187 pages of >>> repeating ACCGACTACCGACT in TextEdit and it worked fine. >>> >> >> -- >> David L. Swofford david.swoff...@duke.edu >> >> Center for Evolutionary Genomics >> Institute for Genome Sciences & Policy >> Box 90338 >> Duke University >> Durham, NC 27708 USA >> >> National Evolutionary Synthesis Center (NESCent) >> Suite A200 >> 2024 W. Main Street >> Durham, NC 27705 USA >> >> (919)613-7458 (Duke) >> (919)668-4591 (Nescent) >> >> > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/aki%40apple.com > > This email sent to a...@apple.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
