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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
