On 2006-08-12, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> On 8/12/06, Gary Johnson <[EMAIL PROTECTED]> wrote:
> > I just finished troubleshooting a problem that had several
> > contributing factors, one of which was the way Vim's mch_FullName()
> > function behaves with ClearCase versioned file names.
> >
> > If you open a file under ClearCase using the full path name and a
> > version extension, e.g.,
> >
> > /project/xyz/system/src/bar.c@@/main/42
> >
> > Vim will ask mch_FullName() for the full name of that file.
> > mch_FullName() will then extract everything to the left of the last
> > '/' as the directory containing the file and chdir() to that
> > directory, e.g.,
> >
> > chdir("/project/xyz/system/src/bar.c@@/main")
> >
> > mch_FullName() then calls getcwd() to determine the operating
> > system's name for that directory, which from ClearCase is
> >
> > /view/garyjohn_main@@/project/xyz/system/main/5/src/main/2/bar.c/main
> >
> > mch_FullName() then puts back the trailing "file name" of "42" in
> > this case and returns the full file name as
> >
> > /view/garyjohn_main@@/project/xyz/system/main/5/src/main/2/bar.c/main/42
> >
> > This is the name that is then given to the buffer used for that file
> > and which appears in the status line.
> >
> > This is a valid file name which points to the correct file and works
> > with most external commands. However, it does not work with those
> > external commands or Vim autocommands whose behavior depend on the
> > file name suffix. It's also really ugly in the status line.
>
> How about using a symlink ?
That would work. It could be messy figuring out where to put it
where its name would be unique, but not impossible.
> Regarding statusline, you can use custom statusline
> and replace %f to %{MyFilename()} which knows to handle @@.
Good idea. There's even a ClearCase command that can convert from
one form of the file name to another.
On 2006-08-12, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> On 8/12/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> > On 8/12/06, Gary Johnson <[EMAIL PROTECTED]> > > If you open a file
> > under ClearCase using the full path name and a
> > > version extension, e.g.,
> > >
> > > /project/xyz/system/src/bar.c@@/main/42
>
> If I'm not mistaken, 42 is version name here, and your problem is that
> such pathname does not have .c extension.
>
> How about creating "automatic" symlinks: have autocommand autocreate
> symlinks these lines:
>
> :au BufNew /project/xyz/system/src/*.v*.c :!ver=`basename <afile> .c
> | sed 's/^.*\.v//'`; base=`basename <afile> .c | sed
> 's/\.v[0-9]*\$//`; ln -s /project/xyz/system/src/\$base.c@@/main/\$ver
> <afile>
>
> This is untested, but the idea is that when you open
>
> % vim bar.v42.c
>
> the proper symlink is automatically created to version
> 42 of bar.c This solves the problem of proper extension
> and of ugly @@ filenames.
Hmm. That could work. Thanks.
One of the situations in which I've had trouble giving a
properly-extended file name to an external program is when I've used
the ClearCase Vtree Browser to select a C file to opened in Vim,
then tried to run 'lint' on the file. In that case, I could modify
my :Lint command to create a temporary file with the proper suffix,
either as a copy of the file in the Vim buffer or as a symbolic link
from the ClearCase file as in your suggestion.
I've also come up with a solution for part of the problem, that of
Vim's insistence on converting a name like
/project/xyz/system/src/bar.c@@/main/42
(through chdir() and getcwd()) to a name like
/view/garyjohn_main@@/project/xyz/system/main/5/src/main/2/bar.c/main
Using the following autocommand seems to fix that by restoring the
original file name. I thought I had tried this solution before and
it didn't work, but it seems to work now, so I must have had
something set differently before.
au VimEnter /view/*@@/* silent windo
\ exe 'file' system('cleartool des -short -cview "'.expand("%").'"')
The windo command covers the case where vim was invoked as vimdiff
to compare two ClearCase versions.
Thanks again,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
