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

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

Expand Messages
  • Christian Brabandt
    Hi Marcin! ... 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
    Message 1 of 8 , Mar 23, 2013
    • 0 Attachment
      Hi Marcin!

      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.

      diff --git a/src/eval.c b/src/eval.c
      --- a/src/eval.c
      +++ b/src/eval.c
      @@ -23902,6 +23902,17 @@
      {
      valid |= VALID_HEAD;
      *usedlen += 2;
      + if (*fnamep != NULL && **fnamep == '.' && *fnamelen == 1)
      + {
      + /* fnamep was already set to '.', try to move one directory up */
      + *fnamep = FullName_save(*fnamep, FALSE);
      + vim_free(*bufp);
      + if (*fnamep == NULL)
      + return -1;
      + p = *bufp = *fnamep;
      + tail = gettail(*fnamep);
      + *fnamelen = (int)STRLEN(*fnamep);
      + }
      s = get_past_head(*fnamep);
      while (tail > s && after_pathsep(s, tail))
      mb_ptr_back(*fnamep, tail);


      regards,
      Christian
      --
      Heute haben es die Frauen nur noch beim Friseur eilig, unter die Haube
      zu kommen.
      -- Joachim Fuchsberger

      --
      --
      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.
    • 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 2 of 8 , Mar 23, 2013
      • 0 Attachment
        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 3 of 8 , Mar 23, 2013
        • 0 Attachment
          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 4 of 8 , Mar 23, 2013
          • 0 Attachment
            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 5 of 8 , Mar 23, 2013
            • 0 Attachment
              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 6 of 8 , Mar 23, 2013
              • 0 Attachment
                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.