136239Re: trouble with pattern, character collections
- Feb 19, 2013Hi 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:
>  echo len(matchstr("\n",'\zs[^\n]\ze'))
>  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
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@....
For more options, visit https://groups.google.com/groups/opt_out.
- << Previous post in topic Next post in topic >>