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

Re: [Clip] Version 7 FIND problems

Expand Messages
  • joy8388608
    Yes, I do have regex selected. Even though it doesn t matter, you didn t say if it worked for you the way I had it. Putting additional spaces in didn t fix
    Message 1 of 16 , Apr 4, 2012
      Yes, I do have regex selected.
      Even though it doesn't matter, you didn't say if it worked for you the way I had it. Putting additional spaces in didn't fix anything for me.

      That IS odd there is a find UP for REPLACE but not for FIND.

      If it helps you, placing a backwards searching hyperlink at the end of your text will do a FIND up.

      For example, placing [ mov^B ] at the end of the doc and double clicking it will find the last 'mov' in the doc.

      I just tried it and it works, but highlights just the 'ov' which is probably another bug. And SOMETIMES, all the text from the end up to the string is highlighted and sometimes ONLY the search string is highlighted. But THAT was also happening in Ver 6.

      Joy




      --- In ntb-clips@yahoogroups.com, "John Shotsky" <jshotsky@...> wrote:
      >
      > I put 4 spaces in front of your lines, and it all worked properly for me. Did you have regex selected?
      >
      > Also, I keep hoping for a find 'up' in addition to down and all. If you happen to go past the thing you're looking for,
      > in a 200 kb file, you have to either start over, or select 'all' and hope it restarts at the top, which it does not
      > always do in the released version. We need to be able to search up, often we just want to see if the same thing exists
      > are an earlier point in the file without having to start at the beginning, every time.
      >
      > Regards,
      > John
      > RecipeTools Web Site: <http://recipetools.gotdns.com/> http://recipetools.gotdns.com/
      >
      > From: ntb-clips@yahoogroups.com [mailto:ntb-clips@yahoogroups.com] On Behalf Of joy8388608
      > Sent: Wednesday, April 04, 2012 10:07
      > To: ntb-clips@yahoogroups.com
      > Subject: [Clip] Version 7 FIND problems
      >
      >
      > I left some posts in the BASIC group documenting some problems with Ver 7 but have not had any replies so I hope they
      > have been noted.
      >
      > I just found a problem with FIND in ver 7 pre-release 2 that I hope someone will verify. If I don't start getting some
      > answers or verification of problems I find, I will have to go back to Ver 6 and let someone else do the testing.
      >
      > I want to match all the spaces at the start of each line. When I do a FIND on the following data for ^\x20+, it matches
      > from the second space up to and including the 'a'. Find Next matches from the third space up to and including the 'a'.
      > After a few more tries, it matches just the 'a'. The next find matches the '1' of '100'.
      >
      > a 100
      > mov ax,0040
      > mov ds,ax
      > or byte ptr [0017],40
      > mov ah,1
      > int 16
      > mov ax,4c00
      > int 21
      >
      > Please tell me it's not something stupid I'm doing.
      >
      > Joy
      >
      >
      >
      > [Non-text portions of this message have been removed]
      >
    • John Shotsky
      Your sample didn t have any spaces at the beginning of the lines, so it shouldn t find anything. On my computer, it finds nothing using your search string when
      Message 2 of 16 , Apr 4, 2012
        Your sample didn't have any spaces at the beginning of the lines, so it shouldn't find anything. On my computer, it
        finds nothing using your search string when I remove the spaces. The caret says to look at the beginning of the line,
        and if there are no spaces, it won't look further inside the line.

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

        From: ntb-clips@yahoogroups.com [mailto:ntb-clips@yahoogroups.com] On Behalf Of joy8388608
        Sent: Wednesday, April 04, 2012 11:00
        To: ntb-clips@yahoogroups.com
        Subject: Re: [Clip] Version 7 FIND problems


        Yes, I do have regex selected.
        Even though it doesn't matter, you didn't say if it worked for you the way I had it. Putting additional spaces in didn't
        fix anything for me.

        That IS odd there is a find UP for REPLACE but not for FIND.

        If it helps you, placing a backwards searching hyperlink at the end of your text will do a FIND up.

        For example, placing [ mov^B ] at the end of the doc and double clicking it will find the last 'mov' in the doc.

        I just tried it and it works, but highlights just the 'ov' which is probably another bug. And SOMETIMES, all the text
        from the end up to the string is highlighted and sometimes ONLY the search string is highlighted. But THAT was also
        happening in Ver 6.

        Joy

        --- In ntb-clips@yahoogroups.com <mailto:ntb-clips%40yahoogroups.com> , "John Shotsky" <jshotsky@...> wrote:
        >
        > I put 4 spaces in front of your lines, and it all worked properly for me. Did you have regex selected?
        >
        > Also, I keep hoping for a find 'up' in addition to down and all. If you happen to go past the thing you're looking
        for,
        > in a 200 kb file, you have to either start over, or select 'all' and hope it restarts at the top, which it does not
        > always do in the released version. We need to be able to search up, often we just want to see if the same thing exists
        > are an earlier point in the file without having to start at the beginning, every time.
        >
        > Regards,
        > John
        > RecipeTools Web Site: <http://recipetools.gotdns.com/> http://recipetools.gotdns.com/
        >
        > From: ntb-clips@yahoogroups.com <mailto:ntb-clips%40yahoogroups.com> [mailto:ntb-clips@yahoogroups.com
        <mailto:ntb-clips%40yahoogroups.com> ] On Behalf Of joy8388608
        > Sent: Wednesday, April 04, 2012 10:07
        > To: ntb-clips@yahoogroups.com <mailto:ntb-clips%40yahoogroups.com>
        > Subject: [Clip] Version 7 FIND problems
        >
        >
        > I left some posts in the BASIC group documenting some problems with Ver 7 but have not had any replies so I hope they
        > have been noted.
        >
        > I just found a problem with FIND in ver 7 pre-release 2 that I hope someone will verify. If I don't start getting some
        > answers or verification of problems I find, I will have to go back to Ver 6 and let someone else do the testing.
        >
        > I want to match all the spaces at the start of each line. When I do a FIND on the following data for ^\x20+, it
        matches
        > from the second space up to and including the 'a'. Find Next matches from the third space up to and including the 'a'.
        > After a few more tries, it matches just the 'a'. The next find matches the '1' of '100'.
        >
        > a 100
        > mov ax,0040
        > mov ds,ax
        > or byte ptr [0017],40
        > mov ah,1
        > int 16
        > mov ax,4c00
        > int 21
        >
        > Please tell me it's not something stupid I'm doing.
        >
        > Joy
        >
        >
        >
        > [Non-text portions of this message have been removed]
        >



        [Non-text portions of this message have been removed]
      • Don
        I too show no spaces.
        Message 3 of 16 , Apr 4, 2012
          I too show no spaces.

          On 4/4/2012 2:04 PM, John Shotsky wrote:
          > Your sample didn't have any spaces at the beginning of the lines, so it shouldn't find anything. On my computer, it
          > finds nothing using your search string when I remove the spaces. The caret says to look at the beginning of the line,
          > and if there are no spaces, it won't look further inside the line.
          >
          > Regards,
          > John
        • joy8388608
          Drat. I don t know how I pasted lines with 7 spaces in front of each line and they all disappeared in the post. I m pasting them again and they DO have leading
          Message 4 of 16 , Apr 4, 2012
            Drat. I don't know how I pasted lines with 7 spaces in front of each line and they all disappeared in the post. I'm pasting them again and they DO have leading spaces. At least now - before I hit SEND.

            Aside from that, my original post, problem and question stands.

            a 100
            mov ax,0040
            mov ds,ax
            or byte ptr [0017],40
            mov ah,1
            int 16
            Mov ax,4c00
            int 21

            Joy


            --- In ntb-clips@yahoogroups.com, Don <don@...> wrote:
            >
            > I too show no spaces.
            >
            > On 4/4/2012 2:04 PM, John Shotsky wrote:
            > > Your sample didn't have any spaces at the beginning of the lines, so it shouldn't find anything. On my computer, it
            > > finds nothing using your search string when I remove the spaces. The caret says to look at the beginning of the line,
            > > and if there are no spaces, it won't look further inside the line.
            > >
            > > Regards,
            > > John
            >
          • flo.gehrke
            ... The Standard and Wildcard Search allows to search up . With RegEx, it has never been possible to search up or backwards (with B option in a clip).
            Message 5 of 16 , Apr 4, 2012
              --- In ntb-clips@yahoogroups.com, "John Shotsky" <jshotsky@...> wrote:
              >
              > Also, I keep hoping for a find 'up' in addition to down and all.

              The Standard and Wildcard Search allows to search 'up'. With RegEx, it has never been possible to search 'up' or 'backwards' (with 'B' option in a clip). So that's no issue of NT 7.0 but probably due to the way the RegEx Engine works.

              For more details, see the topic '^!Find Command - Reverse Regular Expression Search' that started with message #18159 of Aug 5, 2008.

              Regarding Joy's problem (#22539), I can't reproduce that issue. I get 5 to 6 spaces with her sample text, and '^\x20+' is matching correctly all spaces at the beginning of every line. It never includes any letter or number.

              Flo
            • joy8388608
              How about that. I never noticed you could search UP unless Reg Exp was checked! And the FIND problem I reported went away after I installed NTL V7R3. Those
              Message 6 of 16 , Apr 4, 2012
                How about that. I never noticed you could search UP unless Reg Exp was checked!

                And the FIND problem I reported went away after I installed NTL V7R3.

                Those problems that some people have and others don't are a bear.

                I am STILL seeing the problem that a tab in my browser opens when I double click the last or second to last word in a sentence ending with a period. Can anyone reproduce THAT?

                And double clicking in the middle of a word still selects the word from the click point to the beginning of the word which is how I found the problem above.

                Joy



                --- In ntb-clips@yahoogroups.com, "flo.gehrke" <flo.gehrke@...> wrote:
                >
                > --- In ntb-clips@yahoogroups.com, "John Shotsky" <jshotsky@> wrote:
                > >
                > > Also, I keep hoping for a find 'up' in addition to down and all.
                >
                > The Standard and Wildcard Search allows to search 'up'. With RegEx, it has never been possible to search 'up' or 'backwards' (with 'B' option in a clip). So that's no issue of NT 7.0 but probably due to the way the RegEx Engine works.
                >
                > For more details, see the topic '^!Find Command - Reverse Regular Expression Search' that started with message #18159 of Aug 5, 2008.
                >
                > Regarding Joy's problem (#22539), I can't reproduce that issue. I get 5 to 6 spaces with her sample text, and '^\x20+' is matching correctly all spaces at the beginning of every line. It never includes any letter or number.
                >
                > Flo
                >
              • Don
                Think about it with negative and positive look aheads and behinds and so forth ... there is a specific reason that regex only goes one way :-)
                Message 7 of 16 , Apr 4, 2012
                  Think about it with negative and positive look aheads and behinds and so
                  forth ... there is a specific reason that regex only goes one way :-)

                  On 4/4/2012 9:03 PM, joy8388608 wrote:
                  > How about that. I never noticed you could search UP unless Reg Exp was checked!
                • John Shotsky
                  You re right, I wasn t thinking of it in terms of backwards searching using regex . I almost always have regex checked, as I almost always AM using regex to
                  Message 8 of 16 , Apr 4, 2012
                    You're right, I wasn't thinking of it in terms of backwards searching 'using regex'. I almost always have regex checked,
                    as I almost always AM using regex to identify the search. I guess I thought it would convert it to a text search
                    automatically, and search backwards. I will try to uncheck regex box to search upwards in the future, but I suspect that
                    will be unrewarding, as it will require ONLY a literal, which isn't always possible, or useful. At least, now I
                    understand the issue.

                    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.

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

                    From: ntb-clips@yahoogroups.com [mailto:ntb-clips@yahoogroups.com] On Behalf Of flo.gehrke
                    Sent: Wednesday, April 04, 2012 14:18
                    To: ntb-clips@yahoogroups.com
                    Subject: Re: [Clip] Version 7 FIND problems


                    --- In ntb-clips@yahoogroups.com <mailto:ntb-clips%40yahoogroups.com> , "John Shotsky" <jshotsky@...> wrote:
                    >
                    > Also, I keep hoping for a find 'up' in addition to down and all.

                    The Standard and Wildcard Search allows to search 'up'. With RegEx, it has never been possible to search 'up' or
                    'backwards' (with 'B' option in a clip). So that's no issue of NT 7.0 but probably due to the way the RegEx Engine
                    works.

                    For more details, see the topic '^!Find Command - Reverse Regular Expression Search' that started with message #18159 of
                    Aug 5, 2008.

                    Regarding Joy's problem (#22539), I can't reproduce that issue. I get 5 to 6 spaces with her sample text, and '^\x20+'
                    is matching correctly all spaces at the beginning of every line. It never includes any letter or number.

                    Flo



                    [Non-text portions of this message have been removed]
                  • Art Kocsis
                    Ii never noticed the search direction option change with RegX either but that is just the way RegX doesn t work. In NTB7#2 I do not have your problems with
                    Message 9 of 16 , Apr 4, 2012
                      Ii never noticed the search direction option change with RegX either but
                      that is just the way RegX doesn't work.

                      In NTB7#2 I do not have your problems with double clicking words (WinXP).

                      I suppose having a wild card search option may be useful but my first
                      reaction is the new GUI will be a PIA. It requires two clicks instead of
                      just one and the RegX option is hidden until one clicks on the select box.
                      I would much prefer having two always visible check boxes in a slightly
                      larger window than being forced to double the click load. I would even
                      rather have the previous GUI and forego a wild card option.

                      What would be really useful however, would be a way to easily delete a Find
                      or Replace history entry. Often I have made a typo or have multiple entries
                      in debugging a RegX pattern and the history gets long and cluttered. A
                      simple right click and delete on a highlighted entry would be a big
                      improvement. Another possible method would be to press the delete key on a
                      highlighted entry. This is the method used by Firefox to delete form
                      history entries. Or for max convenience, implement both methods.

                      Namaste', Art

                      At 4/4/2012 06:03 PM, Joy wrote:
                      >How about that. I never noticed you could search UP unless Reg Exp was
                      >checked!
                      >Those problems that some people have and others don't are a bear.
                      >
                      >I am STILL seeing the problem that a tab in my browser opens when I double
                      >click the last or second to last word in a sentence ending with a period.
                      >Can anyone reproduce THAT?
                      >
                      >And double clicking in the middle of a word still selects the word from
                      >the click point to the beginning of the word which is how I found the
                      >problem above.
                    • Don
                      I usually always click in a blank part of the regex find so it jumps to the top and I go top down. I m just used to it and I guess my stuff isn t that big
                      Message 10 of 16 , Apr 5, 2012
                        I usually always click in a blank part of the regex find so it jumps to
                        the top and I go top down. I'm just used to it and I guess my stuff
                        isn't "that" big like John's is apparently. It works well for me and I
                        use it hourly.

                        The history can get long as Art suggests and cluttered.

                        What would be really cool Eric is to add a recorder feature for "clip
                        building". Do a search and replace, it is what you want, click on
                        commit and it saves it as a clip step. You could thus do a series of
                        steps and have them all saved as a clip for future use. I do this
                        manually all of the time. I get thirty similar documents. I do a
                        search and replace, it's successful, so I then copy both halves of it to
                        a clip replace and save the clip. Repeat over and over and over until I
                        have the clip. Still efficient in the end, but could get way more
                        efficient.

                        Is it possible to simply write a clip to do this?

                        On 4/5/2012 1:49 AM, Art Kocsis wrote:
                        > Ii never noticed the search direction option change with RegX either but
                        > that is just the way RegX doesn't work.
                        >
                        > In NTB7#2 I do not have your problems with double clicking words (WinXP).
                        >
                        > I suppose having a wild card search option may be useful but my first
                        > reaction is the new GUI will be a PIA. It requires two clicks instead of
                        > just one and the RegX option is hidden until one clicks on the select box.
                        > I would much prefer having two always visible check boxes in a slightly
                        > larger window than being forced to double the click load. I would even
                        > rather have the previous GUI and forego a wild card option.
                        >
                        > What would be really useful however, would be a way to easily delete a Find
                        > or Replace history entry. Often I have made a typo or have multiple entries
                        > in debugging a RegX pattern and the history gets long and cluttered. A
                        > simple right click and delete on a highlighted entry would be a big
                        > improvement. Another possible method would be to press the delete key on a
                        > highlighted entry. This is the method used by Firefox to delete form
                        > history entries. Or for max convenience, implement both methods.
                        >
                        > Namaste', Art
                        >
                        > At 4/4/2012 06:03 PM, Joy wrote:
                        >> How about that. I never noticed you could search UP unless Reg Exp was
                        >> checked!
                        >> Those problems that some people have and others don't are a bear.
                        >>
                        >> I am STILL seeing the problem that a tab in my browser opens when I double
                        >> click the last or second to last word in a sentence ending with a period.
                        >> Can anyone reproduce THAT?
                        >>
                        >> And double clicking in the middle of a word still selects the word from
                        >> the click point to the beginning of the word which is how I found the
                        >> problem above.
                        >
                        >
                        >
                        > ------------------------------------
                        >
                        > Fookes Software: http://www.fookes.com/
                        > NoteTab website: http://www.notetab.com/
                        > NoteTab Discussion Lists: http://www.notetab.com/groups.php
                        >
                        > ***
                        > Yahoo! Groups Links
                        >
                        >
                        >
                        >
                      • diodeom
                        ... 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
                        Message 11 of 16 , Apr 5, 2012
                          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)

                          I suppose my earlier motivation to achieve the same functionality solely within NT waned maybe too quickly. My first clip-only attempt kept track of iterations and populated dialog entries okay, but it required repetitive manual reactivation after each pattern's turn, and, worse yet, it wasn't free off occasional unpredictable and thus unreproducible (for debugging) hiccups. In contrast, AutoIt offered me plenty of glitch-free love right away, so I never looked back.

                          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.)

                          Dio
                        • diodeom
                          ... 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
                          Message 12 of 16 , Apr 10, 2012
                            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
                            ^!FocusDoc
                            ^!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.

                            Dio
                          • John Shotsky
                            Very cool. I will put this to the test. Thanks! Regards, John RecipeTools Web Site: http://recipetools.gotdns.com/ From:
                            Message 13 of 16 , Apr 10, 2012
                              Very cool. I will put this to the test. Thanks!

                              Regards,
                              John
                              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
                              ^!FocusDoc
                              ^!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.

                              Dio



                              [Non-text portions of this message have been removed]
                            • Eric Fookes
                              Hi Don, ... Thanks for your suggestion. I ll add it to the wish list. -- Regards, Eric Fookes http://www.fookes.com/
                              Message 14 of 16 , Apr 16, 2012
                                Hi Don,

                                > What would be really cool Eric is to add a recorder feature for "clip
                                > building". Do a search and replace, it is what you want, click on
                                > commit and it saves it as a clip step. You could thus do a series of
                                > steps and have them all saved as a clip for future use. I do this
                                > manually all of the time.

                                Thanks for your suggestion. I'll add it to the wish list.

                                --
                                Regards,

                                Eric Fookes
                                http://www.fookes.com/
                              Your message has been successfully submitted and would be delivered to recipients shortly.