I encountered following problem for kernel code reading:
~~~
Cscope tag: icsk_timeout
# line filename / context / line
1 60 include/net/inet_connection_sock.h <<<unknown>>></unknown>
* @icsk_timeout:
2 86 include/net/inet_connection_sock.h <<<unknown>>>
unsigned long
3 230 include/net/inet_connection_sock.h <<<unknown>>>
icsk->icsk_timeout = jiffies + when;
~~~</unknown></unknown>
In the second item, the keyword "icsk_timeout" is not showing.
By AI assisted, following patch could solve the issue, make the tab with space:
~~~
$ diff -Naur src/egrep.c.src src/egrep.c
--- src/egrep.c.src 2017-11-07 00:16:24.000000000 +0000
+++ src/egrep.c 2026-10-09 05:03:41.951290242 +0000
@@ -2076,6 +2076,15 @@
return fread(p, sizeof(p), buf_end - p, fptr);
}
+/ Match display.c: tabs in source lines confuse cscope -L clients. /
+static void
+putc_line_char(FILE *output, int c)
+{
~~~
Thanks,
Mark
patch in file.
The report is a bit unclear on what, exactly, you asked cscope to do, and what you were using to look at its output. Which -L mode client was that, and why woud its potential failure to cope with tab characters, which are perfectly fine in C source code, have to be seen as cscope's problem?
The way the output was mangled by SF's markdown processing also makes it quite hard to judge what might be wrong here. I'm pretty sure there were not two
<unknown>tags in cscope's actual output.It also doesn't reproduce for me in stock cscope 15.9, searching Ubuntu's linux source 6.8.0. Both line modes, and interactive mode, correctly display all of that line, including the tabs and all the way to its closing semicolon.
Last edit: Hans-Bernhard Broeker 2026-10-10
Hello Hans,
My env is WSL, with cscope
mark@wxy:/mnt/c/Windows/system32$ cscope -V
cscope: version 15.9
The problem is, when do search "cs find t icsk_timeout" in Linux kernel code(v 6.18), the keyword "icsk_timeout" was not showed in the item-4.
Please check the attachment by snapshot.
Thanks,
Mark
"cs find" is not exactly a cscope command. It's a vim integration command. Which means, given that cscope itself appears to quite successfully display those lines, if run by itself, the responsibility for the garbled display would IMHO have to be laid at the feet of the VIM integration for cscope.
Hi Hans,
Thanks for your support.
I have sent one email to vim to consult the problem.
Thanks,
Mark
Last edit: mark.zhang 2026-10-18
https://github.com/vim/vim/discussions/21611
Solved on the VIM end of things (as of v9.2.1259)