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

Re: [Clip] Version 7 FIND problems

Expand Messages
  • 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 1 of 16 , Apr 4, 2012
    • 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 2 of 16 , Apr 4, 2012
      • 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 3 of 16 , Apr 4, 2012
        • 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 4 of 16 , Apr 4, 2012
          • 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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.