Menu
▾
▴
[Cscope-devel] [ cscope-Bugs-453466 ] top lines invisible but still selectable
|
From: <no...@so...> - 2001-08-21 18:37:13
|
Bugs item #453466, was opened at 2001-08-20 12:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=104664&aid=453466&group_id=4664 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Satya Nemana (satyan) Assigned to: Hans-Bernhard Broeker (broeker) Summary: top lines invisible but still selectable Initial Comment: Environment: Windows 2K Professional 1-2 Pentium CPU on Dell Systems. Using CSCOPE 15.3 built with GNU gcc/g++ tools downloaded from CYGWIN 5.0 for Windows. If I invoke cscope session on the same 15.3 src directory and search for 'getline', then it displays all lines that contain 'getline' and I can select any of them for example 0 through 9 and get into vi. Functionally it works OK. But some of the lines in the top part of cscope window are not visible. In this case on cscope15.3/src, if I search for getline, then the lines 0 to 6 are not visible. I have added a snapshot of the screen dump as an enclosure with this. This problem is not only for searching as illustrated above, but also occurs sometimes if I try to do "Find this C symbol:", "Find this global definition:" etc. Typically it happens, when the resulting buffers displayed in top cscope window overflows beyond certian large buffer lengths. Selecting 0 to 6 in above example, brings up the vi session. It means functioanally it works. Only the displaying lines are missing. Please note that these top invisible 6 lines appear as blabk lines, which means the 1st visible line (which is 7) is located in 8th row and the all the 7 top rows are blank lines. I don't know if it happens on Solaris with our version. I would like to check it and let you know. ---------------------------------------------------------------------- >Comment By: Hans-Bernhard Broeker (broeker) Date: 2001-08-21 11:37 Message: Logged In: YES user_id=27517 I suspect the real problem is that CYGWIN is trying to be overly clever, here. cscope is supposed to already deal with this issue correctly --- all reads of filenames are done in text mode, but all files cscopes writes (including those of the cscope.out file) are in binary mode. Without those changes, porting cscope to DJGPP would never have been possible. But IIRC, Cygwin has a really boneheaded idea that it should be doing DOS<->UNIX textfile conversion behind the scenes, too. For a program carefully ported to non-Unix filesystems already, this transformation breaks it instead of fixing anything. The solution might be to force Cygwin to interpret these sourcefiles as binary mountpoints. ---------------------------------------------------------------------- Comment By: Satya Nemana (satyan) Date: 2001-08-21 11:25 Message: Logged In: YES user_id=302967 Broeker, Congrats. you nailed the problem right on its head. All the cscope sources came up in DOS mode with each line ending with \r\n in stead of a just \n whereas system headers are not in dos format. If the file is in DOS mode, then cscope shows up invisible or blank lines. In stead of expecting the user to convert all files into non-dos mode, it is better for cscope to treat them in same way, by fixing it in cscope.exe. In my example, what ever are displayed are system headers, which are not in DOS mode (line terminates with a \n) and hence these lines are visible. For example, I could not see the command.c entries for getline search. I could see them again, as soon as I removed the \r before \n. Once I converted the command.c file into non-dos mode (as indicated below) by removing the \r before \n, then these lines became visible. I normally use vim.exe, which comes with GNU in CYGWIN, and is linked to vi.exe, so that vi is same as vim. To convert into dos mode actually, I copied stdio.h into a local command.c and did a .r oldcommand.c and removed the actual stdio.h related lines, so that file format is preserved. Summary is that this can be fixed in cscope somehow by treating \r\n specially and converting into \n. Please let me know, if I can fix it here and send it for your review. I will wait for your suggestion. Thanks in advance. ---------------------------------------------------------------------- Comment By: Hans-Bernhard Broeker (broeker) Date: 2001-08-21 03:25 Message: Logged In: YES user_id=27517 More likely than not, this is a Curses-related problem. I had lots of problems with the DOS version of curses, too. Does the display come up correctly again if you force a redraw (by typing Ctrl-L)? Did you try it with a less more traditional Screen size? The screenshot you uploaded seems to be from a session with considerably more than 25 lines. And yet another idea: reproducing your example search for symbol "getline", I only find 7 references (numbered 0 to 6), all contained in the cscope sources. The ones still visible in your screenshot are from system headers. This *may* be part of the problem, or a sign of some difference between local source files and system headers that causes it. It just might be a DOS-style line endings problem, e.g. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=104664&aid=453466&group_id=4664 |