>>>Sigh. I'll just live with it.
>>
>>before giving up, you can wave a dead chicken over the monitor.
>>(okay, so this will likely not do anything -- but at least by doing it you've demonstrated that you've tried everything possible before giving up)
>>
>>But to be more serious... I'm wondering if you've got some instances where newline sequence wasn't quite right (i.e. not the usual carriage return followed by line feed). This could possibly "skew" the line count. Also other things that might affect it would be lines longer than a certain limit (i.e. where linewrap is involved) -- which could skew the display as well. Personally I prefer to keep program lines to 80 or fewer characters (this dates back to times when I was using ASCII terminals) - or perhaps for good measure, trying to keep within 72 columns. If the program code is a PRG file, you could try loading it into NOTEPAD, then copy-paste into a new text file. This should rid you of any pesky "invisible" control characters that could mess you up. Any characters in the 0..31 and 127.255 range could give you headaches.
>>I do recall ages ago having problems with a text file -- turned out there were stray NUL characters that caused some text editors to start truncating lines. Displaying file on screen or printer wouldn't reveal the problem as the NUL character was "invisible".
>
>Thanks, I'll try that.

Another thing you could also check are instances where blank lines appear in your code. I'd seen occasional assembler / compiler / interpreter that would "hiccup" on blank lines and end up reporting incorrect line numbers (typically they're too low - usually they're offset by number of blank lines prior to the reported line). A kludge around this is to change blank lines into a comment line (e.g. add an asterisk).