Loading ...
Sorry, an error occurred while loading the content.

22576RE: [Clip] Version 7 FIND problems

Expand Messages
  • John Shotsky
    Apr 10, 2012
      Very cool. I will put this to the test. Thanks!

      RecipeTools Web Site: <http://recipetools.gotdns.com/> http://recipetools.gotdns.com/

      From: ntb-clips@yahoogroups.com [mailto:ntb-clips@yahoogroups.com] On Behalf Of diodeom
      Sent: Tuesday, April 10, 2012 18:21
      To: ntb-clips@yahoogroups.com
      Subject: Re: [Clip] Version 7 FIND problems

      John wrote:
      > 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.

      Here's a simple (and rather unpolished) clip that aims to provide "Find Previous" functionality for just such occasions.
      It assumes that the Find and Replace dialog window is active and the most recent match is selected in the doc, though it
      should also work right after F&R is closed (by relaying on the pattern history). A likely caveat to some might be the
      prerequisite that the option "Find Word at Cursor" has to be unchecked (@ View/Options/Tools).

      ;Note: Slower systems may require increased delays between ^!Keyboard entries
      ;Bring focus back to Find and Replace dialog
      ^!Menu Search/Replace
      ;Capture the search pattern (into clipboard)
      ^!Keyboard Alt+G &100 Ctrl+C
      ;Return focus to the active document and hide actions
      ^!SetScreenUpdate 0
      ;Select all text above the beginning of selection
      ^!Select 0
      ^!SelectTo 1:1
      ;Locate the last match within selection
      ^!Find "(?s)(^$GetClipboard$)(?!.+(?1))" HRS
      ;Move cursor one (or more) lines above*
      ^!Jump -1
      ;Reactivate the Find and Replace dialog, invoke Find Next
      ^!Keyboard Ctrl+R &100 Alt+F

      */ Prior to jumping the cursor up a line (or more) the command ^!Find has already located the targeted previous match,
      but the end objective is to return it as a result of the actual F&R dialog's search. Whenever the search pattern
      contains a look-behind or the capture-resetting \K (as is often the case for me), F&R would fail to deliver the right
      match if it were to start at the highlighted location. For this reason the cursor is preemptively moved up some
      arbitrary (suitable for one's prevalent patterns) distance.

      I'd also note that if multiple matches occur in the same or the preceding line, the result will be merely approximate;
      however, please keep in mind that this clip is meant to aid in backtracking matches that are spread too far apart in
      voluminous docs for the convenient manual cursor repositioning by a lucky guess, that is, it makes little sense to
      employ it for match-dense texts.


      [Non-text portions of this message have been removed]
    • Show all 16 messages in this topic