Navigating complicated file hierarchies

12 views
Skip to first unread message

Per Thulin

unread,
Jan 5, 2009, 6:01:54 AM1/5/09
to v...@vim.org
Hello fellow vim users!

I use vim for all my coding and text editing needs. Until now I've
only used it for small projects with all files in a single folder,
nothing complicated. However, my current job involves a lot of jumping
around between files in very different file hierarchies, copying
pasting etc. I've tried a few different strategies:

1. Use bash to jump around in the system and open/close new Vim
instances when I need to edit something. This makes it easy to
navigate the file system but doesn't work when I need to copy/paste
content from e.g. /foo/b/c/d.txt to /bar/a/b/c/d.txt, as I need both
these files open in the same vim instance, and to open those files as
absolute paths is a PITA.

2. Have one Vim instance and use :Ex to navigate the file system. The
biggest problem with this setup though is that when I've navigated to
a different folder, I can't use :e to open a new file in this same
folder because the working directory that :e looks at isn't affected.

I think the best solution for me would be if there was a way to have
multiple terminals where I can use bash and vim however I choose, but
copy/paste content freely between them. I have no problems with
multiple windows, just need to be able to copy/paste.

So my question is: how do you manage long file hierarchies in vim? I
know it's possible because I've heard about very skilled developers
doing the same work as I do entirely in vim.

Thanks!
-Per Thulin

wormi...@gmail.com

unread,
Jan 5, 2009, 2:25:56 PM1/5/09
to vim...@googlegroups.com

When this comes up for me, I generally use the NERD tree plugin.

There is, iir, method to make vims buffers global among all active vim sessions, but I do not recall the specifics.

Thanks,
Chris
Sent via BlackBerry from T-Mobile

-----Original Message-----
From: "Per Thulin" <per.t...@valentinewebsystems.se>

Date: Mon, 5 Jan 2009 12:01:54
To: <v...@vim.org>
Subject: Navigating complicated file hierarchies

_sc_

unread,
Jan 5, 2009, 2:29:22 PM1/5/09
to vim...@googlegroups.com
On Monday 05 January 2009 5:01 am, Per Thulin wrote:

as i attempt to respond to this post no-one else has yet
posted a reply -- i am sure this will change, and others'
replies may be more to your liking, but here goes

> I use vim for all my coding and text editing needs. Until now I've
> only used it for small projects with all files in a single folder,
> nothing complicated. However, my current job involves a lot of jumping
> around between files in very different file hierarchies, copying
> pasting etc. I've tried a few different strategies:
>
> 1. Use bash to jump around in the system and open/close new Vim
> instances when I need to edit something. This makes it easy to
> navigate the file system but doesn't work when I need to copy/paste
> content from e.g. /foo/b/c/d.txt to /bar/a/b/c/d.txt, as I need both
> these files open in the same vim instance, and to open those files as
> absolute paths is a PITA.

wait -- stop right there -- why do you believe they have to
be open in the same vim instance? was your vim compiled
without +clipboard? (:ver will tell you)

if you have the benefit of konsole supplying your bash
shell, you can have many shells open in the same window,
each with its own path -- ctrl-shift-n will open new shells,
and shift-cursor-left or shift-cursor-right will navigate
around in them

a yank to clipboard is as easy as prefacing your yank with
"+ (double quote plus) -- for example

"+7yy

will yank 7 lines beginning with the current line into the
clipboard -- toggle to your target window, and

"+p

will paste them there

> 2. Have one Vim instance and use :Ex to navigate the file system. The
> biggest problem with this setup though is that when I've navigated to
> a different folder, I can't use :e to open a new file in this same
> folder because the working directory that :e looks at isn't affected.

with ':set autochdir' the current directory will
automatically be set to the path of whatever module becomes
current

> I think the best solution for me would be if there was a way to have
> multiple terminals where I can use bash and vim however I choose, but
> copy/paste content freely between them. I have no problems with
> multiple windows, just need to be able to copy/paste.
>
> So my question is: how do you manage long file hierarchies in vim? I
> know it's possible because I've heard about very skilled developers
> doing the same work as I do entirely in vim.

my favorite method is to have many bash shells open in a
single konsole window -- i have aliases set up in my
~/.bashrc to make getting to my favorite directories easy,
for example

alias cd7='cd ~/.build/vim'

allows me to quickly cd to my vim build directory by typing
cd7<enter>

i've gotten away from navigating directories using :Explore
due to some as yet unresolved bugs in the netrw script which
cause changes in settings in other open buffers (very
unsettling)

hth,

sc

Gene Kwiecinski

unread,
Jan 5, 2009, 2:31:56 PM1/5/09
to vim...@googlegroups.com
>1. Use bash to jump around in the system and open/close new Vim
>instances when I need to edit something. This makes it easy to
>navigate the file system but doesn't work when I need to copy/paste
>content from e.g. /foo/b/c/d.txt to /bar/a/b/c/d.txt, as I need both
>these files open in the same vim instance, and to open those files as

I do that all the time when editing my html/js stuff, as I have a main
"index" page with a bunch of dirs hanging off it, with the 'index.html'
file referencing each one, and one 'common' dir for js
function-libraries, common .css files (to maintain the same
"look'n'feel"), etc.

When I want to c&p something in a file I'm editing, I just 'cd' to the
dir where the source file lives, 'vim' the file, then use the clipboard
to hijack whatever code I need and paste it to the target file I'm
editing. No need to have the same 'vim' instance.

Your clipboard broken somehow that this doesn't work?

Reid Thompson

unread,
Jan 5, 2009, 2:36:55 PM1/5/09
to vim...@googlegroups.com, v...@vim.org

Reid Thompson

unread,
Jan 5, 2009, 2:36:55 PM1/5/09
to vim...@googlegroups.com, v...@vim.org
On Mon, 2009-01-05 at 12:01 +0100, Per Thulin wrote:
http://www.vim.org/scripts/script.php?script_id=95

Tom Link

unread,
Jan 5, 2009, 2:47:06 PM1/5/09
to vim_use
> So my question is: how do you manage long file hierarchies in vim?

If those files belong to a project, I'd suggest to use one of the
related plugins for project management. For obvious reasons, I'm
partial to tselectfiles. In general, people recommend project.vim[2]

You didn't tell us which files (filetype) you work with.

[1] http://www.vim.org/scripts/script.php?script_id=1865
[2] http://www.vim.org/scripts/script.php?script_id=69

Charles Campbell

unread,
Jan 5, 2009, 3:12:13 PM1/5/09
to vim...@googlegroups.com
Per Thulin wrote:
> Hello fellow vim users!
>
> I use vim for all my coding and text editing needs. Until now I've
> only used it for small projects with all files in a single folder,
> nothing complicated. However, my current job involves a lot of jumping
> around between files in very different file hierarchies, copying
> pasting etc. I've tried a few different strategies:
>
> 1. Use bash to jump around in the system and open/close new Vim
> instances when I need to edit something. This makes it easy to
> navigate the file system but doesn't work when I need to copy/paste
> content from e.g. /foo/b/c/d.txt to /bar/a/b/c/d.txt, as I need both
> these files open in the same vim instance, and to open those files as
> absolute paths is a PITA.
>
> 2. Have one Vim instance and use :Ex to navigate the file system. The
> biggest problem with this setup though is that when I've navigated to
> a different folder, I can't use :e to open a new file in this same
> folder because the working directory that :e looks at isn't affected.
>

This "feature" is something netrw has to emulate the previous file
explorer's behavior.
I don't like it myself, and caught grief about it when netrw didn't have
that behavior
as its default. Anyway, the fix is simple; put

let g:netrw_keepdir= 0

into your .vimrc.


> I think the best solution for me would be if there was a way to have
> multiple terminals where I can use bash and vim however I choose, but
> copy/paste content freely between them. I have no problems with
> multiple windows, just need to be able to copy/paste.
>
> So my question is: how do you manage long file hierarchies in vim? I
> know it's possible because I've heard about very skilled developers
> doing the same work as I do entirely in vim.
>

You can have multiple windows with netrw running in several. You can
use the
marked-file-(copy|move) capability to copy/move the file(s). See

:help netrw-mf
:help netrw-mc
:help netrw-mm

Regards,
Chip Campbell

_sc_

unread,
Jan 5, 2009, 8:38:06 PM1/5/09
to vim...@googlegroups.com
On Monday 05 January 2009 1:29 pm, _sc_ wrote:
> if you have the benefit of konsole supplying your bash
> shell, you can have many shells open in the same window,
> each with its own path -- ctrl-shift-n will open new shells,
> and shift-cursor-left or shift-cursor-right will navigate
> around in them

oops i lied -- that should read 'ctrl-alt-n'

and if you want to get fancy and help yourself out when you
open a lot of these, you can name them with ctrl-alt-s

sc


Tony Mechelynck

unread,
Jan 5, 2009, 11:40:25 PM1/5/09
to vim...@googlegroups.com, v...@vim.org

There are several methods depending on your exact needs and procedures.

For the kind of use-case described above, I think that I would use
split-windows in one Vim instance (probably gvim but YMMV), with
different local directories in different windows thanks to the ":lcd"
command.

Another possibility would be several bash sessions in an X terminal (for
instance, a konsole window with several tabs, one bash instance in each
tab), and one (or more) gvim session(s), possibly with split-windows as
above, pasting from one (bash or gvim) X window to another by means of
the clipboard.

If you don't have KDE or maybe even X11 installed, you might check the
manual for the "screen" command to open several simulaneous bash
instances in a single console. I don't use it myself but I've heard much
praise of it by those who use it. (If you have X and Gnome but not KDE,
check the capabilities of the gnome-terminal program: I know the name
but not the details. If you use the Gnome winmanager but have KDE also
installed, you can run any KDE application, including konsole, under Gnome.)


Best regards,
Tony.
--
"The Army is a place where you get up early in the morning to be yelled
at by people with short haircuts and tiny brains."
-- Dave Barry

Tony Mechelynck

unread,
Jan 6, 2009, 12:21:20 AM1/6/09
to vim...@googlegroups.com, v...@vim.org
On 05/01/09 20:36, Reid Thompson wrote:
[...]
>
> http://www.vim.org/scripts/script.php?script_id=95
>

I notice that the screenshot link on that page is 404 not found (I
didn't try the other links), and the author's email bounces (User unknown).


Best regards,
Tony.
--
The goal of science is to build better mousetraps. The goal of nature
is to build better mice.

Ryan Phillips

unread,
Jan 6, 2009, 12:23:39 AM1/6/09
to vim...@googlegroups.com, v...@vim.org, Per Thulin
Tony Mechelynck <antoine.m...@gmail.com> said:
>
> There are several methods depending on your exact needs and procedures.
>
> For the kind of use-case described above, I think that I would use
> split-windows in one Vim instance (probably gvim but YMMV), with
> different local directories in different windows thanks to the ":lcd"
> command.
>
> Another possibility would be several bash sessions in an X terminal (for
> instance, a konsole window with several tabs, one bash instance in each
> tab), and one (or more) gvim session(s), possibly with split-windows as
> above, pasting from one (bash or gvim) X window to another by means of
> the clipboard.
>
> If you don't have KDE or maybe even X11 installed, you might check the
> manual for the "screen" command to open several simulaneous bash
> instances in a single console. I don't use it myself but I've heard much
> praise of it by those who use it. (If you have X and Gnome but not KDE,
> check the capabilities of the gnome-terminal program: I know the name
> but not the details. If you use the Gnome winmanager but have KDE also
> installed, you can run any KDE application, including konsole, under Gnome.)

In addition to excellent Tony's reply, you might want to try the
fuzzyfinder plugin. It may help navigate directories a bit easier.

-Ryan

Per Thulin

unread,
Jan 6, 2009, 2:34:23 AM1/6/09
to vim...@googlegroups.com

Tony Mechelynck

unread,
Jan 6, 2009, 2:55:11 AM1/6/09
to per.t...@valentinewebsystems.se, vim...@googlegroups.com

This is the second copy of a post; the first one was posted 20 hours ago
and got a lot of replies in that time. Please read them.

Regards,
Tony.
--
ARTHUR: Be quiet!
DENNIS: Well you can't expect to wield supreme executive power just 'cause
some watery tart threw a sword at you!
ARTHUR: Shut up!
DENNIS: I mean, if I went around sayin' I was an empereror just because
some
moistened bint had lobbed a scimitar at me they'd put me away!
The Quest for the Holy Grail (Monty
Python)

Per Thulin

unread,
Jan 6, 2009, 4:06:32 AM1/6/09
to v...@vim.org
Thanks guys, I did not expect this much response and your answers have
been very helpful!

Someone asked me about which filetypes I work with and which terminal
application and desktop environment I'm using. I'm mostly editing
python source code and xml files, so I use vims indentation and syntax
highlighting support there. My work environment differs a lot, so my
workflow has to be independant of it. On my home desktop I use Ubuntu
(GNOME, gnome-terminal), home laptop is Kubuntu (KDE 4.1, Konsole) and
work machine is a Mac with the built in Mac terminal application.

I've had bad experience with using the systems clipboard as the
resulting text often get very weird indentation (don't know if this is
because of vim indenting the incoming text, or something else). Also
the "+ shortcut is a little tricky to type, especially on a swedish
keyboard. Another problem I run into with multiple vim sessions is
that I often try to open the same file and get conflicting swap files,
but this is probably just a matter of changing my own bad habits of
leaving files and sessions open.

Also I didn't realise that vim had such helpful plugins, I'll look
into them in the evening and get back with my results here.

Thanks again,
Per Thulin

John Beckett

unread,
Jan 6, 2009, 4:32:18 AM1/6/09
to vim...@googlegroups.com
Per Thulin wrote:
> I've had bad experience with using the systems clipboard as
> the resulting text often get very weird indentation

If you are pasting into console/terminal Vim (not gvim), see:
http://vim.wikia.com/wiki/Toggle_auto-indenting_for_code_paste

BTW it would be really easy for someone to review that tip (i.e. confirm
that it's ok for current Vim, and remove the {{review}} line).

John

Tony Mechelynck

unread,
Jan 6, 2009, 4:37:55 AM1/6/09
to vim...@googlegroups.com, v...@vim.org

Weird indentation when pasting can often be avoided by an appropriate
use of the 'paste' option.

Best regards,
Tony.
--
Millions of sensible people are too high-minded to concede that
politics is almost always the choice of the lesser evil. "Tweedledum
and Tweedledee," they say, "I will not vote." Having abstained, they
are presented with a President who appoints the people who are going to
rummage around in their lives for the next four years. Consider all
the people who sat home in a stew in 1968 rather than vote for Hubert
Humphrey. They showed Humphrey. Those people who taught Hubert
Humphrey a lesson will still be enjoying the Nixon Supreme Court when
Tricia and Julie begin to find silver threads among the gold and the
black.
-- Russel Baker, "Ford without Flummery"

Tony Mechelynck

unread,
Jan 6, 2009, 4:37:55 AM1/6/09
to vim...@googlegroups.com, v...@vim.org
On 06/01/09 10:06, Per Thulin wrote:

Weird indentation when pasting can often be avoided by an appropriate

beaufabry

unread,
Jan 6, 2009, 4:48:45 AM1/6/09
to vim_use
> When this comes up for me, I generally use the NERD tree plugin.
>
> There is, iir, method to make vims buffers global among all active vim sessions, but I do not recall the specifics.
>
> Thanks,
>     Chris

Can't recommend the NERDtree plugin enough, means the entire coding
side of my development
process sits in a single gvim session, which makes fuzzyfinderbuffer
and split windows also very useful.

Also useful to couple the plugin with this in your .vimrc:

map <leader>d :execute 'NERDTreeToggle ' . getcwd()<CR>

In command mode this allows you to toggle the NERDTree browser on/off
with two keystrokes.

Marc Weber

unread,
Jan 6, 2009, 8:32:49 AM1/6/09
to vim...@googlegroups.com, v...@vim.org
I use glob open plugin and MRU.

I think glob open is similar to the fuzzy finder plugin. However you can
still apply black and white filters and the first search result to find
the file you're looking for faster.

Navigating files can be done in many ways. You didn't tell us the most
important thing: How do you know which file you want to edit?

Example:

In the nix language there is an import statement:
import ../dir/dir/file.nix

In this case I've written a small script so that I can press fg on that
line opening that file. In contrast to the default gf it does also open
it if it doesn't yet exist.

If you're looking for a file which contains 'foobar' you should either
use grep or idutils or generate tags or such. This will be fastest.

To get an idea about what can be found within a directory I usually do
find | vim -
Then you can press gf to open the files easily..

So this really depends on how you figure out which file you want to
open!

Sincerly
Marc Weber

Marc Weber

unread,
Jan 6, 2009, 8:32:49 AM1/6/09
to vim...@googlegroups.com, v...@vim.org

Per Thulin

unread,
Jan 8, 2009, 3:08:27 AM1/8/09
to vim...@googlegroups.com, Marc Weber, v...@vim.org
First of all, that gf command is awesome, didn't know about it! Thanks!

> Navigating files can be done in many ways. You didn't tell us the most
> important thing: How do you know which file you want to edit?

Well in python there are import statements, but they don't
necessariliy match file system paths. Maybe there's a script available
to follow an import statement using the environment variable
PYTHONPATH or something.

Thanks,
Per Thulin

John Beckett

unread,
Jan 8, 2009, 3:19:46 AM1/8/09
to vim...@googlegroups.com
Per Thulin wrote:
> Well in python there are import statements, but they don't
> necessariliy match file system paths. Maybe there's a script
> available to follow an import statement using the environment
> variable PYTHONPATH or something.

We have a tip:
http://vim.wikia.com/wiki/Automatically_add_Python_paths_to_Vim_path

John

itai

unread,
Jan 8, 2009, 2:19:42 PM1/8/09
to vim_use
(This is my first post in this group!)

Some notes you might find helpful:

1. I'd like to second whoever recommended GNU screen. It's great, and
you should learn to use it. Note that screen has its own virtual
terminal copy and paste functionality, which is occasionally useful.

2. As far as entering a file's path is concerned, are you familiar
with wildmenu? Try ":set wildmenu". You might like it.

3. Use the X clipboard register ('*'). This will allow you to yank and
paste from one vim instance to another. It will also assist you in
integrating vim and your working environment (for instance, you'll be
able to yank text to and from Firefox).

If you'd like to use this register by default, add the following (or
something similar) to your .vimrc:
set clipboard=autoselect,unnamed

You might also like:
inoremap <C-v> <C-r>*
cnoremap <C-v> <C-r>*

(See http://vim.wikia.com/wiki/Accessing_the_system_clipboard .)

4. The vim help files seem to recommend against using 'autuchdir'. I
use the following:
autocmd BufEnter * lcd %:p:h

(See http://vim.wikia.com/wiki/Set_working_directory_to_the_current_file
.)

Also, NERD tree (as others have said) is very good.

Hope this helps.

On Jan 5, 1:01 pm, "Per Thulin" <per.thu...@valentinewebsystems.se>
wrote:

John Beckett

unread,
Jan 8, 2009, 5:06:50 PM1/8/09
to vim...@googlegroups.com
itai wrote:
> (This is my first post in this group!)

Welcome, and thanks for the informative message.

For the future, please "bottom post". That is, quote a *small* relevant
part of the message you are replying to, then put your reply underneath.

I am periodically spraying the above advice in an effort to restore the
convention established by old timers here.

John

Per Thulin

unread,
Jan 13, 2009, 10:22:19 AM1/13/09
to itai, vim...@googlegroups.com
On 8 jan 2009, at 20.19, itai wrote:
> (This is my first post in this group!)

Welcome!

> 1. I'd like to second whoever recommended GNU screen. It's great, and
> you should learn to use it. Note that screen has its own virtual
> terminal copy and paste functionality, which is occasionally useful.

Yes, sometimes it's useful, but I'd rather use vims own clipboard
functionality due to its tighter integration. It would be very useful
if there was some vim/screen integration so that I could select text
with vim, yank it so that it would end up in screens clipboard, then
paste it in another vim session.

> 3. Use the X clipboard register ('*'). This will allow you to yank and
> paste from one vim instance to another. It will also assist you in
> integrating vim and your working environment (for instance, you'll be
> able to yank text to and from Firefox).

Can't use X since my workflow has to work on OSX as well. I don't want
to run an X server for this.

> 4. The vim help files seem to recommend against using 'autuchdir'. I
> use the following:
> autocmd BufEnter * lcd %:p:h
>
> (See http://vim.wikia.com/wiki/Set_working_directory_to_the_current_file
> .)

Wow, thanks! I've been looking exactly for this!

> Also, NERD tree (as others have said) is very good.

I've been using NERDTree for some days now, and while I'm very
impressed with it (I really like the bookmarks functionality, and the
keyboard bindings are the best I've ever come across), it doesn't fit
my working style. It reminds me too much of why I moved away from
IDEs. For what I do, nothing beats bash for navigating the filesystem,
using find, grep awk etc to get the files I want. I really want just
one window that displays my current task.

One simple little integration thing that would fix it all would be if
could do this:

1. From vim, run :shell
2. Find the files I'm after
3. Open these in the vim session I ran :shell from.

Hold your hats now, but Emacs users can do this. From Emacs they do
the equivalent of running :shell, then navigate to another directory
which becomes Emacs working directory. Now they can do the equivalent
of :e <some file in that directory>.

Thanks!
-Per Thulin

Itai Fiat

unread,
Jan 13, 2009, 11:51:30 AM1/13/09
to Per Thulin, vim...@googlegroups.com
On Tue, Jan 13, 2009 at 17:22, Per Thulin
<per.t...@valentinewebsystems.se> wrote:

> One simple little integration thing that would fix it all would be if could
> do this:
>
> 1. From vim, run :shell
> 2. Find the files I'm after
> 3. Open these in the vim session I ran :shell from.
>
> Hold your hats now, but Emacs users can do this. From Emacs they do the
> equivalent of running :shell, then navigate to another directory which
> becomes Emacs working directory. Now they can do the equivalent of :e <some
> file in that directory>.
>
> Thanks!
> -Per Thulin

This sound incredibly useful. This idea has never occurred to me, but it is
really good, and I will use it. Below you will find my take on how to achieve
this. There is probably much room for improvement.

(Important note: You mentioned you also use OS X. Well, sorry. I don't know
whether this will work. It does on Linux.)

1.

Create a bash file called "choose" (say, in your ~/bin), and enter the
following:

#!/bin/bash

for filename in $*
do
echo `readlink -f $filename` >> /tmp/vim_choose_files
done

2.

Add the folowing to your .vimrc:

function s:ShellChoose ()
call system("rm -f /tmp/vim_choose_files")
shell
let l:files=system("cat /tmp/vim_choose_files")
if !v:shell_error
let l:files=substitute(l:files, "\n", " ", "g")
exec "argadd ".files
endif
endfunction

command -nargs=0 Shell call s:ShellChoose()

3.

Use.

Usage instructions:

a. Use ":Shell" instead of ":shell".
b. Go to any directory, and choose files you would like to edit using the
"choose" bash script.

Examples:

choose a.txt
choose *.txt

You don't have to choose all files at once.
c. When you <C-d> your way back to vim, the files you've chosen will be added to
the argument list.

Itai Fiat

unread,
Jan 13, 2009, 12:09:15 PM1/13/09
to Per Thulin, vim...@googlegroups.com
On Tue, Jan 13, 2009 at 18:51, Itai Fiat <itai...@gmail.com> wrote:

> On Tue, Jan 13, 2009 at 17:22, Per Thulin
> <per.t...@valentinewebsystems.se> wrote:
>>
>> 1. From vim, run :shell
>> 2. Find the files I'm after
>> 3. Open these in the vim session I ran :shell from.
>

> This sound incredibly useful. This idea has never occurred to me, but it is
> really good, and I will use it. Below you will find my take on how to achieve
> this. There is probably much room for improvement.

Improvement the first:

Bash file (~/bin/choose)
------------------------

#!/bin/bash

for filename in $*
do

echo `readlink -f $filename` >> ~/.vim/chosen_files
done


.vimrc
------

function s:ShellChoose ()
call system("rm -f ~/.vim/chosen_files")
shell
if !filereadable(expand("~/.vim/chosen_files"))
return
endif
let l:files=system("cat ~/.vim/chosen_files")


let l:files=substitute(l:files, "\n", " ", "g")
exec "argadd ".files

endfunction

command -nargs=0 -bang Shell call s:ShellChoose()

Antony Scriven

unread,
Jan 13, 2009, 6:50:25 PM1/13/09
to vim...@googlegroups.com
On Tue, Jan 13, 2009 at 3:22 PM, Per Thulin
<per.t...@valentinewebsystems.se> wrote:

> [...]


>
> One simple little integration thing that would fix it all
> would be if could do this:
>
> 1. From vim, run :shell
> 2. Find the files I'm after
> 3. Open these in the vim session I ran :shell from.
>
> Hold your hats now, but Emacs users can do this. From
> Emacs they do the equivalent of running :shell, then
> navigate to another directory which becomes Emacs working
> directory. Now they can do the equivalent of :e <some
> file in that directory>.

If you have a client-server enabled vim:

$ vim --servername VIM1
:shell " or <C-Z>
$ cd ~/tmp
$ vim --servername VIM1 --remote *.txt; exit # or fg

Or, from any shell to any vim:

$ >~/.x; for f in *.txt ; do >>~/.x readlink -f $f; done
$ vim
:for f in readfile(expand('~/.x')) | exe 'argadd' f | endfor

This is essentially what Itai Fiat does elsethread, but you can
do this in any shell and read the files into any vim instance.

Or, like your emacs example:

$ >~/.x pwd
$ vim
:cd readfile(expand('~/.x'))[0] | e.

You don't even need to script this last one: the shell
command is easy enough to type and you can get the vim
command from your history, e.g. :cd r<up> --Antony

Antony Scriven

unread,
Jan 13, 2009, 6:54:16 PM1/13/09
to vim...@googlegroups.com
On Tue, Jan 13, 2009 at 11:50 PM, Antony Scriven
<adsc...@gmail.com> wrote:

> On Tue, Jan 13, 2009 at 3:22 PM, Per Thulin
> <per.t...@valentinewebsystems.se> wrote:
>
> > [...]
> >
> > One simple little integration thing that would fix it all
> > would be if could do this:
> >
> > 1. From vim, run :shell
> > 2. Find the files I'm after
> > 3. Open these in the vim session I ran :shell from.
> >

> > [...]


>
> $>~/.x pwd
> $ vim
> :cd readfile(expand('~/.x'))[0] | e.

Oops, I meant :exe 'cd' readfile(expand('~/.x'))[0] | e.

> You don't even need to script this last one: the shell
> command is easy enough to type and you can get the vim
> command from your history, e.g. :cd r<up> --Antony

And, similarly, :exe <up> --Antony

Eduard

unread,
Jan 20, 2009, 11:12:48 AM1/20/09
to vim...@googlegroups.com
On Tue, Jan 13, 2009 at 07:09:15PM +0200, Itai Fiat wrote:

> On Tue, Jan 13, 2009 at 18:51, Itai Fiat <itai...@gmail.com> wrote:

> >> 1. From vim, run :shell
> >> 2. Find the files I'm after
> >> 3. Open these in the vim session I ran :shell from.

> > This sound incredibly useful. This idea has never occurred to me, but it is
> > really good, and I will use it. Below you will find my take on how to achieve
> > this. There is probably much room for improvement.
>
> Improvement the first:

Itai, thank you very much! Your function is wonderful, something I had
always wanted to do inside Vim.

--
Eduard Fabra.

Ben Fritz

unread,
Jan 20, 2009, 1:03:55 PM1/20/09
to vim_use
On Jan 8, 1:19 pm, itai <itai.f...@gmail.com> wrote:

> 4. The vim help files seem to recommend against using 'autuchdir'. I
> use the following:
>     autocmd BufEnter * lcd %:p:h
>
> (Seehttp://vim.wikia.com/wiki/Set_working_directory_to_the_current_file
> .)
>

Regarding 'autochdir'...why is it that the help files recommend
against using it?

And, do you really save anything by using the autocmd version that
basically does exactly the same thing?

I'd like to update the tip linked by itai to put more emphasis on
'autochdir' but I don't know whath the consequences would be.

I've been using autochdir...the only broken thing I've noticed is
saving and restoring sessions (neither of which works properly when
autochdir is on, but I actually think the autocmd would be worse with
no easy way to disable it).

Tom Link

unread,
Jan 20, 2009, 1:24:54 PM1/20/09
to vim_use
> I've been using autochdir...the only broken thing I've noticed is
> saving and restoring sessions

The same here. I don't think it will break too many other plugins
since without that option you cannot make any assumptions about the
current directory anyway. The autocommand is probably worse because a
plugin couldn't test whether it's enabled.

Matt Wozniski

unread,
Jan 20, 2009, 1:37:26 PM1/20/09
to vim...@googlegroups.com
On Tue, Jan 20, 2009 at 1:03 PM, Ben Fritz wrote:

>
> On Jan 8, 1:19 pm, itai wrote:
>
>> 4. The vim help files seem to recommend against using 'autuchdir'. I
>> use the following:
>> autocmd BufEnter * lcd %:p:h
>
> Regarding 'autochdir'...why is it that the help files recommend
> against using it?
>
> And, do you really save anything by using the autocmd version that
> basically does exactly the same thing?

I think the biggest problem with :set autochdir is that it fires too
often. The autocmd version, since it doesn't have nested, doesn't
fire when a plugin switches buffers through an autocmd, and the
autochdir option does.

> I'd like to update the tip linked by itai to put more emphasis on
> 'autochdir' but I don't know whath the consequences would be.
>
> I've been using autochdir...the only broken thing I've noticed is
> saving and restoring sessions (neither of which works properly when
> autochdir is on, but I actually think the autocmd would be worse with
> no easy way to disable it).

But, like I said - vim itself disables it during autocmds, which is
presumably why it's always behaved better for me. I did try out
autochdir when the option was added, but I switched back to the
autocmd when I found out it behaved better.

~Matt

Agathoklis D. Hatzimanikas

unread,
Jan 20, 2009, 1:59:17 PM1/20/09
to vim...@googlegroups.com

Right, the autocommand is probably worse, as a matter of fact, exactly
this breakage occurred to me last week while running a script.
When I (finally) figure out the reason of the failure, I had to place an
awful 'if' statement to check for a global variable (which I am not very
fond of them) to run the autocommand or not.
I've read the docs and I wasn't sure if it was for better to use 'autochdir'
or not and because I didn't have enough time to test it, I postponed the
transition.
So thanks for posting your experiences. Checking for 'autochdir' is
easy so I believe is more safe to use, it just requires by the script
writers to check for that option.

Regards,
Ag.

_sc_

unread,
Jan 20, 2009, 10:19:56 PM1/20/09
to vim...@googlegroups.com

netrw recently had an issue with 'autochdir' that it did not
have with the autocmd -- the issue's been fixed, but i
remain leary of 'autochdir'

sc

Ben Fritz

unread,
Jan 21, 2009, 11:20:27 AM1/21/09
to vim_use
I've updated the tip mentioned to include more emphasis on
'autochdir':

http://vim.wikia.com/wiki/Set_working_directory_to_the_current_file

I tried to incorporate our discussion about 'autochdir' and the
autocmd mentioned to do the same. Are there any concerns I missed? I'd
like the "Caveats" section to include any common plugins that are
actually known to fail with either of these methods, so if you know
any, bring 'em on!

Nicolas Aggelidis

unread,
Jan 23, 2009, 8:12:00 AM1/23/09
to vim...@googlegroups.com, itai
> Hold your hats now, but Emacs users can do this. From Emacs they do
> the equivalent of running :shell, then navigate to another directory
> which becomes Emacs working directory. Now they can do the equivalent
> of :e <some file in that directory>.
>
> Thanks!
> -Per Thulin

hi Per,

i had the same need as you, and indeed emacs users with shell mode and
dired have everything! but (because i don't like the editing-part of
emacs) i used the
vtreeexplorer plugin plus autochdir... so now i fire up vtreeexplore
and use 't' to open files in new tabs or 'o' to open them in the same
window....

Another mechanism i use to navigate file hierarchies is ctags and
lookupfile plugin....

Yet another mechanism: for the times i needed to edit files that
contained certain words, i had the following script:

echo "Searching folder $PWD:"
#find $PWD -type f \( -path '*/lib/*' \) \
files_temp=$( find $PWD -type f \( \! -path '*/.svn/*' -a \! -path
'*/Logs/*' \) \
-exec grep --color=always --ignore-case --files-with-matches "$@" {} + )

echo ""

oldPS3=$PS3
PS3='edit file: '

files="$files_temp Cancel"

select selection in $files; do
if [ "$selection" == "Cancel" ]; then
echo "user canceled"
break
elif [ $selection ]; then
gvim "$selection"
break
else
echo 'invalid selection.'
fi
done

PS3=$oldPS3

Charles Campbell

unread,
Jan 23, 2009, 9:32:52 AM1/23/09
to vim...@googlegroups.com
Per Thulin wrote:
> Hello fellow vim users!
> [snip]

> 2. Have one Vim instance and use :Ex to navigate the file system. The
> biggest problem with this setup though is that when I've navigated to
> a different folder, I can't use :e to open a new file in this same
> folder because the working directory that :e looks at isn't affected.
>
[snip]

Try putting

let g:netrw_keepdir= 0

in your .vimrc before using :Explore (I do). The reason for the
behavior -- its what the v6 file explorer did, not that I'm particularly
enamored of it.

Regards,
Chip Campbell

Reply all
Reply to author
Forward
0 new messages