nisus.com

The Document Manager regularly drives me crazy. Somehow I must have edited--perhaps accidentally--some document on another server. That is I seem to have edited a document on my Powerbook while it was connected to my desktop. As a result every time I run the cursor down the File menu and over the menu items referring to recently opened DM files, Nisus goes into permanent beach ball mode while it desperately tries to locate the non-existant server. Sometimes Nisus doesn't even recover from this and I am forced to shut Nisus down.
Nisus really has to find a more graceful way to fail here. Even without the crash, I find the long wait I get for what is essentially an inadvertent action intolerable.

Hmm...

Well after more experimentation, it seems that the preferences were corrupted, or something. Removing the .plist file completely restored working order, but gave me that "New User" feeling. I tried editing the .plist file removing some document manager related preferences as well as some file addresses that were still pointing at my long-gone iDisk, and now things seem to work again.

One question though: is it really true that deleting the preference file causes Nisus to also overwrite the Nisus New File? (I had to restore the new file from my other computer)

phspaelti wrote: One question though: is it really true that deleting the preference file causes Nisus to also overwrite the Nisus New File? (I had to restore the new file from my other computer)

Deleting the com.nisus.NisusWriter.plist file does not overwrite your customised Nisus New File. Only the location of your customised Nisus New File becomes unknown and therefore the default Nisus New File is used instead when you relaunch the app after deleting the plist file. However, your customised keyboard shortcuts will be lost.
I keep a compressed copy of the com.nisus.NisusWriter.plist in the same folder which can be expanded when needed and which helps to avoid all the trouble.

Hamid is exactly right: the preferences file only stores the location of your Nisus New File, but the template itself (wherever it is stored) should be intact.

As for why deleting your preferences file may have solved your unresponsive document manager problem: OSX stores aliases to recent files in your preferences, which are listed in your document manager. When the document manager (or its menus) are displayed, it asks for file information, which can trigger alias resolution and thus remote server connection delays/timeouts. We're aware of this frustrating issue and plan to make this process better behaved.

Hamid wrote:

phspaelti wrote: One question though: is it really true that deleting the preference file causes Nisus to also overwrite the Nisus New File? (I had to restore the new file from my other computer)

Deleting the com.nisus.NisusWriter.plist file does not overwrite your customised Nisus New File. Only the location of your customised Nisus New File becomes unknown and therefore the default Nisus New File is used instead when you relaunch the app after deleting the plist file.

So what you are saying is that if I had located the Nisus New File in the application support file this would have restored the New File?

I also now realize that I could have used Time Machine to restore the New File.

Hamid wrote:However, your customised keyboard shortcuts will be lost.
I keep a compressed copy of the com.nisus.NisusWriter.plist in the same folder which can be expanded when needed and which helps to avoid all the trouble.

In fact I could have used Time Machine to restore the .plist file as well, so there isn't really any need to keep the compressed file either.
However through this experience I have now learned about the P-list editor which is quite nice, and makes it possible to selectively fix problems (up to a point, I guess).

martin wrote:As for why deleting your preferences file may have solved your unresponsive document manager problem: OSX stores aliases to recent files in your preferences, which are listed in your document manager. When the document manager (or its menus) are displayed, it asks for file information, which can trigger alias resolution and thus remote server connection delays/timeouts. We're aware of this frustrating issue and plan to make this process better behaved.

Thanks Martin. I am really glad to hear that.

In the just released version 2.0.5 update we've done some work to prevent this problem from affecting users. The Document Manager and its associated components are now less aggressive about asking OSX to resolve aliases which might trigger remote server connections.