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

Version 7 FIND problems

Expand Messages
  • joy8388608
    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
    Message 1 of 16 , Apr 4 10:06 AM
    View Source
    • 0 Attachment
      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
    • John Shotsky
      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
      Message 2 of 16 , Apr 4 10:16 AM
      View Source
      • 0 Attachment
        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]
      • 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 3 of 16 , Apr 4 10:59 AM
        View Source
        • 0 Attachment
          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 4 of 16 , Apr 4 11:04 AM
          View Source
          • 0 Attachment
            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 5 of 16 , Apr 4 11:09 AM
            View Source
            • 0 Attachment
              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 6 of 16 , Apr 4 1:45 PM
              View Source
              • 0 Attachment
                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 7 of 16 , Apr 4 2:17 PM
                View Source
                • 0 Attachment
                  --- 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 8 of 16 , Apr 4 6:03 PM
                  View Source
                  • 0 Attachment
                    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 9 of 16 , Apr 4 7:58 PM
                    View Source
                    • 0 Attachment
                      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 10 of 16 , Apr 4 8:20 PM
                      View Source
                      • 0 Attachment
                        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 11 of 16 , Apr 4 10:49 PM
                        View Source
                        • 0 Attachment
                          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 12 of 16 , Apr 5 5:09 AM
                          View Source
                          • 0 Attachment
                            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 13 of 16 , Apr 5 9:04 AM
                            View Source
                            • 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)

                              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 14 of 16 , Apr 10 6:20 PM
                              View Source
                              • 0 Attachment
                                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 15 of 16 , Apr 10 6:26 PM
                                View Source
                                • 0 Attachment
                                  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 16 of 16 , Apr 16 3:27 AM
                                  View Source
                                  • 0 Attachment
                                    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.