Re: trouble with pattern, character collections

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
Christian
--
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@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.