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

136229Re: trouble with pattern, character collections

Expand Messages
  • Christian Brabandt
    Feb 19, 2013
      Hi Erik!

      On Di, 19 Feb 2013, Erik Christiansen wrote:

      > On 18.02.13 23:06, Christian Brabandt wrote:
      > > No, it is because "\n" is evaluated to a true line feed, so "[^\n]"
      > > matches anything but ASCII NUL and ASCII 10, while '[^\n]' matches
      > > anything but ASCII NUL (which is used internally by Vim to distinguish
      > > lines from each other (e.g. a line seperator), so that a . matches
      > > anyhing in the buffer but the line seperator)
      > >
      > > > If so which is the best way to fix this - and which should be the way to
      > > > express [^\n] meaning do not match \n rather than behave like '.' then ?
      > Vim already uses '$' for EOL, documented at ":h $", which even seems to
      > offer the synonym "<End>".

      Well, if you think about it, $ matches something different. You can't
      say, "/n$n" can you?

      > Vim already has '.' to mean '.', so does not
      > need <elephant> for the same. So why do it???

      Because the '.' is a perfect valid alias to [^\n] in most regexes
      anyway? Why cripple it?

      > > [^\n] should always behave like '.'
      > No, sorry, only in a line devoid of newlines. By definition.
      > In regex terms, i.e the user view, [^\n] may match anything other than a
      > newline, while '.' may match any single character. Only if newlines have
      > been stripped in the internal line representation, and e.g. replaced
      > with NUL, can '.' legitimately fail to match \n. Otherwise, we can only
      > reasonably say the [^\n] should NOT always behave like '.'

      In all regexp engines that I know of, the '.' by default doesn't match a
      newline, so it is perfectly valid to have [^\n] match the same as '.'

      > In contrast, "[^\n]" _is_ identical to '[^\n]' in regex syntax, so must
      > be identical in behaviour, devoid of even subtle differences, in any
      > context.

      Please read again the article to which you replied. I already said, why
      this is different. This comes from the string-evaluation of the "[..]"
      expression. You can read about it at :h expr-string.

      > Sorry, [^\n] can never match \n ; not even in pink. That is broken
      > behaviour.

      Please come back with some arguments. I told you why this happens. If
      you don't want that, Vim already provides a setting to fix this.

      :set cpo+=l

      Mit freundlichen Grüßen
      Windows ist kein Virus - ein Virus tut etwas.

      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.
    • Show all 28 messages in this topic