THE 3.1B1 on Win XP
Start with switch "-u 100".
THE starts in the directory.
A macro issues "command edit xxxx" to edit one of the files listed. The file contains these 20 lines
Line 001
Line 002
Line 003
Line 004
Line 005
Line 006
Line 007
Line 008
Line 009
Line 010
Line 011
Line 012
Line 013
Line 014
Line 015
Line 016
Line 017
Line 018
Line 019
Line 020
The file is displayed with the end of each line abutting the start of the next line, like this (this is truncated because of the size of the textarea)
Line 001Line 002Line 003Line 004 and so on.
The lines are actually stored on a Linux system (EOLOUT=LF), and each line ends with 0x0A. This makes each line 9 bytes long (8 data + 1 end), so the first line displayed can show 11 lines from the file (99 bytes) plus 1 byte from line 12, and this is the case. The first displayed line ends this way
Line 010Line 011L
Arrowing the cursor across the displayed line and watching the id line to see the hex and decimal value at each byte, I see that the 0x0A bytes are there, but no position in the displayed line shows them. When the cursor moves from byte 8 (the '1' that ends the first line of the file) to byte 9, the byte value in the id line shows 0x0A but the cursor in the displayed line is at the first character of the second text line of the file (the 'L'). Arrowing 1 byte right, the id line shows the byte value as character 'L' but the cursor is now at the 'i'. Cursor and byte value remain off by 1 position through the text of the second data line, then off by 2 positions throught the third data line, and so on.
Also, I'm not sure that 0x00 bytes in the file are handled properly.
Logged In: YES
user_id=1587066
Originator: YES
OK, using -u doesn't always skip display of the 0D and 0A bytes, but it does happen.