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

Re: trouble with pattern, character collections

Expand Messages
  • Christian Brabandt
    Hi Marc! ... Bram, here is a patch, making [^ n] not match NL within the text and that also documents, that . matches CR and LF within the text. This makes
    Message 1 of 3 , Feb 19, 2013
    • 0 Attachment
      Hi Marc!

      On Mo, 18 Feb 2013, Marc Weber wrote:

      > I don't think that additional threads are going to help
      > There is an issue, and we should find a way to fix (IMHO).
      > Let me summarize again - and tell me if you feel differently.
      >
      > Test cases:
      > [1] echo len(matchstr("\n",'\zs[^\n]\ze'))
      > [2] echo len(matchstr("\n","\\zs[^\n]\\ze"))
      >
      > I expect both do the same, the difference is that the second as chr(10) in [^],
      > while the first has \n (which should be translated to chr(10).
      >
      > However I obsorve that [2] returns 0 as expected , but [1] does return
      > 1, thus it matches \n even though I told Vim that I do not want to match
      > it. People told me this was because '.' is equal to [^\n].
      >
      >
      > Current situation: at least to be fixed
      > 1:
      > No matter whether '.' should behave like [^\n]
      > [1] and [2] should behave the same, right?
      > 2:
      > This should be documented.
      > (Do you all at least agree these two statments?)

      Bram, here is a patch, making [^\n] not match NL within the text and
      that also documents, that '.' matches CR and LF within the text.

      This makes both [1] and [2] behave the same and seems to better match
      the users expectations.

      regards,
      Christian
      --
      Ein Volk kann nicht auf seine Genies, sondern auf das Volk, auf die
      Menge stolz sein - die Genies können auf die Genies es sein.
      -- Jean Paul

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Christian Brabandt
      ... Attached is an updated patch, that also prevents /[] matching [] (a collation cannot be empty, so I think it should return an error and other vi clones do,
      Message 2 of 3 , Feb 19, 2013
      • 0 Attachment
        On Di, 19 Feb 2013, Christian Brabandt wrote:

        > On Mo, 18 Feb 2013, Marc Weber wrote:
        > > I don't think that additional threads are going to help
        > > There is an issue, and we should find a way to fix (IMHO).
        > > Let me summarize again - and tell me if you feel differently.
        > >
        > > Test cases:
        > > [1] echo len(matchstr("\n",'\zs[^\n]\ze'))
        > > [2] echo len(matchstr("\n","\\zs[^\n]\\ze"))
        > >
        > > I expect both do the same, the difference is that the second as chr(10) in [^],
        > > while the first has \n (which should be translated to chr(10).
        > >
        > > However I obsorve that [2] returns 0 as expected , but [1] does return
        > > 1, thus it matches \n even though I told Vim that I do not want to match
        > > it. People told me this was because '.' is equal to [^\n].
        > >
        > >
        > > Current situation: at least to be fixed
        > > 1:
        > > No matter whether '.' should behave like [^\n]
        > > [1] and [2] should behave the same, right?
        > > 2:
        > > This should be documented.
        > > (Do you all at least agree these two statments?)
        >
        > Bram, here is a patch, making [^\n] not match NL within the text and
        > that also documents, that '.' matches CR and LF within the text.
        >
        > This makes both [1] and [2] behave the same and seems to better match
        > the users expectations.

        Attached is an updated patch, that also prevents /[] matching []
        (a collation cannot be empty, so I think it should return an error and
        other vi clones do, also grep and perl throw an error).

        Included are tests as well.

        regards,
        Christian
        --
        Sprachlexikon-Namen: GERRITT - gemütl. Schritt-Tempo b. Pferden

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Bram Moolenaar
        ... This isn t right, there are no NL characters in the text. There are NUL characters which are stored as NL characters. That s an implementation detail,
        Message 3 of 3 , Feb 20, 2013
        • 0 Attachment
          Christian Brabandt wrote:

          > Hi Marc!
          >
          > On Mo, 18 Feb 2013, Marc Weber wrote:
          >
          > > I don't think that additional threads are going to help
          > > There is an issue, and we should find a way to fix (IMHO).
          > > Let me summarize again - and tell me if you feel differently.
          > >
          > > Test cases:
          > > [1] echo len(matchstr("\n",'\zs[^\n]\ze'))
          > > [2] echo len(matchstr("\n","\\zs[^\n]\\ze"))
          > >
          > > I expect both do the same, the difference is that the second as chr(10) in [^],
          > > while the first has \n (which should be translated to chr(10).
          > >
          > > However I obsorve that [2] returns 0 as expected , but [1] does return
          > > 1, thus it matches \n even though I told Vim that I do not want to match
          > > it. People told me this was because '.' is equal to [^\n].
          > >
          > >
          > > Current situation: at least to be fixed
          > > 1:
          > > No matter whether '.' should behave like [^\n]
          > > [1] and [2] should behave the same, right?
          > > 2:
          > > This should be documented.
          > > (Do you all at least agree these two statments?)
          >
          > Bram, here is a patch, making [^\n] not match NL within the text and
          > that also documents, that '.' matches CR and LF within the text.
          >
          > This makes both [1] and [2] behave the same and seems to better match
          > the users expectations.

          This isn't right, there are no NL characters in the text. There are NUL
          characters which are stored as NL characters. That's an implementation
          detail, which sometimes becomes visible to the user.

          It's good to explain this in the docs. I'm not sure we actually should
          change the behavior, it might not really take away much confusion.


          --
          DENNIS: You can't expect to wield supreme executive power just 'cause some
          watery tart threw a sword at you!
          "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ an exciting new programming language -- http://www.Zimbu.org ///
          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        Your message has been successfully submitted and would be delivered to recipients shortly.