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

Re: trouble with pattern, character collections

Expand Messages
  • 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 1 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 2 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.