quote:

---

> Yes, actually I mentioned that cscope worked fine when used outside
> of gvim.

---

quote:

---

>
> Fred Ma <fma@doe.carleton.ca> wrote:
>
>
> That's not quite the same thing --- cscope works with an internal
> representation of its query results, which is quite unlikely to be
> broken in the way indicated here.
>
> The vim interface, OTOH, relies on the _printed_ representation of
> those results, which you only get to see for yourself if you run
> cscope in -l or -L mode. Possible gotchas here would include line
> breaks or blanks in the wrong places, or anything else that screws up
> the vim interface's parser of cscope line-mode output. Since you
> seemed to imply that the problem only happend sometimes, but not
> reliably, that's why I suggested cscope -ld output as the next thing
> to test. If you're worried about too public an exposure, you can
> still send samples to me by email.
>
> BTW: There is an open bug report from last week, posted anonymously to
> the cscope bug tracker about this, too. Was that you, or somebody
> else? That report mentioned an important additional detail: the
> problem only happened with vim 6.2, but not with 6.0.

---

quote:

---

> I looked at the man page for -l. I'll spend a bit of time playing
> with it. It's probably as you say, some parsing problem with the
> gvim plugin. The matching list shows, but selection of a particular
> match causes gvim to jump to the wrong place. I will look at it
> tomorrow, as I have been up for a long time right now. If it comes
> down to it, would you mind receiving 3 longish files, as well as a
> description of what gvim queries give the wrong jumps?

---

quote:

---

>
> Fred Ma <fma@doe.carleton.ca> wrote:
>
>
> I could reproduce a problem like
> that using cscope's own C source code and VIM 6.1 I found on some
> RedHat box.
>
> A little digging in VIM's CVS repository shows what looks like a patch
> exactly for this problem having been applied to VIM, recently. It's
> revision 1.29 of src/if_cscope.c, checked in September 2003. Indeed,
> plugging that version of this source file into the distributed vim62
> source tarball fixes the problem for me.
>
> The problem is caused by vim trying to move tags in the currently
> viewed file to the top of the list, but forgetting to update the
> internal counts. It's a genuine internal VIM bug, unrelated to the
> cscope output format and VIM's parsing of it. They solved it by
> removing that sorting step entirely.

---

quote:

---

>
> I checked the vim 6.2 patches (and installed gnu patch
> utility, since the solaris patch seems to be unable to
> process the vim patches). I applied the patches in the
> specified vim build directory. The "make" step stops
> with fatal errors, so I untarred the entire vim source
> from the originally downloaded tarball. Then I ran
> configure, applied the patches, and reran "make". Same
> errors. I'll search the vim mailing list before either
> posting to comp.editors or the vim list. Thanks for
> pointing out the patches.

---

quote:

---

>
> I'm not a user of either package so this is strictly a guess, but it
> sure smells like a problem caused by not handling whitespace in
> pathnames correctly (a very common problem). Fred might want to take a
> quick look and see if any of his files have whitespace or other special
> characters.
>
> MB

---