On Friday, May 31, 2013 7:42:01 PM UTC+1, Gary Johnson wrote:
> On 2013-05-31, A. S. Budden wrote:
> > Forwarding to vim-dev as requested... any cscope/vim experts here?
>
> Not an expert but a daily user.
>
> > > When using cscope, the path as provided to the "cs add" command is
> > > used. If the working directory changes, this is potentially no longer
> > > valid. This causes me a problem as I have a plugin that tries to
> > > pause cscope and restart it (so it can regenerate cscope.out without
> > > access conflicts). It does this by parsing "cs show" to get the file
> > > name(s) and then doing "cs kill" to pause and "cs add" to restart. If
> > > the working directory has changed, "cs add" fails.
>
> That's a problem with the way your plugin manages the name(s) of the
> cscope database file(s).
That's probably true. In most instances, my plugin works absolutely fine as
it's expected to take over managing cscope connections entirely (i.e. it
handles running cs add and cs kill based on its own internal list). However,
it also tries to leave the state as it was if the user has MANUALLY added
cscope connections and I quickly realised that this didn't work in certain
situations because doing something like this fails:
cd c:/path/to/firstlocation
cs add cscope.out
cd c:/path/to/somewhereelse
" Now the plugin wants to pause stuff
cs kill -1
" This fails as it had no way of getting the original path to cscope.out
cs add cscope.out
> > > I think the fix is relatively simple: make "cs add filename" do the
> > > equivalent of "exe 'cs add' fnamemodify('filename', ':p')", but I
> > > don't know how to do that in Vim's code.
>
> > > An example of the issue can easily be produced with the following
> > > example (on Windows):
> > >
> > > * Create c:\proj1\test1.c with a simple function (I used void test1(void)
> > > { })
> > > * Create c:\proj2\test2.c with another simple function (I used void
> > > test2(void) { })
> > > * In each directory (c:\proj1 and c:\proj2), run "cscope -b" to create
> > > cscope.out
> > >
> > > First attempt (doesn't work):
> > >
> > > gvim -u NONE -U NONE
> > > :cd c:\proj1
> > > :e test1.c
> > > :cs add cscope.out
> > > :vnew
> > > :lcd c:\proj2
> > > :e test2.c
> > > :cs add cscope.out
> > > :cs show
> > > # Only shows one entry: cscope.out
>
> When I do this using vim on Linux (I'm not using X at the moment and
> I don't have cscope for Windows), I see two entries:
>
> # pid database name prepend path
> 0 28267 cscope.out <none>
> 1 28274 cscope.out <none>
>
> If you're seeing only one entry, it may be a bug in the Windows
> version.
Quite possible: I only tested this on Windows. Unfortunately, since there's no
function-type interface to cscope, there's no way of getting the database path
from the above.
> However, if I then execute ":cs reset", ":cs show" shows only one
> entry:
>
> # pid database name prepend path
> 0 28563 cscope.out <none>
That certainly looks wrong.
> It seems to me that Vim ought to resolve and display the cscope
> database files used for cscope connections in the same way it does
> for files being edited. That is, a cscope.out file in the current
> directory would be displayed as "cscope.out" and one in a different
> directory would be displayed as "/path/to/dir/cscope.out". That
> display could change as the current directory changes.
Yes.
> A ":cs reset" would then use a valid path to the database file of
> each connection being reset, rather than just using the file name
> that each connection was started with.
>
> A ":cs show" would also then provide more useful information about
> the file used for each database and might be used as described in
> the first paragraph of the bug report. However, the full path name
> to a database file may not fit in the space allowed in the ":cs
> show" output. Long names should be shorted as is done for the
> ":file" command. Trying to determine the file name by scraping the
> output of ":cs show" would be like trying to determine the name of
> the current file by scraping the output of ":file" and would
> generally not be successful.
Yes, a function interface to allow the details to be retrieved would be really
nice.
> While Vim could provide a list variable or a function for accessing
> the list of cscope connection files, I think it would be acceptable
> to require a plugin to manage this list itself.
Yes, I do this already (as I said above), unfortunately this doesn't help with
manually started cscope connections.
Al
--
--
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.
