I seem to be having an extreme version of the problem noted earlier in "optimizing speed?" Namely, Nisus types at a crawl, navigates through the document so slowly that I'm forever jerking a page ahead or a page behind; and Find-Replace is so sluggish that even now, 10min after the fact, the application is still struggling (spinning rainbow wheel of death and all) to replace the one remaining element I need to replace.
I've tried the Disk Verify and Disk Repair approach, and it seemed to improve matters for a bit, but now it seems to be back to its old tricks again. I don't have this problem with any other programs, though a comparable slowing did once occur when I tested out the Code 2000 Unicode font in TextEdit---and subsequently dumped, because it appears that somehow the application is substantially slowed by use of that font, as if it had to look through the whole huge font at all times. This particular bout of slowness seemed in part to be triggered when I put some forms in Lucida Grande (I'm a linguist, and so use a lot of Unicode phonetic characters in papers). Lucida Grande has never had this efffect in TextEdit, however. Any suggestions as to how to get some workable speed back?
Very very slow
and grep is slow, too
Speaking of slow.... I hope some effort is being put into PowerFind(Pro) to speed it up. I have a document with ~1862 lines in it that I simply wanted to delete the one or more spaces at the beginning of a line. Using PowerfindPro (^\s+) on this document took a full minute on a 1 Ghz PowerBook G4. The same command on the same file in BBEdit is instantaneous (yes, I know that BBEdit is a Carbon app). Then in the same file, I tried to replace all instances of a comma followed by zero or more spaces (,\s*) with a tab (\t). After ten minutes, NWE had still not finished and I killed it (the CPU monitor was pegged at 100% for the entire ten minutes). For the same find and replace on the same file, NW Classic took 1 minute 37 seconds and BBedit took 1.5 SECONDS to replace the 18,610 instances of ,\s*
By the way, line/paragraph endings have gotten complex in MacOS X since classic mac used a carriage return whereas, Unix uses a linefeed character. In the above file, which was a MacClassic text format and therefore had carriage returns, I had to replace them with linefeeds before I could search for spaces at the beginning of the line. NWE has no special symbol to represent a classic mac carriage return when you use “Show invisibles” and yet shows the same symbol that the NW Classic used for carriage returns to represent line feeds and refers to them as “returns”. This can lead to a great deal of confusion!
So, we need a special symbol to represent classic carriage returns and it should perhaps somehow be made more explicit that “end of line” in PowerFind will find both linefeeds and carriage returns.
By the way, I found the Find and Replace boxes in the find dialog to be entirely too small for complex PowerFind searches. Since I have Developer Tools installed, I was able to open up the Nisus package and find and launch the appropriate .nib in interface builder to make bigger boxes (usual proviso -- work on a copy, etc.). This is not, however, a good general solution and I would urge Nisus programmers to make the Find/replace dialog resizable.
By the way, line/paragraph endings have gotten complex in MacOS X since classic mac used a carriage return whereas, Unix uses a linefeed character. In the above file, which was a MacClassic text format and therefore had carriage returns, I had to replace them with linefeeds before I could search for spaces at the beginning of the line. NWE has no special symbol to represent a classic mac carriage return when you use “Show invisibles” and yet shows the same symbol that the NW Classic used for carriage returns to represent line feeds and refers to them as “returns”. This can lead to a great deal of confusion!
So, we need a special symbol to represent classic carriage returns and it should perhaps somehow be made more explicit that “end of line” in PowerFind will find both linefeeds and carriage returns.
By the way, I found the Find and Replace boxes in the find dialog to be entirely too small for complex PowerFind searches. Since I have Developer Tools installed, I was able to open up the Nisus package and find and launch the appropriate .nib in interface builder to make bigger boxes (usual proviso -- work on a copy, etc.). This is not, however, a good general solution and I would urge Nisus programmers to make the Find/replace dialog resizable.
Very very slow
My document is presently 16 pages long. Since my initial post, I have found the following possibly associated effects.
(1) NWX starts out reasonably fast, but then noticeably slows down the longer I have the application running.
(2) This is most evident in using Find-Replace functions or the Clipboard (simple; I have yet to even try multiple Clipboards): particularly after making changes involving special fonts (e.g. the Unicode font Lucida Grande), any Find-Replace function (again, on just a small document like this one) results in an endless spinning rainbow wheel of death. The most recent instance involved not a Find-Replace action, however, but simply a Copy to Clipboard action operating over a single page that had multiple fonts (inlcuding one TTF; might this be an issue?).
I notice too that NWX in startup tends to take a noticeably longish time in its "Finding Fonts" phase. This reinforces the idea that whatever is wrong has something to do with fonts, and is possibly related to the problem I had with Code2000 in TextEdit---i.e. as if the Find-Replace and Clipboard functions are s being slowed because they somehow have to wade through the whole of Unicode, or at least the whole of a Unicode font.
At any rate, thank you for your work; I look forward to finding out what the problem (and, hopefully, its solution) is.
Sla/n,
bhur gcara
(1) NWX starts out reasonably fast, but then noticeably slows down the longer I have the application running.
(2) This is most evident in using Find-Replace functions or the Clipboard (simple; I have yet to even try multiple Clipboards): particularly after making changes involving special fonts (e.g. the Unicode font Lucida Grande), any Find-Replace function (again, on just a small document like this one) results in an endless spinning rainbow wheel of death. The most recent instance involved not a Find-Replace action, however, but simply a Copy to Clipboard action operating over a single page that had multiple fonts (inlcuding one TTF; might this be an issue?).
I notice too that NWX in startup tends to take a noticeably longish time in its "Finding Fonts" phase. This reinforces the idea that whatever is wrong has something to do with fonts, and is possibly related to the problem I had with Code2000 in TextEdit---i.e. as if the Find-Replace and Clipboard functions are s being slowed because they somehow have to wade through the whole of Unicode, or at least the whole of a Unicode font.
At any rate, thank you for your work; I look forward to finding out what the problem (and, hopefully, its solution) is.
Sla/n,
bhur gcara
addendum
I neglected to include a present crude patch to the problem: because this slowness problem seems to "accumulate", by frequently saving and then quitting NWX and restarting it, I can restore normal behavior for a while. If I'm not careful and forget to save before I Cut/Paste or use Find-Replace, however, I then end up losing changes, since the only way out is a Force Quit---lest I be mistaken for impatient, I have started my browser, logged in, and composed most of these posts, and usually waited for a goodly while on both sides of that with NWX still churning fruitlessly away, so it seems to be a more substantial problem still than the difference between a few seconds to perform a Find-Replace vs. even a few minutes.
qhua:
Please send us feedback on this issue using the Send Feedback option in the NWE Help menu. When you do this, it includes information about any crashes or other internal problems Nisus Writer might have experienced recently.
I'm not sure how a font could be causing your problem. If it takes a long time during the "Finding Fonts..." phase, that usually means you have a lot of fonts installed. All we do during that part of start up is ask Mac OS X for a list of names of all the fonts you have active; we do not even load the fonts themselves.
Also, even though you are not using it...have you tried disabling this Code font so that it is not even available on your system just to see if that speeds things up? This would not be a permanent fix, but it might help to diagnose the problem.
-Charles
Please send us feedback on this issue using the Send Feedback option in the NWE Help menu. When you do this, it includes information about any crashes or other internal problems Nisus Writer might have experienced recently.
I'm not sure how a font could be causing your problem. If it takes a long time during the "Finding Fonts..." phase, that usually means you have a lot of fonts installed. All we do during that part of start up is ask Mac OS X for a list of names of all the fonts you have active; we do not even load the fonts themselves.
Also, even though you are not using it...have you tried disabling this Code font so that it is not even available on your system just to see if that speeds things up? This would not be a permanent fix, but it might help to diagnose the problem.
-Charles
Charles Jolley
Nisus Software, Inc.
Nisus Software, Inc.
still slow and crashing
Thanks! I will pass this along. I actually have never used Code 2000 with NWX: it being so difficult to use with TextEdit, I deleted it completely from my system months ago, before I even installed NWX. So I don't think it's a problem.
I have however isolated one other factor. The document that I have been haveing so much trouble with has some portions copied and pasted from an old Word 98 document opened in Nisus. Within these are footnotes. I found yesterday if I try to delete the footnote numbers (in the text), I trigger an endless loop of churning rainbow wheel. Nothing else in these copied elements has this effect---as much trial and error testing showed---only the footnote numbers. So perhaps there is some evil invisible formatting from the original Word file that is causing the problem?
Today's crash, however, seemed to come out of nowhere, with none of the factors I've associated with it before.
One question: I did not seem to have any of these problems in the few days when I was testing out NWX in Demo mode. Now that I've bought and registered a license, could this have made a difference?
I have however isolated one other factor. The document that I have been haveing so much trouble with has some portions copied and pasted from an old Word 98 document opened in Nisus. Within these are footnotes. I found yesterday if I try to delete the footnote numbers (in the text), I trigger an endless loop of churning rainbow wheel. Nothing else in these copied elements has this effect---as much trial and error testing showed---only the footnote numbers. So perhaps there is some evil invisible formatting from the original Word file that is causing the problem?
Today's crash, however, seemed to come out of nowhere, with none of the factors I've associated with it before.
One question: I did not seem to have any of these problems in the few days when I was testing out NWX in Demo mode. Now that I've bought and registered a license, could this have made a difference?
-
John Amriding
- Posts: 1
- Joined: 2006-02-27 08:43:38
Just downloaded the demo on my desktop (X.4.5) and laptop (X.3.9). The laptop seems to work O.K. but the desktop??? Hmm...
Can't even get past the startup screen (it seems to have difficulty with the fonts) yet Word, Pages & Text Edit don't seem to have any problems at all.
BTW, just repaired my permissions so I presume that isn't a problem...
Can't even get past the startup screen (it seems to have difficulty with the fonts) yet Word, Pages & Text Edit don't seem to have any problems at all.
BTW, just repaired my permissions so I presume that isn't a problem...