You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Edit mode uses the screen editor to edit SEQ text files, using the BASIC program memory and line numbers. In Edit mode (enabled with EDIT ON), lines are stored as raw text instead of tokenized BASIC, and several commands have alternate behaviors, such as DLOAD/DSAVE operating on SEQ files instead of PRG files and eliding line numbers and linking information. Only a few commands have Edit mode behaviors; others abort with Edit Mode Error when not supported.
It would be useful to have a way to combine files interactively. I propose giving the existing MERGE command a new Edit mode behavior: MERGE "<filename>" [,L<linenum>] reads the contents of a SEQ file and inserts it at the given line number, or at the end of text if no line number is specified.
The L argument is only supported in Edit mode. Any lines at or after the given line number are renumbered by 10s, similar to how line numbers are assigned during an Edit mode DLOAD. (Edit mode line numbers are not saved to disk as they are in BASIC.)
Alternatives considered
The MERGE command appends a BASIC PRG file on disk to a BASIC program in memory. It does not offer insert capability, and in fact expects the user to ensure that the program on disk starts at a later line number than the last line of the program in memory, to simplify the line linking process. It does not overwrite overlapping lines. Given this concatenating behavior, it's symmetrical with the proposed Edit mode, without a line number argument.
The line number argument will be difficult to implement, but useful enough in Edit mode to consider. It would not be practical to offer a similar argument to MERGE in BASIC mode, unless it behaved like RENUMBER or something. That feels out of scope for this request.
Another possibility is to give this new Edit mode behavior to the IMPORT command. This is another utility for merging code from disk into a BASIC program, except in this case it loads a full program listing from a SEQ file including line numbers, and behaves as if the file is typed at the Ready prompt. There is some symmetry in the reading of SEQ files, and Edit mode SEQ files don't have line numbers so different behavior there would be expected. But the proposed behavior feels further from IMPORT than MERGE.
A new keyword like INSERT could avoid hassles with symmetry. IMO we should take a conservative stance on creating new keywords at this point, to avoid collisions with existing programs. I'm not fully opposed, but we should do the work to scan all BASIC programs on Filehost to determine the likelihood of a collision. In this case, having two existing commands that could be extended seems like plenty of options.
With no changes, a user could manage concatenating files by saving the file in memory to disk, then writing a small program that opens the first file with APPEND# on one channel and the file to append with DOPEN# on another, then reading from the latter and writing to the former until end of file. The user then reloads the appended file. That's too many statements to expect a user to enter in direct mode whenever a merge is desired.
The text was updated successfully, but these errors were encountered:
Edit mode uses the screen editor to edit SEQ text files, using the BASIC program memory and line numbers. In Edit mode (enabled with
EDIT ON
), lines are stored as raw text instead of tokenized BASIC, and several commands have alternate behaviors, such asDLOAD
/DSAVE
operating on SEQ files instead of PRG files and eliding line numbers and linking information. Only a few commands have Edit mode behaviors; others abort with Edit Mode Error when not supported.It would be useful to have a way to combine files interactively. I propose giving the existing
MERGE
command a new Edit mode behavior:MERGE "<filename>" [,L<linenum>]
reads the contents of a SEQ file and inserts it at the given line number, or at the end of text if no line number is specified.The
L
argument is only supported in Edit mode. Any lines at or after the given line number are renumbered by 10s, similar to how line numbers are assigned during an Edit mode DLOAD. (Edit mode line numbers are not saved to disk as they are in BASIC.)Alternatives considered
The MERGE command appends a BASIC PRG file on disk to a BASIC program in memory. It does not offer insert capability, and in fact expects the user to ensure that the program on disk starts at a later line number than the last line of the program in memory, to simplify the line linking process. It does not overwrite overlapping lines. Given this concatenating behavior, it's symmetrical with the proposed Edit mode, without a line number argument.
The line number argument will be difficult to implement, but useful enough in Edit mode to consider. It would not be practical to offer a similar argument to MERGE in BASIC mode, unless it behaved like RENUMBER or something. That feels out of scope for this request.
Another possibility is to give this new Edit mode behavior to the IMPORT command. This is another utility for merging code from disk into a BASIC program, except in this case it loads a full program listing from a SEQ file including line numbers, and behaves as if the file is typed at the Ready prompt. There is some symmetry in the reading of SEQ files, and Edit mode SEQ files don't have line numbers so different behavior there would be expected. But the proposed behavior feels further from IMPORT than MERGE.
A new keyword like
INSERT
could avoid hassles with symmetry. IMO we should take a conservative stance on creating new keywords at this point, to avoid collisions with existing programs. I'm not fully opposed, but we should do the work to scan all BASIC programs on Filehost to determine the likelihood of a collision. In this case, having two existing commands that could be extended seems like plenty of options.With no changes, a user could manage concatenating files by saving the file in memory to disk, then writing a small program that opens the first file with
APPEND#
on one channel and the file to append withDOPEN#
on another, then reading from the latter and writing to the former until end of file. The user then reloads the appended file. That's too many statements to expect a user to enter in direct mode whenever a merge is desired.The text was updated successfully, but these errors were encountered: