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

Re: trouble with pattern, character collections

Expand Messages
  • 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 1 of 28 , Feb 20, 2013
      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

      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


      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.