#25 Text search results invisible

closed-invalid
nobody
None
5
2011-06-12
2010-04-01
No

Hi,

I'm using Cscope 15.7a in a gnome terminal window on Ubuntu 9.10. Cscope is an amazing tool; whenever I need to understand a larger codebase it's the first tool I go to.

However, there's one problem that I've seen for quite a while and I can't seem to find a solution.

When searching for a text string or an egrep pattern, many of the matches are invisible. They're there, I can move the cursor from line to line and select them and in Vi they display correctly, but the match line has no content. No text. Sometimes some of the matches show and others not.

While googling for a solution I found that other people have the same problem. I tried running in RXVT instead of gnome-term but got the exact same results.

Any clues?

Cheers,

Mattis

Discussion

1 2 > >> (Page 1 of 2)
  • The most common reason by far for that kind of problem are source file with broken (wrong-platform) line-breaks. Compilers may accept them, but cscope doesn't.

     
    • status: open --> pending-later
     
    • status: pending-later --> open-later
     
  • broeker, thanks.

    That might be the case. If that was the problem though, shouldn't it affect the other search methods as well? (C symbol, global definition, et.c.). Those work perfect every time for me, I never have the problems that I do with egrep and text.

    Thanks,

    Mattis

     
  • Rich Coe
    Rich Coe
    2011-06-09

    # on sources that have '\r\n' in them, egrep produces no output
    # strip the carriage return out of the output

     
  • Rich Coe
    Rich Coe
    2011-06-09

    # cscope.egrep.out.patch
    # on sources that have '\r\n' in them, egrep produces no output
    # strip the carriage return out of the output
    # rcoe@wi.rr.com
    #
    --- cscope-15.7a/src/egrep.y 2008-03-12 15:43:56.000000000 -0500
    +++ cscope-15.7a.orig/src/egrep.y 2011-06-09 15:32:08.809669622 -0500
    @@ -592,12 +592,22 @@ egrep(char *file, FILE *output, char *fo
    succeed:
    fprintf(output, format, file, lnum);
    if (p <= nlp) {
    - while (nlp < &buf[2*BUFSIZ])
    + while (nlp < &buf[2*BUFSIZ]) {
    + if ('\r' == *nlp) {
    + nlp++;
    + continue;
    + }
    putc(*nlp++, output);
    + }
    nlp = buf;
    }
    - while (nlp < p)
    + while (nlp < p) {
    + if ('\r' == *nlp) {
    + nlp++;
    + continue;
    + }
    putc(*nlp++, output);
    + }
    lnum++;
    nlp = p;
    if ((out[(cstat=istat)]) == 0)

     
    • status: open-later --> open-invalid
     
  • A side note: next time you want to post a patch, please attach it as a file. Patches don't survive posting as free-form comments any better than text files survive being in entirely the wrong format for the platform they're on.

    This is really a non-issue. Nobody has an actual need to keep text files in the wrong format. Fix your sources, and the problem will be gone. It's as simple as that.

     
  • Rich Coe
    Rich Coe
    2011-06-09

    A properly formatted patch file can be found here:
    https://bugzilla.novell.com/attachment.cgi?id=433854

    I could not attach the file to this report, the feature was not available.

     
  • Rich Coe
    Rich Coe
    2011-06-09

    The source files cannot be 'fixed', as I do not own them.
    Fixing source files of a 10000+ file source project should not be required to fix
    broken output of a tool.

     
1 2 > >> (Page 1 of 2)