NISUS Archives

June 2011

NISUS@LISTSERV.DARTMOUTH.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Thu, 2 Jun 2011 19:19:49 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (113 lines)
Dear Nis-Listers,

Now that the dust has settled from the Nisus Writer Pro 2 release,  
and there seem to be few complaints, I contemplate the upgrade  
options, and have a few questions:

I scanned through the update list, and did not see mention of change  
or resolution for two items of interest to me, and I expect/hope  
others as well.

- Have either of these problems been changed in the upgrade to v2?
- Do any of you find these problems annoying?
- How would you feel about petitioning Nisus to implement user  
options to be Cocoa-compliant vs Individualistic?
- Or do you have any other ideas for resolution?

And to any programmers out there, if Nisus is not willing to provide  
user options, might it be possible to manually alter a plist, or a  
byte or two in a resource of the App to resolve the behavior? (major  
'caveat emptor', of course) Would Nisus be likely to divulge which  
bytes?  Or how trivial would it be to discover which bytes?
_________________________

1- 	Cocoa find string mutual sharing:

I'm not able to get NWP to share the system find string as other  
Cocoa apps do, so I can cmd-E a selection in NWP and switch  
back&forth between to Mail, TextEdit, Safari, etc. with the find  
string being shared and updated by all equally.  Martin at Nisus  
indicated the isolation was to prevent a carefully crafted find  
string from being trashed.  That certainly is understandable, and  
provision should indeed be in place to protect that condition. But  
there is a "recent" find string menu, which it would seem adequate  
protection in most cases.  One thing it would not do, however, is for  
hypothetical usage patterns where one simply does not want the find  
string of other apps to mess with the Nisus string.  This latter item  
would seem to me the strongest reason for discrete user option to be  
'Cocoa compliant' vs 'Individualistic'.

I discovered accidentally, that Safari has a non-intrusive variation,  
which works well with its alternative to a find dialog (the little  
panel that opens under the title-bar).  If and when that find panel  
is open, which is quite prominent or noticeable, Safari does not  
accept the find string to be altered by other apps.  But once it is  
closed, it resumes normal Cocoa mutual sharing.  I like this  
behavior, now that I am aware.

Though Nisus find interface is not so simple, could this, or some  
variant, be beneficial for NWP, or would a discrete user option be  
better?  I would be pleased with either one, just so long as I could  
have achieve mutual sharing with NWP.

NW classic used to have ability to activate a macro at "switch in".   
Would something on this order be possible in NWP?
_________________________

2- 	Triple-click selection: sentence vs paragraph

NWP introduced multi-click selection of sentences, which I applaud.   
But I detest the way it was implemented in NWP 1.3 — usurping 3  
clicks for sentence and moving paragraph selection to 4 clicks.  This  
interferes terribly with my work habits, because it clashes with  
standard Cocoa app behavior.  Shame on Apple for not including  
sentence selection built into Cocoa.  But given that, I must side  
with pushing sentence selection to 4 clicks within Nisus, leaving  
triple click consistent for all Cocoa apps.


Would there be any way to assign a macro to mouse clicks?  Or put a  
regular menu item in a contextual menu?  These two items would be far  
more relevant BEFORE the triple-click was usurped, but in the spirit  
of brain-storming, I offer them anyhow... perhaps they would spark  
some creative solution...

Thanks for all your help,
	Ben Andrus

__________________________________________________

REFERENCE 	to help decipher triple-click behaviour anomalies, lest  
any be confused as I was for a time:

	a)	create three paragraphs with at least two sentences each, and  
then separate them with an option return (new line in same  
paragraph-- what the heck term can we use now that we have so many  
churned up options?) I think "soft return" is not free-- since word  
processors put those in to wrap the lines, correct?

	b)	try the various quantities of clicks at end of document and to  
the right of the return & option-return:

With NWP v1.3, I get the following responses— triple-clicks are  
inconsistent between situations, and no line ends at end of document  
introduces its own irregularities:

Option-return:
	1- caret set to precede the option-return.
	2- selects the option-return
	3- selects the sentence FOLLOWING the option-return
	4- selects the paragraph
	
Return:
	1- caret set to precede the return.
	2- selects the return
	3- selects nothing (same as #1— sets caret before return)
	4- selects the paragraph, including the return

Document end:
	1- caret set to end of line/document.
	2- selects preceding (final) word (or punctuation char)
	3- selects preceding sentence.
	4- selects the paragraph, which has no return.
__________________________________________________

ATOM RSS1 RSS2