Monday, February 28, 2011

Help debugging autocd-like behavior on startup

I like the fact that the current directory can be local to a given
directory. As such, I wanted to enable a behavior wherein opening a
filename containing '/./' would automatically :lcd to the portion
preceding the '/./'.

Use case:
$ vim -o /path/to/stuff/./app/models/blah.rb /path/to/other/project/./app/models/blee.rb
Then,
:e app/mod<Tab>/<Tab>
in either window will tab-complete filenames only within that project's
app/ subdir.

Unfortunately, at startup with the '-o' option, it seems as though the
act of :lcd'ing in one window (or buffer?) is causing the '/./' portion
of the filename in another window to be lost.

So, a simplified, but tested version of what I'm trying to do:

==> ~/.vim/plugin/dotted-dirs.vim <==
aug DottedLCD
au!
au BufReadPost * call DottedLCD(expand("<afile>"))
aug END

fun! DottedLCD(filename)
let parts = split(a:filename, '/\./')
if len(parts) > 1
echomsg parts[0]
endif
endfun
=====================================

$ mkdir -p /tmp/a/some/long /tmp/b/some/other
$ touch /tmp/a/some/long/directory.txt /tmp/b/some/other/hierarchy.txt
$ vim -o /tmp/a/./some/long/directory.txt /tmp/b/./some/other/hierarchy.txt

:messages
"/tmp/a/./some/long/directory.txt" 0L, 0C
/tmp/a
"/tmp/b/./some/other/hierarchy.txt" 0L, 0C
/tmp/b


But, if the 'echomsg parts[0]' line is changed to:
exe ":lcd ".fnameescape(parts[0])

The first file succeeds (:pwd reports /tmp/a), but the second file
doesn't. And the opened filename is reported in the :messages output
without the '/./':

:messages
"/tmp/a/./some/long/directory.txt" 0L, 0C
"/tmp/b/some/other/hierarchy.txt" 0L, 0C

In my initial attempt at a fix, I tried using BufReadCmd (and cribbing
NETRW's idiom of surrounding an executed ":e" with ":silent doau
BufRead{Pre,Post}"), but had the same issue.

I also tried splitting it into two portions. BufReadPost would setup a
buffer-local variable to hold the correct pre-/./ directory, and then
BufEnter would actually :lcd to that dir. But apparently the BufEnter
happens too quickly or the order isn't sufficiently different to matter.

Does anyone see what's happening? and/or a simple way around this? Is
there some variable that holds the originally-specified filename?

--
Thanks,
Ben

--
You received this message from the "vim_use" 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

No comments:

Post a Comment