The issue is that a "line" in a text file can mean many things. It's because of the way a text file is saved (all text files, not just those from lisp). Say you have the following in a text file:
First line
Second line
Third line is a bit longer
Fourth
Fifth lineHow would you get to the Fourth line? Any line could be any length. The above file is saved thus:
First line[CR][LF]Second line[CR][LF]Third line is a bit longer[CR][LF]Fourth[CR][LF]Fifth line
So in this case the Fourth line starts at the 56th character, but if any of the lines before it is only slightly different that character is at a different position.
So no way to simply go to a specific place in the file for all possibilities. You have to read the first set of lines to find out where the line you're interested in starts. But say you've now figured out that the Fourth line starts at character 56. You want to change it into: "Fourth Line". This will alter the file to this:
First line[CR][LF]Second line[CR][LF]Third line is a bit longer[CR][LF]Fourth Lineth line
Which corrupts the rest of the file since you're actually overwriting part of the fifth line to get something which looks like this:
First line
Second line
Third line is a bit longer
Fourth Lineth lineTherefore it's never a good idea to work on only parts of a text file - unless you make it into a structured file (like a database file). These are split into packets, which never vary in size. The simplest structured file would work similar to an old Pascal string Array. E.g. each line can only be a maximum of 255 characters long, but the blank space is also saved - just ignored, the 1st character lists the actual length of the text in the line as binary digit. The above would be saved as:
\013First line............some garbage not even worrying about this....up to the 256't character
\014Second line.....................
\033Third line is a bit longer.........................
\007Fourth.........................
\013Fifth line.....................Now you know that the 4th line always starts at the 769th character and ends at 1024 - no matter how long any one line's actual text is.
Clearly this file has lots of wasted space, because none of those lines even come close to using the full space allotted to them. This is the major example of what's meant when a programmer says efficiency is a balance between speed and space. The text file uses the least space but takes the longest to edit, the structured file uses the most space but can be edited near instantaneously.
There's another drawback when using structured. Very few (if any) text editors will read that file correctly. So your program would be the only thing which could make sense of it, or you'd need to write some new version of Notepad so someone else could open that file to even just see what's inside.
In lisp I'd only start considering structured files when I want to randomly replace single lines in a file with 1000's of lines on a very short interval. If it's only say 100 lines, it's probably not worth the effort to try and steer clear of the following code:
(defun TextFile
-ReadLine#
(FileName Number
/ f str
)
(defun TextFile
-WriteLine#
(FileName Number Text
/ f lst str
) (str))
lst)))
And even if it's more lines I'd look at saving each line as an item in a global list (as mentioned previously). That way you read the entire file once into RAM, then replace the item(s) in the list as your program continues working. Then you could add something like a DrawingClosing reactor to save that list back to the file just before the Dwg is closed. That would be a lot more efficient than the constant file access you're after.
Edit: Bug corrected in code.
