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

Re: trouble with pattern, character collections

Expand Messages
  • Marc Weber
    Hi Bram, thanks for joining the discussion and participating. echo len(nr2char(0)) returns 0, where is the 0 char stored as n .. So please take care about the
    Message 1 of 28 , Feb 20, 2013
    • 0 Attachment
      Hi Bram,

      thanks for joining the discussion and participating.

      echo len(nr2char(0))
      returns 0, where is the 0 char stored as \n ..
      So please take care about the use case: I'm not talking about buffers,
      I'm talking about matchstr, substitute etc and viml strings.

      I'm aware that both should be tested and documented which becomes clear
      reading my later summary.

      Anyway [^\n] matching \n is a very very unexpected behaviour.
      Having \_[ syntax doesn't make sense, either. Because [\n] works and is
      standard. And this should be visible in docs.

      Marc Weber

      --
      --
      You received this message from the "vim_use" 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_use" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Erik Christiansen
      ... Bram, is that meant to be There are NL characters which are stored as NUL characters ? Because if there are no NL characters in the text , then nothing
      Message 2 of 28 , Feb 20, 2013
      • 0 Attachment
        On 20.02.13 13:32, Bram Moolenaar wrote:
        > Christian Brabandt wrote:
        > > 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.

        Bram, is that meant to be "There are NL characters which are stored as
        NUL characters"? Because if "there are no NL characters in the text",
        then nothing can be stored as them, can it?

        > That's an implementation detail, which sometimes becomes visible to
        > the user.

        OK, but the actual problem is corruption of a regex syntax snippet in
        one quoting context. Letting "[^\n]" not be the same as '[^\n]' is the
        mark of a broken regex implementation. Other regex engines manage \n
        without their syntax breaking, so it is possible with Vim too.

        Vim has '.' to represent "any character", and so does not require a
        second representation for that. But if [^\n] is the same as '.', because
        there are no newlines present, then that must _always_ be the case,
        regardless of a bit of quoting flim-flam.

        > It's good to explain this in the docs.

        Yes, knowing that there are no newlines can help us avoid looking for
        them.

        Another fix is needed, though, for the problem that quote flavour is
        allowed to corrupt the regex in one case, causing behaviour contrary to
        the quoted regex syntax. That is an illogicality boobytrap to torment
        the user.

        > I'm not sure we actually should change the behavior, it might not
        > really take away much confusion.

        Excuse me, Bram but removing the broken behaviour of "[^\n]" not being
        the same as '[^\n]' does remove a mind boggling logical nonsense, and so
        does do away with major confusion.

        Deep knowledge if Vim internals is an asset when it fosters effective
        and robust fixes, but tends toward a liability if it blinds one to the
        failings of a self-contradicting user interface, I think.

        In all that we construct, it is _what_ should happen which guides _how_
        it is made to happen. Arguments defending the current broken status
        repeatedly refer to _how_ usurping _what_, as an implementational
        side effect, and accepting that as a justification. That is not
        intelligent design, and has here led to impaired functionality.

        Vim's supremacy would be improved by removing the user interface
        deficiency.

        Erik

        --
        You have all eternity to be cautious in when you're dead.
        - Lois Platford

        --
        --
        You received this message from the "vim_use" 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_use" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+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.