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

136239Re: trouble with pattern, character collections

Expand Messages
  • Christian Brabandt
    Feb 19, 2013
      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
      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.
    • Show all 28 messages in this topic