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

RE: [Clip] Version 7 FIND problems

Expand Messages
  • 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 1 of 16 , Apr 4, 2012
    • 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 2 of 16 , Apr 4, 2012
      • 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 3 of 16 , Apr 5, 2012
        • 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 4 of 16 , 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)

            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 5 of 16 , Apr 10, 2012
            • 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 6 of 16 , Apr 10, 2012
              • 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 7 of 16 , Apr 16, 2012
                • 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.