Manuel, are you referring to a regression or a long-standing TODO for
find_file_in_path?
It sounds to me like a serious problem, but maybe one that not a lot of people
use very heavily (at least not yet on vim 7.4?).
Aaron, are you able to bisect and find an exact version where this appeared?
(Sounds like a pain to hunt through that many versions and rebuild vim that
many times, but it would be nice to know ballpark when it appeared. Hopefully
it was just a bad minor change that needs to be tweaked and not fallout from
some major rewrite.)
David
On Friday, December 27, 2013 7:41:20 AM UTC-8, Aaron Bohannon wrote:
> *ping*
>
> Hopefully, I didn't offend anyone with my follow-up message. I'm happy to be
> corrected if I'm wrong. I'd just like to know what the consensus is on this
> issue.
>
> On Saturday, December 21, 2013 12:19:18 PM UTC-5, Aaron Bohannon wrote:
> > OK, it appears there is a lot of confusion about how upward search is
> > supposed to work. I know I used to be confused for a long time so this is
> > not so surprising. You have to read the documentation very carefully and
> > look at the examples. (And the documentation is the same in version 7.4 as
> > it was in version 7.3.)
> >
> > The thing to note is that using a relative path isn't just a shorter way to
> > give an absolute path. It actually means something quite different. IMO,
> > it should have been listed as a totally separate bullet point in the
> > documentation.
> >
> > With either kind of upward search, the stop directory (after the
> > semi-colon) works the same and isn't relevant to the issue at hand here.
> > Leaving it blank means the search will keep going upward as far as it can,
> > which is what I wanted.
> >
> > When you give an absolute path, you are telling vim where to start the
> > search. When you give a relative path, you *always* start the search from
> > the CWD, and the relative path is a sort of relative "offset", which is
> > appended to the end of each directory traversed. So these use the path in
> > a totally different way, and you could actually imagine a generalized form
> > of upward search that takes three paths: start, offset, and stop. It is
> > this "offset" feature that I need and appears broken. The example in the
> > help file should make it clear why such a thing is useful.
> >
> > I should point out that I still am unclear on exactly how path expressions
> > beginning with "." are meant to be handled. The search path expression
> > ".;" does in fact work in vim 7.4, but this is a corner case in which
> > interpreting "." as an absolute path (i.e., expanded before searching
> > begins) gives you behavior that is almost identical to interpreting it as a
> > relative path (i.e., expanding it relative to each directory visited during
> > searching). The documentation does suggest that paths beginning with "."
> > are supposed to be handled as relative paths, but I suspect that is not
> > actually being done in the case of ".;".
> >
> > Also, btw, my use of ":cd" in the example is not the issue. The example
> > works just the same if you first execute "cd .vim" in your shell and then
> > start vim from inside the ".vim" directory.
> >
> > ...Aaron
> >
> > On Friday, December 20, 2013 10:21:48 AM UTC-5, Ben Fritz wrote:
> > > On Friday, December 20, 2013 7:51:25 AM UTC-6, Christian Brabandt wrote:
> > > > Hi Aaron!
> > > >
> > > > On Do, 19 Dez 2013, Aaron Bohannon wrote:
> > > >
> > > > > To reproduce (on standard *nix installation):
> > > > >
> > > > > (1) start vim in your home directory
> > > > > (2) :cd .vim
> > > > > (3) :echo findfile('.vimrc', expand('$USER') . ';')
> > > > >
> > > > > In vim 7.3, you get something like "/home/$USER/.vimrc".
> > > > >
> > > > > In vim 7.4, you get nothing.
> > > > >
> > > > > I can't understand why no one's reported this. Am I the only person
> > > > > on the planet who uses this feature? I don't know how to get by
> > > > > without it.
> > > >
> > > > You are giving only a partial directory name as stop dir. I am not
> > > > sure,
> > > > this was ever supposed to work. I think, echo findfile('.vimrc',
> > > > '*'.expand('$USER').';') might work, however.
> > > >
> > >
> > > Well, I can confirm on Windows that the behavior changed between 7.3 and
> > > 7.4. But I think this is a case of misunderstanding how ';' is supposed
> > > to work. I was a little confused myself to begin with and tried the
> > > exact same thing to see the failure!
> > >
> > > Looking at :help file-searching, in the section on "upward search", it
> > > took a little while, but eventually I understood that you put the "stop
> > > directory" AFTER the ';', not before.
> > >
> > > I think both you and the OP intended to use ';'.expand('$USER') instead
> > > of the other way around.
> > >
> > > Some experimentation shows that these work, on Vim 7.4, when the
> > > directory is C:\Users\Ben\vimfiles\plugin:
> > >
> > > :echo findfile('_viminfo', ';')
> > > :echo findfile('_viminfo', ';Ben')
> > >
> > > This does NOT work, it doesn't echo anything as the OP reported:
> > >
> > > :echo findfile('_viminfo', 'Ben;')
> > >
> > > All three of these work as intended in Vim 7.3 on Windows.
> > >
> > > But, if I now understand ; properly, I think that 'Ben;' is actually
> > > saying, "starting in the subdirectory Ben of the current directory,
> > > search upwards". But here in vimfiles/plugin, there IS no subdirectory
> > > called "Ben". So Vim is probably correct to fail.
> > >
> > > ';Ben', on the other hand, tells Vim "starting in the current directory,
> > > seach upwards until you encounter the "Ben" directory. I think this is
> > > what the OP intended.
--
--
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
