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

NTB/RegEx FormFeed Bug

Expand Messages
  • Art Kocsis
    This is either a bug in NTB or a bug in RegEX or both. Somehow a form feed char (0Ch) crept into a file. It was invisible as it was the only char in the line:
    Message 1 of 8 , Aug 4, 2012
    • 0 Attachment
      This is either a bug in NTB or a bug in RegEX or both.

      Somehow a form feed char (0Ch) crept into a file.
      It was invisible as it was the only char in the line:
      0C0D0A
      It showed up as a single line, the 0Ch being treated as a space

      The RegEx pattern: ^!Replace "\R" >> "\r\n" AIRSTW
      failed to find or replace it.

      NTB displays it on screen as a single line when it probably
      should have been two empty lines as NTB's working environment
      is supposed to be Windows CRLF IIRC.
    • John Shotsky
      You can get rid of those with: ^!Replace f ARSW It s part of my standard library of characters to handle at the beginning of my larger library.
      Message 2 of 8 , Aug 5, 2012
      • 0 Attachment
        You can get rid of those with:
        ^!Replace "\f" >> "" ARSW

        It's part of my standard library of characters to handle at the beginning of my larger library.
        Regards,
        John
        RecipeTools Web Site: <http://recipetools.gotdns.com/> http://recipetools.gotdns.com/

        From: notetab@yahoogroups.com [mailto:notetab@yahoogroups.com] On Behalf Of Art Kocsis
        Sent: Saturday, August 04, 2012 23:38
        To: NoteTab-Basic
        Subject: [NTB] NTB/RegEx FormFeed Bug


        This is either a bug in NTB or a bug in RegEX or both.

        Somehow a form feed char (0Ch) crept into a file.
        It was invisible as it was the only char in the line:
        0C0D0A
        It showed up as a single line, the 0Ch being treated as a space

        The RegEx pattern: ^!Replace "\R" >> "\r\n" AIRSTW
        failed to find or replace it.

        NTB displays it on screen as a single line when it probably
        should have been two empty lines as NTB's working environment
        is supposed to be Windows CRLF IIRC.



        [Non-text portions of this message have been removed]
      • Art Kocsis
        ... Yes, I know. Already coded workaround. My post was a bug report only. Art
        Message 3 of 8 , Aug 5, 2012
        • 0 Attachment
          At 8/5/2012 01:51 AM, John wrote:
          >You can get rid of those with:
          >^!Replace "\f" >> "" ARSW

          Yes, I know. Already coded workaround.

          My post was a bug report only.

          Art
        • John Shotsky
          According to the PCRE help, there is a compile switch that forces only CR and LF to be recognized in the R sequence. There is a command to override that
          Message 4 of 8 , Aug 5, 2012
          • 0 Attachment
            According to the PCRE help, there is a compile switch that forces only CR and LF to be recognized in the \R sequence.
            There is a command to override that switch, but I don't know how to use it.

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

            From: notetab@yahoogroups.com [mailto:notetab@yahoogroups.com] On Behalf Of Art Kocsis
            Sent: Sunday, August 05, 2012 03:21
            To: notetab@yahoogroups.com
            Subject: RE: [NTB] NTB/RegEx FormFeed Bug


            At 8/5/2012 01:51 AM, John wrote:
            >You can get rid of those with:
            >^!Replace "\f" >> "" ARSW

            Yes, I know. Already coded workaround.

            My post was a bug report only.

            Art



            [Non-text portions of this message have been removed]
          • Eric Fookes
            Hi Art and John, NoteTab uses the PCRE_BSR_ANYCRLF compile switch, which is why the form feed character is not included in the R match. -- Regards, Eric
            Message 5 of 8 , Aug 6, 2012
            • 0 Attachment
              Hi Art and John,

              NoteTab uses the PCRE_BSR_ANYCRLF compile switch, which is why the form
              feed character is not included in the \R match.

              --
              Regards,

              Eric Fookes
              http://www.fookes.com/


              On 05/08/2012 13:05, John Shotsky wrote:
              > According to the PCRE help, there is a compile switch that forces only CR and LF to be recognized in the \R sequence.
              > There is a command to override that switch, but I don't know how to use it.
              >
              > Regards,
              > John
              > RecipeTools Web Site: <http://recipetools.gotdns.com/> http://recipetools.gotdns.com/
              >
              > At 8/5/2012 01:51 AM, John wrote:
              >> You can get rid of those with:
              >> ^!Replace "\f" >> "" ARSW
              >
              > Yes, I know. Already coded workaround.
              >
              > My post was a bug report only.
              >
              > Art
            • Sheri
              You could use (*BSR_UNICODE) at the start of your pattern to invoke the alternative setting. Can be slightly problematic since 85 is an ellipsis in Windows
              Message 6 of 8 , Aug 6, 2012
              • 0 Attachment
                You could use (*BSR_UNICODE) at the start of your pattern to invoke the alternative setting. Can be slightly problematic since \85 is an ellipsis in Windows ANSI for most or all Western languages, but the rest of the Unicode line ends are ok even in non-UTF-8 mode.

                Hi all...!

                Regards,
                Sheri

                Sent from my Nook Color device
              • Sheri
                Sorry, meant x85, not 85. Sent from my Nook Color device
                Message 7 of 8 , Aug 6, 2012
                • 0 Attachment
                  Sorry, meant \x85, not \85.

                  Sent from my Nook Color device

                  Sheri <silvermoonwoman@...> wrote:

                  >You could use (*BSR_UNICODE) at the start of your pattern to invoke the alternative setting. Can be slightly problematic since \85 is an ellipsis in Windows ANSI for most or all Western languages, but the rest of the Unicode line ends are ok even in non-UTF-8 mode.
                  >
                  >Hi all...!
                  >
                  >Regards,
                  >Sheri
                  >
                  >Sent from my Nook Color device
                • flo.gehrke
                  ... Here is a small test: ^!InsertText Peter^PPaul^PMary^%PAGE% ^!Jump -3 ^!Find (*BSR_UNICODE)Mary R RS You will see NT matching Mary plus FF now. If
                  Message 8 of 8 , Aug 6, 2012
                  • 0 Attachment
                    --- In notetab@yahoogroups.com, "John Shotsky" <jshotsky@...> wrote:
                    >
                    > According to the PCRE help, there is a compile switch that
                    > forces only CR and LF to be recognized in the \R sequence.
                    > There is a command to override that switch, but I don't
                    > know how to use it.

                    --- corrigendum ---

                    Here is a small test:

                    ^!InsertText Peter^PPaul^PMary^%PAGE%
                    ^!Jump -3
                    ^!Find "(*BSR_UNICODE)Mary\R" RS

                    You will see NT matching 'Mary' plus FF now.

                    If (*BSR_ANYCRLF) is active, the alternatives for matching FF are.

                    \f
                    \cl
                    \x0C
                    \014
                    etc

                    Regards,
                    Flo
                  Your message has been successfully submitted and would be delivered to recipients shortly.