The NoteTab Clips List is a Public Group with 2007 members.

Primary Navigation

22554Re: Version 7 FIND problems

Expand Messages

diodeom

Apr 5, 2012

0 Attachment

John wrote:

>
> The problem could be partly resolved by having a 'previous' choice rather than an 'up' choice. The problem happens when
> you blow by the point you are looking for, and once you've passed it, you are screwed. You can only go full cycle after
> that. I've done it more than once at one time, trust me. But if it stored the matches, you could back up through
> previous matches and thus find previous matches. Just like 'undo' only simply backing up through previous matches. That
> would be just as useful, and relieve frustration for those that work with larger documents.
>

Yay to that.

If in my trigger-happy rush I happen to blow past the find that's worthy of (re)consideration, I place my cursor some lines above (how high depends on a perceived density of finds in a given doc) and usually get back to the desired spot within a few invocations of Find Next. In that I'm reliant on the "short-term memory allocation region" in my ever-shrinking brain, where the last few contexts of found selections (or any temporarily needed snippets of data) are continuously rotated.

An arguably more civilized (though hardly elegant) method forgoes the Find and Replace dialog in favor of a clip that prompts for search/replace patterns (if not already hard-coded and pulled in sequence from a list), places unique tokens (to be cleared on exit) in the document and keeps track of them. Everything is handled by a wizard with choices like Find Next, Replace with [THIS], Replace with [THAT], etc., Find Previous, Edit Selection, Edit Extended Selection, Google Selection, and so forth.

But I readily admit that hitting Ctrl+R is my primary and preferred route, mainly because the convenience of freely jumping between the modeless dialog and documents is obviously lacking in the modal wizard approach.

- - -

BTW, to handle specifically via Find and Replace hundreds of collected (mostly trouble-sniffing) patterns that have to be processed "by eye" (the ones that cannot be safely automated in my workflow), I currently use the following:

1. Custom ini file that holds the patterns (plus a clip to append any new ones)
2. Clip that:
-- looks in the target doc for a single match per each search pattern from ini
-- collects ini section numbers of successful patterns (forming thus a small array of integers)
-- invokes AutoIt script passing section references collected in the previous step
3. AutoIt script that:
-- invokes NoteTab's Find and Replace dialog
-- populates it with ini values from a given (iterated) section (from the same ini file)
-- invokes Find Next (to display the first match)
[at this point my dialog decision-making or/and other editing starts & goes on until I close F&R]
-- waits until the F&R dialog is closed
-- calls a tiny NT clip that restores the cursor at the doc's top
-- starts the cycle over with the next set of values (until all are processed)

It's a workable solution for me, but it mostly agitates my appetite for a dedicated app with dialog controls placed in a pane parallel to editor's (maybe horizontally), displaying description/purpose of a current pattern, number of matches left to go, number of patterns remaining ahead, various replacement choices (including backward search), collected replacement statistics, etc., maybe with another little pane for jotting down ideas, pattern improvements and whatnot. To avoid reinventing the wheel, I briefly tested a few of "completely script-able" editors (leaning heavily towards Lua ones), but found no happiness. (And to roll out my own, I'm yet to justify any anticipated time & effort commitment in the context of perceived-as-modest productivity gains.)