Post by Stefan on Jul 21, 2024 12:24:50 GMT -5
George,
This suggestion is in two parts.
(1) CLIP command
I notice that 'named' CLIP files when loaded via the CLIP command do not provide information about their filename to Macros.
Say I create a named clip file called "Stef" using the command CUT Stef ALL
A file called Stef.CLIP will be placed in \CLIP folder in the Homedata (Get_INI_Path$), in my case S:\SPFLITE\CLIP\Stef.CLIP
If I reload file Stef.CLIP into the editor via FM or by a simple drag-and-drop from the folder, the macro functions Get_FilePath$, Get_FileName$, Get_FileBase$, Get_FileExt$, and Get_FileDate$ all return correct information.
However. if the same clip file is loaded with the command CLIP STEF, only Get_FilePath$ and Get_FileDate$ provide information and FileDate$ is always today/now, not the date file was last modified.
Why does this matter? I guess 99.99% of the time, it doesn't, however...
Working with mueh, I've been modifying BACKVIEW to support 'special' EDIT session such as CLIP-EDIT, SET-EDIT and EFT-EDIT.
mueh reminded me that while the profile's AUTOBKUP setting is ineffective with these session types, a manual BACKUP command does create a backup file in the usual manner, and BACKVIEW support would be helpful.
I note that both the CLIP and the BACKUP command 'lose' the "name" aspect of a clip file.
Issue command CLIP STEF followed by a BACKUP command and the backup file just reads CLIP.yymmdd-hhmmss.yymmdd.TXT. The 'Stef' part is lost.
Hence I should like to suggest that
- the BACKUP command gains support for 'named' CLIP files and
- the macro functions Get_FileName$, Get_FileBase$, Get_FileExt$ and Get_FileDate$ are populated correctly after loading a file with the CLIP command
(2) Backup file names for CLIP/SET/EFT sessions
Preamble:
I appear to have a setup where CLIP, SET and EFT sessions are associated with profiles CLIP, SETEDIT and EFTEDIT respectively.
The issue is, I cannot remember if/how I created those associations, so I don't know if it is 'built-in'.
I think(!) if profiles called CLIP, EFTEDIT and SETEDIT exist, they are automatically used for those sessions. If not, DEFAULT is used.
The issue is that those profiles are not included in the distribution and probably should be.
If these profiles exist, such associatons are indeed 'builtin', the text below makes sense.
However, if this setup is specific to me, please consider the suggestion in general terms (e.g. why .TXT?) rather than the specific values.
The format of the backup file is documented as
<filebase>.<ext>.YYMMDD-hhmmss.YYMMDD.<ext>
where the two <ext> values are the same for easy reloading.
For 'normal' files, the two <ext> parts are missing if the original file did not have an extension.
All good and consistent.
But for CLIP, SET and EFT data sessions, the backup filename gains a <fileBase> of CLIP, SETEDIT and EFTEDIT respectively, and appends .TXT to the end.
The <filebase> addition is informative, but to be consistent, should the .TXT appendage not be .CLIP, .SETEDIT and .EFTEDIT if those are the profile names used to edit such data?
For example: An EFT backup file would be
EFT.EFTEDIT.YYMMDD-hhmmss.YYMMDD.EFTEDIT
instead of
EFTEDIT.YYMMDD-hhmmss.YYMMDD.TXT
Similarly for a SET-EDIT and CLIP backup data.
Hence I should like to suggest that
- The SPFLite distribution include Profiles CLIP, SETEDIT and EFTEDIT.
- The SPFLite distribution include Profiles CLIP, SETEDIT and EFTEDIT.
- Backup files of CLIP, SET and EFT data follow the normal backup file naming rules, albeit with the addition of <filebase> component of CLIP, SET and EFT.
