Re: trouble with pattern, character collections

Hi Marc!

On Di, 19 Feb 2013, Marc Weber wrote:

> I want Vim defaults to be
> - sane
> - follow the principle of least surprise.
> (I'd like nocompatible to be set by default, but that's another story)
>
> Christian: :set cpo+=l still makes my test cases fail:
> [1] echo len(matchstr("\n",'\zs[^\n]\ze'))
> [2] echo len(matchstr("\n","\\zs[^\n]\\ze")

Well, you need to prevent that expr-quote (:h expr-quote) is being
evaluated. You need to escape the \ then.

> You explained it by \n not being chr(10), so what is it?

No. Please read again what I wrote. I am not going to repeat myself.

> Let's try by understanding \n's behaviour:
> ==========================================
>
> case 1) vim buf
> To my undestanding $ matches end of line (in a vim buffer) without eating that
> end of line whereas \n does both: it matches and eats the end of line.
> Eg try /..\n.. and :set hlsearch
>
> Thus \n is the same as $\n when applying regex to vim buffers. dos 1310 usually
> is encoded in a ff setting, so \n does what you want if you want it.
>
> case 2) matchstr, matchall, substitute =~ and whatnot (?)
>
> So if \n is not chr(10), what is it then in this case?
>
> echo len(matchstr("\n",'\zs[^\n]\ze'))
>
> clearly indicates it matches \n and and I agree on Erik which called it this way
>

Vim internals do not distinguish between evaluating functions and
buffers. They work on matching a regular pattern on a string of text. In
Vim buffers, lines are distinguished in memory by NUL and that is the
only thing, that '.' does not match and so does [^\n] so that in a
buffer a search for /[^\n] will match any char (even control codes like
CR or LF)

What you want is, that in a text /[^\n] also does not match LF character
and that is what my patch provides thus it should do what you want.

> Is there more to fix?
> =====================
>
> issue 1)
>
> docs state:
> [] (with 'nomagic': \[]) */[]* */\[]* */\_[]* */collection*
> \_[]
>
> Well - try /[] - it will not be treated as collection, it'll match [], because
> its empty!! So there should be a comment that collections must contain at least
> one char to be seen as one.

I would call this a bug as well. I think, this should give an error.

> issue 2)
> With "\_" prepended the collection also includes the end-of-line - why does it exist, because
> [\n] is accepted and works as expected?
>
> So can \_[] syntax be deprecated?

Why is this an issue? I don't see a problem with \_ syntax at all.

Mit freundlichen Grüßen
Christian
--
Dem großen Publikum ist ein Buch nicht leicht zu schlecht, sehr
leicht aber zu gut.
-- Marie von Ebner-Eschenbach

--
--
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.