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

Re: [NTB] Re: Search and Replace broken when string includes carriage return

Expand Messages
  • Eric Fookes
    Hi Sheri, ... Help says the ^L token is not available in the Find/Replace dialogs used for searching documents open in NoteTab Pro. But it is available in the
    Message 1 of 15 , Oct 4, 2007
      Hi Sheri,

      > No conversion of linebreaks is done by the search disk utility.
      > Instead of ^P you'd have to use ^L to represent linebreaks in Unix
      > files. Just tried it and that works in the search disk utility even
      > though the help file says ^L isn't supported in Pro!

      Help says the ^L token is not available in the Find/Replace dialogs used
      for searching documents open in NoteTab Pro. But it is available in the
      Search Disk dialog.

      --
      Regards,

      Eric Fookes
      http://www.fookes.com/
    • Sheri
      ... Hi Eric, Thanks for a great program! It s true the statement about ^C and ^L being unavailable in NoteTab Pro is located on the Find and Replace dialog
      Message 2 of 15 , Oct 4, 2007
        --- In notetab@yahoogroups.com, Eric Fookes <egroups@...> wrote:
        >
        > Hi Sheri,
        >
        > > No conversion of linebreaks is done by the search disk utility.
        > > Instead of ^P you'd have to use ^L to represent linebreaks in
        > > Unix files. Just tried it and that works in the search disk
        > > utility even though the help file says ^L isn't supported in Pro!
        >
        > Help says the ^L token is not available in the Find/Replace
        > dialogs used for searching documents open in NoteTab Pro. But it
        > is available in the Search Disk dialog.

        Hi Eric,

        Thanks for a great program!

        It's true the statement about ^C and ^L being unavailable in NoteTab
        Pro is located on the Find and Replace dialog page and not the Search
        Disk page. But having read both pages, it wasn't clear to me that it
        IS available in Pro when using Search Disk. So when I tried it on a
        Unix file and it worked, I was surprised. :)

        Also I see something cautioning about linebreaks and regex on the
        search disk page, while the same thing could be said about non-regex
        searches. In both cases, it should be mentioned that the selection of
        proper tokens needed for matching and substituting line breaks is
        imperative ONLY when using the Search Disk facility. Maybe NoteTab
        could even be made a little smarter (so it won't preformat the search
        disk search criteria with incorrect tokens based on file type).

        Regards,
        Sheri
      • tuttle.grey
        Since many folks are obviously interested in this issue, and I ve had some off-list contacts, here s my follow-up. Quick summary of issue: When I Search Disk
        Message 3 of 15 , Oct 4, 2007
          Since many folks are obviously interested in this issue, and I've had
          some off-list contacts, here's my follow-up.

          Quick summary of issue:
          When I Search Disk for any string that includes a carriage return,
          NoteTab does not find it. I get: Search text "..." not found in files!

          This occurs even when I highlight a string in a file in that very
          directory and Search Disk for that same string. IOW: I highlight a
          string in a file, Search Disk automatically enters that string in its
          search field, I search in the same directory for files including that
          string, and it finds none. It should find it, because it was selected
          from a file in the directory that is being searched.

          I neglected to add that my default is to save files in Unix format:
          View | Options | Documents | selected Format Save As "UNIX". That's
          because I often create and edit HTML and PHP files for use on a Unix
          server. When I used the default setting (DOS/Windows?) we
          occasionally had problems with whitespace from PHP scripts, so my PHP
          coder advised me to select "Save As UNIX". That's now left as my
          default, even when creating text files for Windows use, so I hope it
          won't create any local issues for me.

          Eric advised:
          that the ^P token expects line breaks to have the CR/LF format. If
          files are saved in the Unix/Linux format, then the line breaks have
          the LF format. However, NoteTab handles documents internally using
          the Windows line-break format. When you open a Unix file in NoteTab,
          it will get converted to the Windows format. On saving changes,
          NoteTab creates the file on disk using the Unix format again. That's
          why selecting a block to auto-enter it in the Search Disk dialop
          doesn't truly match how that block is actually saved in the file.

          Sheri offered a further explanation:
          When NoteTab opens a Unix document it converts all the linebreaks to
          CRLFs (carriage return+linefeed) which is normal for Windows files.
          So ^P would work properly on a Unix document while it is displayed in
          the editor. When it gets saved (as a Unix file) all the CRLFs get
          converted to LFs (the norm for Unix files).

          Sheri further explained:
          No conversion of linebreaks is done by the search disk utility.
          Instead of ^P you'd have to use ^L to represent linebreaks in Unix
          files. Just tried it and that works in the search disk utility even
          though the help file says ^L isn't supported in Pro! You could also
          use regex. In regex, linebreaks are \r\n in PC files and \n in Unix
          files. Or the metacharacter \R will match either one.

          Eric advised: you could use the \R token which will be added ito the
          next version of NoteTab, version 5.5. It will find line breaks,
          whether they are based on the Windows, Linux, or Mac format.

          Sheri added this:
          It's true the statement about ^C and ^L being unavailable in NoteTab
          Pro is located on the Find and Replace dialog page and not the Search
          Disk page. But having read both pages, it wasn't clear to me that it
          IS available in Pro when using Search Disk. So when I tried it on a
          Unix file and it worked, I was surprised. :)

          Sheri also added:
          Also I see something cautioning about linebreaks and regex on the
          search disk page, while the same thing could be said about non-regex
          searches. In both cases, it should be mentioned that the selection of
          proper tokens needed for matching and substituting line breaks is
          imperative ONLY when using the Search Disk facility. Maybe NoteTab
          could even be made a little smarter (so it won't preformat the search
          disk search criteria with incorrect tokens based on file type).


          I agree with Sheri. Allowing the Search Disk field to automatically
          select a block which cannot be found, because it is temporarily
          reformatted when viewing, is non-intuitive. Perhaps the smart folks
          at Fookes could come up with an improved method of searching UNIX
          files. :)
        • Sheri
          ... Hi Tuttle, If you use the ASCII protocol to FTP your HTML and PHP files to the UNIX server, the line ending get converted to the server s format. I learned
          Message 4 of 15 , Oct 4, 2007
            --- In notetab@yahoogroups.com, "tuttle.grey" <tuttle@...> wrote:
            >
            >
            > I neglected to add that my default is to save files in Unix
            > format: View | Options | Documents | selected Format Save As
            > "UNIX". That's because I often create and edit HTML and PHP files
            > for use on a Unix server. When I used the default setting
            > (DOS/Windows?) we occasionally had problems with whitespace from
            > PHP scripts, so my PHP coder advised me to select "Save As UNIX".
            > That's now left as my default, even when creating text files for
            > Windows use, so I hope it won't create any local issues for me.


            Hi Tuttle,

            If you use the ASCII protocol to FTP your HTML and PHP files to the
            UNIX server, the line ending get converted to the server's format. I
            learned that while researching for the Custom FTP clips.

            See here, for example:
            http://webtips.dan.info/misc.html

            or here:
            http://www.websiterepairguy.com/articles/os/crlf.html

            So theoretically you could save everything in NoteTab using the
            "DOS/Windows" format option, and not incur any local issues. Or just
            use "Original" format option as the default. Then when new documents
            are saved in NoteTab they will be saved in DOS/Windows format. If you
            ever happen to edit a UNIX document, it will get saved as a UNIX file.
            You would rarely be editing UNIX documents because if the document
            came from the UNIX server using FTP and the ASCII protocol, your local
            copies would be in DOS/Windows format. And if the document were
            created locally it would also be in DOS/Windows format.

            Regards,
            Sheri
          • Tuttle Grey
            ... Hi Sheri! Thanks for the response. My head is somewhat spinning from all that, but I will reread it and check out those links. Prior to changing NoteTab s
            Message 5 of 15 , Oct 4, 2007
              On Thu, October 4, 2007 10:36 am, Sheri wrote:
              > --- In notetab@yahoogroups.com, "tuttle.grey" <tuttle@...> wrote:
              >>
              >>
              >> I neglected to add that my default is to save files in Unix
              >> format: View | Options | Documents | selected Format Save As
              >> "UNIX". That's because I often create and edit HTML and PHP files
              >> for use on a Unix server. When I used the default setting
              >> (DOS/Windows?) we occasionally had problems with whitespace from
              >> PHP scripts, so my PHP coder advised me to select "Save As UNIX".
              >> That's now left as my default, even when creating text files for
              >> Windows use, so I hope it won't create any local issues for me.
              >
              >
              > Hi Tuttle,
              >
              > If you use the ASCII protocol to FTP your HTML and PHP files to the
              > UNIX server, the line ending get converted to the server's format. I
              > learned that while researching for the Custom FTP clips.
              >
              > See here, for example:
              > http://webtips.dan.info/misc.html
              >
              > or here:
              > http://www.websiterepairguy.com/articles/os/crlf.html
              >
              > So theoretically you could save everything in NoteTab using the
              > "DOS/Windows" format option, and not incur any local issues. Or just
              > use "Original" format option as the default. Then when new documents
              > are saved in NoteTab they will be saved in DOS/Windows format. If you
              > ever happen to edit a UNIX document, it will get saved as a UNIX file.
              > You would rarely be editing UNIX documents because if the document
              > came from the UNIX server using FTP and the ASCII protocol, your local
              > copies would be in DOS/Windows format. And if the document were
              > created locally it would also be in DOS/Windows format.

              Hi Sheri! Thanks for the response. My head is somewhat spinning from all that, but I
              will reread it and check out those links.

              Prior to changing NoteTab's pref to save files in Unix format, we were getting some
              issues with extra whitespace or carriage returns in files that I edited. The files
              were of course FTP'd in ASCII mode, yet we still had some issues. Those files are
              used on the Unix server and are parsed by PHP and an XML module. My Unix/PHP expert
              suggested saving edited files in Unix format, and that seemed to eliminate the
              problem.

              I'm certainly open to reinvestigating this issue.
            Your message has been successfully submitted and would be delivered to recipients shortly.