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

Re: expand('%:h:h')

Expand Messages
  • Bram Moolenaar
    ... I don t really like this. If one wants to go above the current directory you can use :p . If it s not there then turning the path into an absolute path
    Message 1 of 8 , Mar 23, 2013
      Christian Brabandt wrote:

      > On Sa, 23 Mär 2013, Marcin Szamotulski wrote:
      >
      > > Dear Vim_Dev,
      > >
      > > If one is in the directory of the current file '%:h:h' expands to '.',
      > > while it should expand tas '%:p:h:h' does. This is probably is not very
      > > useful case since using '../' is much simpler, though it might be used
      > > in a plugin (I've never been hit by this though). Expansion of '%:h:h'
      > > works fine when the current directory is not where the current file is.
      > >
      > > Another, similar issue is when the current file is:
      > > /home/user/directory/file.txt
      > > and the current directory is
      > > /home/user
      > >
      > > Then both '%:h:h' and '%:h:h:h' expand to '.'.
      >
      > I think this patch fixes it. It does so, by noticing, whether *fnamep
      > has been set to '.' and if so and we are still trying to resolve one
      > level up, will resolve '.' to an absolute path.

      I don't really like this. If one wants to go above the current
      directory you can use ":p". If it's not there then turning the path
      into an absolute path is, well, unexpected.

      What problem are we fixing here?


      --
      From "know your smileys":
      *<|:-) Santa Claus (Ho Ho Ho)

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ an exciting new programming language -- http://www.Zimbu.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

      --
      --
      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.
    • Ingo Karkat
      ... I would prefer Christian s changed behavior. As it stands now, you have to always use :p:h:h to avoid that the upwards move stops at . . If you forget
      Message 2 of 8 , Mar 23, 2013
        On 23-Mar-13 17:26:13 +0100, Bram Moolenaar wrote:

        > Christian Brabandt wrote:
        >
        >> On Sa, 23 Mär 2013, Marcin Szamotulski wrote:
        >>
        >>> Dear Vim_Dev,
        >>>
        >>> If one is in the directory of the current file '%:h:h' expands to '.',
        >>> while it should expand tas '%:p:h:h' does. This is probably is not very
        >>> useful case since using '../' is much simpler, though it might be used
        >>> in a plugin (I've never been hit by this though). Expansion of '%:h:h'
        >>> works fine when the current directory is not where the current file is.
        >>>
        >>> Another, similar issue is when the current file is:
        >>> /home/user/directory/file.txt
        >>> and the current directory is
        >>> /home/user
        >>>
        >>> Then both '%:h:h' and '%:h:h:h' expand to '.'.
        >>
        >> I think this patch fixes it. It does so, by noticing, whether *fnamep
        >> has been set to '.' and if so and we are still trying to resolve one
        >> level up, will resolve '.' to an absolute path.
        >
        > I don't really like this. If one wants to go above the current
        > directory you can use ":p".
        > What problem are we fixing here?

        I would prefer Christian's changed behavior. As it stands now, you have to
        always use :p:h:h to avoid that the upwards move stops at ".". If you forget
        about this corner case, it's likely a bug; I can't think of using this behavior
        deliberately.

        > If it's not there then turning the path into an absolute path is,
        > well, unexpected.

        Can't we change the patch so that it turns into the relative upwards move ".."
        (then "../..", etc.)?! This way, it stays relative, and one has to use :p to get
        absolute paths.

        -- regards, ingo

        --
        --
        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.
      • Christian Brabandt
        Hi Ingo! ... Indeed and I really don t mind here. Current version is ok for me. ... You might end up with many ../../../../ and I don t think this help.
        Message 3 of 8 , Mar 23, 2013
          Hi Ingo!

          On Sa, 23 Mär 2013, Ingo Karkat wrote:

          > On 23-Mar-13 17:26:13 +0100, Bram Moolenaar wrote:
          >
          > > Christian Brabandt wrote:
          > >
          > >> On Sa, 23 Mär 2013, Marcin Szamotulski wrote:
          > >>
          > >>> Dear Vim_Dev,
          > >>>
          > >>> If one is in the directory of the current file '%:h:h' expands to '.',
          > >>> while it should expand tas '%:p:h:h' does. This is probably is not very
          > >>> useful case since using '../' is much simpler, though it might be used
          > >>> in a plugin (I've never been hit by this though). Expansion of '%:h:h'
          > >>> works fine when the current directory is not where the current file is.
          > >>>
          > >>> Another, similar issue is when the current file is:
          > >>> /home/user/directory/file.txt
          > >>> and the current directory is
          > >>> /home/user
          > >>>
          > >>> Then both '%:h:h' and '%:h:h:h' expand to '.'.
          > >>
          > >> I think this patch fixes it. It does so, by noticing, whether *fnamep
          > >> has been set to '.' and if so and we are still trying to resolve one
          > >> level up, will resolve '.' to an absolute path.
          > >
          > > I don't really like this. If one wants to go above the current
          > > directory you can use ":p".

          Indeed and I really don't mind here. Current version is ok for me.

          > Can't we change the patch so that it turns into the relative upwards move ".."
          > (then "../..", etc.)?! This way, it stays relative, and one has to use :p to get
          > absolute paths.

          You might end up with many ../../../../ and I don't think this help.

          regards,
          Christian
          --
          Glauben und Wissen vertragen sich nicht wohl im selben Kopfe: sie sind
          darin wie Wolf und Schaf in einem Käfig; und zwar ist das Wissen der
          Wolf, der den Nachbar aufzufressen droht.
          -- Arthur Schopenhauer (Parerga und Paralipomena II)

          --
          --
          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.
        • Ingo Karkat
          ... Granted, it s a corner case, but why not make it more consistent? One trap less, one thing less to code around in plugins. ... It s certainly not nice to
          Message 4 of 8 , Mar 23, 2013
            On 23-Mar-13 20:21:58 +0100, Christian Brabandt wrote:

            > Hi Ingo!
            >
            > On Sa, 23 Mär 2013, Ingo Karkat wrote:
            >
            >> On 23-Mar-13 17:26:13 +0100, Bram Moolenaar wrote:
            >>
            >>> Christian Brabandt wrote:
            >>>
            >>>> On Sa, 23 Mär 2013, Marcin Szamotulski wrote:
            >>>>
            >>>>> Dear Vim_Dev,
            >>>>>
            >>>>> If one is in the directory of the current file '%:h:h' expands to '.',
            >>>>> while it should expand tas '%:p:h:h' does. This is probably is not very
            >>>>> useful case since using '../' is much simpler, though it might be used
            >>>>> in a plugin (I've never been hit by this though). Expansion of '%:h:h'
            >>>>> works fine when the current directory is not where the current file is.
            >>>>>
            >>>>> Another, similar issue is when the current file is:
            >>>>> /home/user/directory/file.txt
            >>>>> and the current directory is
            >>>>> /home/user
            >>>>>
            >>>>> Then both '%:h:h' and '%:h:h:h' expand to '.'.
            >>>>
            >>>> I think this patch fixes it. It does so, by noticing, whether *fnamep
            >>>> has been set to '.' and if so and we are still trying to resolve one
            >>>> level up, will resolve '.' to an absolute path.
            >>>
            >>> I don't really like this. If one wants to go above the current
            >>> directory you can use ":p".
            >
            > Indeed and I really don't mind here. Current version is ok for me.

            Granted, it's a corner case, but why not make it more consistent? One trap less,
            one thing less to code around in plugins.

            >> Can't we change the patch so that it turns into the relative upwards
            >> move ".." (then "../..", etc.)?! This way, it stays relative, and one
            >> has to use :p to get absolute paths.
            >
            > You might end up with many ../../../../ and I don't think this help.

            It's certainly not nice to look at, but expand() will probably mostly be used in
            custom functions, anyway. I can imagine use cases where one wants to go
            programatically to a parent-parent-parent, and maybe stay in relative addressing
            (though I would prefer absolute addresses with :p then, too).

            -- regards, ingo

            --
            --
            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.
          • Marcin Szamotulski
            ... For me %:h:h being the same as %:h is quite not intuitive. I only hope that in my plugins whenever I used :h is have added :p before it. I think mostly
            Message 5 of 8 , Mar 23, 2013
              On 20:53 Sat 23 Mar , Ingo Karkat wrote:
              > On 23-Mar-13 20:21:58 +0100, Christian Brabandt wrote:
              >
              > > Hi Ingo!
              > >
              > > On Sa, 23 Mär 2013, Ingo Karkat wrote:
              > >
              > >> On 23-Mar-13 17:26:13 +0100, Bram Moolenaar wrote:
              > >>
              > >>> Christian Brabandt wrote:
              > >>>
              > >>>> On Sa, 23 Mär 2013, Marcin Szamotulski wrote:
              > >>>>
              > >>>>> Dear Vim_Dev,
              > >>>>>
              > >>>>> If one is in the directory of the current file '%:h:h' expands to '.',
              > >>>>> while it should expand tas '%:p:h:h' does. This is probably is not very
              > >>>>> useful case since using '../' is much simpler, though it might be used
              > >>>>> in a plugin (I've never been hit by this though). Expansion of '%:h:h'
              > >>>>> works fine when the current directory is not where the current file is.
              > >>>>>
              > >>>>> Another, similar issue is when the current file is:
              > >>>>> /home/user/directory/file.txt
              > >>>>> and the current directory is
              > >>>>> /home/user
              > >>>>>
              > >>>>> Then both '%:h:h' and '%:h:h:h' expand to '.'.
              > >>>>
              > >>>> I think this patch fixes it. It does so, by noticing, whether *fnamep
              > >>>> has been set to '.' and if so and we are still trying to resolve one
              > >>>> level up, will resolve '.' to an absolute path.
              > >>>
              > >>> I don't really like this. If one wants to go above the current
              > >>> directory you can use ":p".
              > >
              > > Indeed and I really don't mind here. Current version is ok for me.
              >
              > Granted, it's a corner case, but why not make it more consistent? One trap less,
              > one thing less to code around in plugins.
              >
              > >> Can't we change the patch so that it turns into the relative upwards
              > >> move ".." (then "../..", etc.)?! This way, it stays relative, and one
              > >> has to use :p to get absolute paths.
              > >
              > > You might end up with many ../../../../ and I don't think this help.
              >
              > It's certainly not nice to look at, but expand() will probably mostly be used in
              > custom functions, anyway. I can imagine use cases where one wants to go
              > programatically to a parent-parent-parent, and maybe stay in relative addressing
              > (though I would prefer absolute addresses with :p then, too).
              >
              > -- regards, ingo
              >
              > --
              > --
              > 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.
              >

              For me %:h:h being the same as %:h is quite not intuitive. I only hope
              that in my plugins whenever I used :h is have added :p before it.
              I think mostly about plugin writers who might not know this corner case.

              Best regards,
              Marcin

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