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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
