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

Re: VIML regex comparison problem

Expand Messages
  • Mike Williams
    ... My bad again. On Windows fnamemodify(..., :p ) appears to normalise the given path to remove things like .. and . whereas on unix it doesn t. I was
    Message 1 of 10 , Sep 9, 2013
    • 0 Attachment
      On 09/09/2013 12:47, ZyX wrote:
      >> I had tried calls to escape(..., '\') and that made no difference.
      >> Changing the test
      >>
      >> if l:d !~ "^\V" . s:dir1
      >>
      >> makes no difference.
      >
      > It makes difference with some specific directory names. “Specific” includes dots in directory name.

      My bad again. On Windows fnamemodify(..., ':p') appears to normalise
      the given path to remove things like .. and . whereas on unix it
      doesn't. I was hoping to rely on normalisation being done for me.

      >> If I substitute all back slashes for forward slashes then it works as I
      >> expect. So basically I tripped and fallen into backslash hell, again.
      >>
      >>> b) you do not need regular expressions at all, use l:d[:len(s:dir1)-1] is#
      >>> s:dir1 (use is? for windows).
      >>
      >> Which does work (toss up between using is# and ==# in this case) -
      >> thanks :-)
      >
      > “A is# b” is like “type(A) == type(b) && A ==# b”. I just use it always for string comparison because I constantly use zero as a substitution for python None (e.g. as a default value) and “"abc" == 0” is true because if one of the “==” operands is a number another operand is also coerced to a number. Using “#” and “?” is a good habit because it is bad idea to rely on user settings.
      >
      > Note that I use is# here not because I expect number as one of the operands *here*. I use it because it is string comparison and in some *other* string comparisons I write numbers are expected.

      Thanks for the explanation - this is my first deep dive in VIML to do
      something more than solve an immediate issue. Reading around some of
      the larger plugins and some blogs I get the interesting aroma of python
      and javascript idioms being used, so I expect more confusion as I move
      on until things start to sink in deep.

      Mike
      --
      Old enough to know better, but young enough to not care.

      --
      --
      You received this message from the "vim_dev" 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_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Nikolay Pavlov
      On Sep 9, 2013 4:30 PM, Mike Williams ... includes dots in directory name. ... given path to remove things like .. and .
      Message 2 of 10 , Sep 9, 2013
      • 0 Attachment


        On Sep 9, 2013 4:30 PM, "Mike Williams" <mike.williams@...> wrote:
        >
        > On 09/09/2013 12:47, ZyX wrote:
        >>>
        >>> I had tried calls to escape(..., '\') and that made no difference.
        >>> Changing the test
        >>>
        >>>         if l:d !~ "^\V" . s:dir1
        >>>
        >>> makes no difference.
        >>
        >>
        >> It makes difference with some specific directory names. “Specific” includes dots in directory name.
        >
        >
        > My bad again.  On Windows fnamemodify(..., ':p') appears to normalise the given path to remove things like .. and . whereas on unix it doesn't.  I was hoping to rely on normalisation being done for me.

        There is simplify() function for this.  I personally used to hold most data in directory named literally "*.*" (due to too many dotdirs in $HOME). Three meta-characters! Now it got renamed to a.a.

        There are also normpath and realpath functions in my frawor framework, in autoload/frawor/os.vim and plugin/frawor.vim. They also resolve all symlinks:

        https://bitbucket.org/ZyX_I/frawor/src/bd41cfedd93dbf18b134be8e967d56c36315914b/plugin/frawor.vim#cl-272 and line 283 below;
        https://bitbucket.org/ZyX_I/frawor/src/bd41cfedd93dbf18b134be8e967d56c36315914b/autoload/frawor/os.vim#cl-58 and line 125.

        First one is used to be sure that directories are the same thus doing aggressive normalization, second are library functions.

        >
        >>> If I substitute all back slashes for forward slashes then it works as I
        >>> expect.  So basically I tripped and fallen into backslash hell, again.
        >>>
        >>>> b) you do not need regular expressions at all, use l:d[:len(s:dir1)-1] is#
        >>>> s:dir1 (use is? for windows).
        >>>
        >>>
        >>> Which does work (toss up between using is# and ==# in this case) -
        >>> thanks :-)
        >>
        >>
        >> “A is# b” is like “type(A) == type(b) && A ==# b”. I just use it always for string comparison because I constantly use zero as a substitution for python None (e.g. as a default value) and “"abc" == 0” is true because if one of the “==” operands is a number another operand is also coerced to a number. Using “#” and “?” is a good habit because it is bad idea to rely on user settings.
        >>
        >> Note that I use is# here not because I expect number as one of the operands *here*. I use it because it is string comparison and in some *other* string comparisons I write numbers are expected.
        >
        >
        > Thanks for the explanation - this is my first deep dive in VIML to do something more than solve an immediate issue.  Reading around some of the larger plugins and some blogs I get the interesting aroma of python and javascript idioms being used, so I expect more confusion as I move on until things start to sink in deep.
        >
        >
        > Mike
        > --
        > Old enough to know better, but young enough to not care.

        --
        --
        You received this message from the "vim_dev" 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_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Mike Williams
        ... I hate Mondays. No it is working on unix - I had an extra character in a directory which resulted in the path being left as is which confused me. ...
        Message 3 of 10 , Sep 9, 2013
        • 0 Attachment
          On 09/09/2013 14:35, Nikolay Pavlov wrote:
          > On Sep 9, 2013 4:30 PM, "Mike Williams" <mike.williams@...>
          > wrote:
          >>
          >> On 09/09/2013 12:47, ZyX wrote:
          >>>>
          >>>> I had tried calls to escape(..., '\') and that made no difference.
          >>>> Changing the test
          >>>>
          >>>> if l:d !~ "^\V" . s:dir1
          >>>>
          >>>> makes no difference.
          >>>
          >>>
          >>> It makes difference with some specific directory names. “Specific”
          > includes dots in directory name.
          >>
          >>
          >> My bad again. On Windows fnamemodify(..., ':p') appears to normalise the
          > given path to remove things like .. and . whereas on unix it doesn't. I
          > was hoping to rely on normalisation being done for me.

          I hate Mondays. No it is working on unix - I had an extra character in
          a directory which resulted in the path being left as is which confused me.

          > There is simplify() function for this. I personally used to hold most data
          > in directory named literally "*.*" (due to too many dotdirs in $HOME).
          > Three meta-characters! Now it got renamed to a.a.

          Thanks - I had missed simplify() and that has pinged me to resolve() as
          well.

          > There are also normpath and realpath functions in my frawor framework, in
          > autoload/frawor/os.vim and plugin/frawor.vim. They also resolve all
          > symlinks:
          >
          > https://bitbucket.org/ZyX_I/frawor/src/bd41cfedd93dbf18b134be8e967d56c36315914b/plugin/frawor.vim#cl-272and
          > line 283 below;
          > https://bitbucket.org/ZyX_I/frawor/src/bd41cfedd93dbf18b134be8e967d56c36315914b/autoload/frawor/os.vim#cl-58and
          > line 125.
          >
          > First one is used to be sure that directories are the same thus doing
          > aggressive normalization, second are library functions.

          Looks real useful - I will have read around the framework for more
          inspiration.

          Cheers.

          >
          >>
          >>>> If I substitute all back slashes for forward slashes then it works as I
          >>>> expect. So basically I tripped and fallen into backslash hell, again.
          >>>>
          >>>>> b) you do not need regular expressions at all, use l:d[:len(s:dir1)-1]
          > is#
          >>>>> s:dir1 (use is? for windows).
          >>>>
          >>>>
          >>>> Which does work (toss up between using is# and ==# in this case) -
          >>>> thanks :-)
          >>>
          >>>
          >>> “A is# b” is like “type(A) == type(b) && A ==# b”. I just use it always
          > for string comparison because I constantly use zero as a substitution for
          > python None (e.g. as a default value) and “"abc" == 0” is true because if
          > one of the “==” operands is a number another operand is also coerced to a
          > number. Using “#” and “?” is a good habit because it is bad idea to rely on
          > user settings.
          >>>
          >>> Note that I use is# here not because I expect number as one of the
          > operands *here*. I use it because it is string comparison and in some
          > *other* string comparisons I write numbers are expected.
          >>
          >>
          >> Thanks for the explanation - this is my first deep dive in VIML to do
          > something more than solve an immediate issue. Reading around some of the
          > larger plugins and some blogs I get the interesting aroma of python and
          > javascript idioms being used, so I expect more confusion as I move on until
          > things start to sink in deep.
          >>
          >>
          >> Mike
          >> --
          >> Old enough to know better, but young enough to not care.
          >


          Mike
          --
          Old enough to know better, but young enough to not care.

          --
          --
          You received this message from the "vim_dev" 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_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        Your message has been successfully submitted and would be delivered to recipients shortly.