|
Post by George on Mar 10, 2022 12:39:12 GMT -5
Robert: Just tried it. Whether I say SAVEAS TempText.txt or just SAVEAS and select the file from the OpenFile popup, the session switches to the newly selected filename. Looking at the SAVEAS code, it doesn't even seem to notice whether its a CLIP session or not. George P.S. Did you see my edit of your NumLock suggestion?
|
|
|
Post by George on Mar 10, 2022 13:50:06 GMT -5
Robert: OK, big difference. You want a REPLACE in a CLIP session to act like a SAVEAS.
Hmm, big change. REPLACE was never supposed to actually change the existing files data (unless MM/MM line commands were used), As well, it may not be a full .zf .zl type REPLACE, would you want the session name to now represent a file on disk where the open edit session is not the same as the file, but is titled as if it is?
I don't want to get into trying to describe commands in the mode of "If a normal edit, it works this way, if it's a CLIP session it acts another way etc.
I think each of the SAVE, SAVEAS, CREATE and REPLACE have their own reasons for doing what they do.
George
|
|
|
Post by Stefan on Mar 11, 2022 7:08:47 GMT -5
Hi Robert,
Sounds interesting, I could give it a go. To be clear about what you seek... (1) you're in a CLIP session (2) You issue SAVEAS Without a filename? With a filename? Both? What 'path' would you expect to have added to the filename? (3) If the selected path\filename exists you wish to to a REPLACE
ELSE you wish to do a CREATE (4) Assuming success in step (3) you wish to close the clip session and open a new tab with the output file
Does that about cover it?
|
|
|
Post by George on Mar 11, 2022 11:31:26 GMT -5
Robert: I'm confused. If I'm in CLIP and I say SAVEAS FRED.TXT, the file is created and the session becomes a normal Edit of FRED.TXT. Isn't that exactly what you want? Or is it only a problem because the file already exixts?
In which case the options are: 1) A REPLACE option on the SAVEAS command. 2) An EDIT option on CREATE / REPLACE to open the file in a new tab. 3) A macro to do it.
George
|
|
|
Post by George on Mar 12, 2022 13:53:41 GMT -5
Well, don't overlook Options => FM which gives you the option of a) Working Directory or b) Last Used Directory.
Neither of these in my opinion are exactly great.
But I agree, there might/should be more that can be done.
George
|
|
|
Post by Stefan on Mar 13, 2022 4:11:48 GMT -5
Given that the CLIP data could have originated from... (a) any of the existing open tabs (b) from outside SPFLITE altogether (c) read in as a previously saved named clip (d) even from another 'clip' session ...you cannot make an assumption at all because the origin isn't known.
So you always need to pop up the Selection dialog, even if 'filename.ext' was specified, to solicit a filepath, unless the user provided a fully-qualified filename as command argument. A macro can do the pop-up but will need a "loop(off)" call before it, and probably resort to initiating the normal WINDOWS selection dialog rather than the SAVEAS one. The question, 'Does file exist or not' is then also easy to answer and a CREATE or REPLACE can be issued as required. In the absence of any line-selection critera at macro start, I would part company with the usual 'line-range-missing' error and just assume you mean 'all lines'.
It always annoys me that CREATE and REPLACE insist on line ranges and don't use 'all lines' as default in the absence of a 'line range' definition. It is especially annoying because after typing a fully-qualified name, the error 'pending line range' deletes the command from the command line. Normally, an error message leaves the command the user typed in the command line. If 'all lines' is not be the default, there should be an 'ALL' operand for these commands so a user can issue "CREATE 'fullfilename' ALL" from anywhere in the file without scrolling about to add a range.
----------------------------- BTW, I tried issuing SAVEAS from a macro (admittedly only once) and it dropped SPFLITE into a most bizarre state (might have been a one-off). The macro didn't finish The macro didn't loop SPFLite was unresponsevive but not marked as 'not responding' - probably because Windows hadn't asked it to respond to anything Task Manager showed no CPU resource being consumed. It just 'sat' there, like Shroedinger's cat, apparently alive and dead at the same time. I had to terminate SPFLIte from Task Manager. Will need to try this again to see if this is repeatable.
|
|
|
Post by mueh on Mar 13, 2022 4:18:53 GMT -5
Hi Robert and Stefan ! Attached MSA macro can be issued for CLIP and (Empty) session . If MSA str is issued Recent Paths Flist is searched for str and Path is used in promt for file . MSA.macro (2.6 KB)
|
|
|
Post by George on Mar 13, 2022 9:37:10 GMT -5
Guys: As the person tagged with 'doing' smething, my preference is:
Make ALL the default for CREATE/REPLACE if no line range is marked. (I too hate what it currently does)
Add REPLACE/REP option to SAVEAS (and maybe CREATE for consistency?) to handle existing file replacement.
If CREATE/REPLACE/SAVEAS don't have a fully qualified name, popup the OpenFile dialog to provide the proper location.
And if we do the above, do we still want the FM option of Working Dir/Last Used Dir?
George
|
|
|
Post by Stefan on Mar 13, 2022 12:28:35 GMT -5
George, in reply to your last post... In short, I agree with all points in your summary.
I should also like to see another change, which is easy to do but string length may be an issue. SAVEAS, CREATE, REPLACE, etc currently confirm the action with a message like "8 records written". This is 'data' rather than 'information'. I wager that I'm not the only one who does not care about the record count. I expect SPFLite to get that right!
The question in my mind is "Where did SPFLite put it?"
So a message that says 'Saved to Dir 'C:\blah\blah\<ie. a pathname>\" is much better.
There's no need for the "filename.ext" part because the user supplied that. Feel free to use 'Folder' instead of 'Dir' if you prefer.
Robert, in reply to your last post...
Given we all agree the default for save/create/replace, etc should be ALL lines unless user says otherwise. we can probably put that aside.
I like that SAVEAS is 'PC speak' and leaves me editing the new file afterwards without altering the old one or leaving the old tab open and I wouldn't want to lose that feature. But you've skillfully incorporated it in your proposed SAVE AS... structure. Same function as SAVEAS has now, brought about by the addition of the 'AS' operand. Neat! If you expand the existing SAVE comamnnd in this way, the SAVEAS command is redundant.
I should like to add .... So when the user issues 'SAVE AS <filename here, either specified or obtained via selection dialog>' and the file already exists, the comamnd reurns RC=4 with a warning message. Crucially, at this point the command line contains the entire command string, so the user can EITHER...
- just add the 'REPLACE/REP' keyword to overwrite the file OR... - just overtype/change the filename to make it unique. No need to start again with retrieving/retyping the command and re-entering the selection dialog, etc., etc.
Aside from a nod to ISPF/PDF compatibility, I don't really see any need to keep the CREATE and REPLACE commands given that your proposed "SAVE AS...." syntax can cover both of these. For backward compatibility you could simply SET.ALIAS them to the new SAVE AS command. As you pointed out, the notional difference between CREATE and REPLACE were annoying in 1975 and are still annoying today!
I think the new SAVE AS command could also accept a REP/REPLACE option.
That leaves how to pick the path name for the selection dialog or which default to use. I believe in keeping this simple and predictable for the user...
(1) If the user specifies a fully-qualified path - that's it. No selection dialog. Just do it. (2) For SAVE AS issued from a tab containing an existing file, we should start the selection dialog at the same directory/folder where the existing file is stored. It the user supplies no name at all or a 'filename.ext' without a path, there are two options. I propose....
a) user enters "\filename.ext" - just use the same directory where the 'source' file is stored
b) user enters "filename.ext" (no \) - open a selection dialog starting in the same direcorty where the source file is stored (3) For a clip session, Robert's point (5a) is correct. We always need a file selection dialog. What should be the 'starting point' for this dialog? I have no better idea than using the file path recorded on the FM screen.
(3) For data in a a New/Empty tab - see (3) above.
Sorry Robert, but I don't like the idea of a 'default' directory where 'lost' files go. (If we must have one, I vote for "%UserProfile%\Desktop\" because it can easily be found and dragged to the right place or into SPFLite.)
As for maintaining a list of 'recently used directories', you could use FAVORITES.FLIST or even RECENT.FLIST given both already exist and are already being maintained. But that would be yet another, different(!) selection dialog to appear. I'm not keen.
I figure 99% of the time, the present CREATE/REPLACE/SAVEAS is issued from a tab that already contains data from an existing file. eg: I want a new XYZ.MACRO, large parts of which are similar to my existing ABC.MACRO, so I edit ABC.MACRO and issue SAVE AS XYZ.MACRO.
Back in 1975, I would have opened XYZ.MACRO and 'COPY ABC.MACRO' into it - probably both in the same PDS or from another with a very similar name!
|
|
|
Post by George on Mar 13, 2022 13:32:48 GMT -5
Robert: Before going further, I reviewed the FM path option logic. Quite a surprise!
The Options => FM setting is dead as a doornail. It's set, saved etc. but is never referenced - anywhere! We obviously made a change somewhere in the past. So then, how is the PATH handled currently?
When needed, if a pop-up to choose the location is not used, the default will be the path of the file currently being edited. If no real file (CLIP, $Empty, SETEDIT, etc.) then the most recently used FilePath entry from FM is used.
And if all that fails to generate a PATH, the Windows Current Directory is used. This is not ideal but ....
You know me, I do not want some wholesale revision of all the SAVE, SAVEAS, CREATE and REPLACE routines. That's simply a no-go, far too disruptive, too many new UI options etc.
I suggest we leave them alone (for now) and create a single new command to replace them all. Then after it has proven itself, we remove the other 4 old commands. I can cobble this new command together with some judicious cut/paste from the other four commands.
WRITE [COND]
[file-name [REP | REPLACE ] [line-control-range ] [ X | NX ] [ U | NU ] [ EDIT | BROWSE | VIEW ] ]
If file-name is fully qualified, - fine. If not and it has a leading ?, a selection list of the Recent Paths will be presented. If no leading ?, a normal Path selection dialog is presented.
e.g
Replace current SAVE WRITE Replace current CREATE or REPLACE WRITE filename [ REP ] Replace current SAVEAS WRITE filename EDIT [ REP ]
The SAVEAS, CREATE and RELACE versions can all obviously add the optional line-range etc operands. No line range defaults to ALL.
Would this do what we want?
George
|
|
|
Post by George on Mar 14, 2022 11:49:07 GMT -5
Robert: My only reason for making a new command was to have the old and new available in parallel. Keeping it as SAVE is worthwhile, CREATE/REPLACE/SAVEAS would just disappear. We can probably provide or suggest ALIAS entries to smooth the transition.
My main comment on your suggested AS / TO / IN options is the complexity of cross-tab stuff. It is terribly difficult.
I'll fully comment later.
George
|
|
|
Post by George on Mar 14, 2022 12:50:10 GMT -5
Robert:
1. If I have a browse session and I say SAVEAS new-file-name, this is currently rejected, even though the original file would not have been altered. This seems overly strict.
Cmd table Oops, but correcting it leaves you in Browse of the new file. I think that is the correct action.
Does this mean you have changed the code to address this? If so, I will look for it in the next beta. It sounds like this is in fact the correct action. If I didn't want that, I could do a CUT of the entire file and start a NEW edit session manually if I had to.
2. For the primary commands, BROWSE can be abbreviated as B or BRO but Edit and View cannot be shortened. ED is obvious for EDIT, but no short version of VIEW comes to mind.
Why the obsession with shortening things that are already pretty short (4 chars)?
What can I say? I suppose it IS an obsession. I use RESET all the time, and instead of saying RES as an abbreviation for it, I have an alias defined as RE=RESET. I find it much easier to type and is less prone to typing errors.
3. We have at times used the expression "defaults to ALL" but I assume you don't literally mean a keyword of ALL but mean that "all lines" is implied. Hey, if you want an actual ALL that's ok but we need to be clear what is meant.
I'm not sure that "defaults to ALL" is subject to interpretation. Tell me what incorrect assumption can be made. Clarifying this is a make work project.
The clarification is for US. It's not a make-work project; I am not talking about revising the Doc. I just wanted be sure you were not really going to implement an ALL keyword to imply .ZF .ZL in this new variation of SAVE that we've been discussing.
4. I would not get rid of SAVE. That's for ISPF compatibility. SAVEAS is an SPFLite invention so we are free to do as we wish.
We could suggest an ALIAS for SAVE => WRITE.
5. The WRITE keyword seems a bit long.
Length again?
What can I say? At least I'm consistent.
6. With all these keywords, we have to document somewhere that saving a file actually called REP or whatever requires quotes.
Sure, another paragraph in the Doc. to explain the obvious.
Alright, you got me there. I can hear you sighing across the international border, in ASCII no less :-((
7. The EDIT VIEW BROWSE thing is a bit wordy. I assume its meaning is "open another window to replace the current one" and then open the file using the specified access method (edit view or browse). If I understand correctly, it seems like you are combining two things, the idea of starting a new window, and saying how you want to access the file once you get there. Ideally, these two concepts should be specified separately.
Separately? How? Where? It has to be specified somewhere, what better place than when it's created?
The "separately" part meant separate keywords, not separate operations. Yes, it would be specified in the same SAVE/WRITE command, just not (always) as a single keyword.
7.1 I would like to simplify this. First, let us assume that if a new file is put in an existing edit window. its mode of access is assumed to be what was there before. So if I were in EDIT, the new window is also EDIT. BROWSE goes to BROWSE, and VIEW goes to VIEW.
Fair. See my fix in point 1 above. Nothing wrong with a default, the operands would be there as options.
This brings up a thought. I don't know if we ever considered this before, but suppose you were in a file opened in one mode, but wanted to change the mode. For instance, you might want to BROWSE a file, but once you saw it, you might want to alter it. Right now, the only way this would be possible is to close the file and reopen it a different way. It would be nice if could change modes right in the edit window with a primary command. Suppose the command were MODE access-type, where you'd say how you wanted to process the file. So there would be a MODE EDIT, MODE BROWSE and MODE VIEW. In EDIT, you couldn't change modes if there were any unsaved changes.
I can hear your teeth grinding. As I said, I am not sure if we ever discussed this idea in the past.
7.2 If a new file goes to a new window, just assume EDIT if possible. You're accessing a new file which is a copy of the old one. If you don't want to change it, why did you create a copy in the first place? To have a backup? That's what BACKUP is for.
We just agreed to open the new file in the same mode as the original.
This point and those following implying the creation of a new session in a new tab may be difficult to accomplish, just a comment for now.
My bad, a consequence of writing too much. This 7.2 item I wrote is incorrect. Launching a new tab is a harder problem than deciding what mode the file will be in.
7.3 Suppose you really don't want to change the newly created file, at least not at the moment. Let's allow a new keyword of RO for Read Only. If you want, RO can always mean VIEW, and then you could add a General Options GUI field to say what RO means. If you don't like that idea, BR means Browse and RO means View. Let's keep this short, can we?
What's wrong with the EDIT, BROWSE and VIEW proposed options. And again, as these would be exceptions and infrequently used, let's forget this abbreviation stuff.
Does that mean you would accept currently existing abbreviations but not the new ones I suggested?
As I see it, there are 3 possible things you could do to handle the resultant edit window(s). Not that you'd necessarily support all of them, but there are in fact 3 ways to go when saving as a new name:
(a) Write the new file but stay with the original file in the original window. I would term this the "stay" option. STAY means that, even though you save a file under a new name, it doesn't change what you were doing in the current edit window. That handles the current CREATE and REPLACE semantics.
(b) Write the new file and move the focus of the current edit window to the new name, abandoning the old file and the old window, but replacing the edit window it used to be located in. I would term this to be the "move" option. MOVE is the semantics you do now (most of the time) for SAVEAS.
(3) Write the new file and open a second window with the new name, but keep the existing window open too. You could call this a "dual" option, since you'd have an extra edit session open. This would be a new feature; you don't currently support the semantics of what DUAL would imply.
When you boil down the above, there are actually just two factors in play. One is whether or not you want a new edit session with with the new name in effectively a new window, and the other is whether you want to keep the old window where it was.
To address this,
- "AS filename" would mean "the saved file with the new name will have its own window". The new window would replace the old window. This is the "move" option noted above.
- "IN filename" would mean the saved file in the new filename will NOT have its own window but will merely be saved". The current edit window with its current edit file stays where it is. It is possible that IN is the default and might not be needed, but since we are changing things, having IN explicitly stated seems like good clarity and documentation. This is the "stay" option noted above.
- "TO filename" would mean "the saved file with the new name will have its own window and the old window is retained". Thus, saving TO filename would open a second window. This is a play on words, to help you remember, because TO rhymes with TWO, and TO filename would change one open window into two of them. This is the "dual" option noted above.
I find the AS / IN / TO 'magic words' way too similar, I've read this multiple times and I'd still fail a test in describing each one correctly, there has to be a better way.
For AS, think of it like SAVEAS, only now it would be two words, SAVE AS. That goes along with retaining the SAVE command, but with extended syntax. As for IN and TO, I would have to agree with the "magic" aspect of it. If you don't like it, chances are good other users won't like it either.
I am not sure what the better way, but clearly one is needed.
8. I believe the COND option is useful, but the "condition" that is involved is whether the file has been modified or not. I believe a form of MODIFIED or MOD would be a more appropriate name for this.
Let's not change stuff for no good reason. "More appropriate" isn't enough,
You are right. Even if users would go for MOD, we would still have to explain it. I am not a big fan of COND, but it's been around for a while. It's like MVS JCL that has weird syntax in places but it's been around for decades and it's too late to change it.
9. I understand X|NX and U|NU but what would WRITE name X NU mean? Excluded lines which are not User lines?
If you really wanted to support this, I won't stop you, but I suspect very few users would try such a thing. I would simplify this to just [ X | NX | U | NU ] and only allow one of these, because otherwise users may have difficulty understanding what a combination of these codes would mean. (Maybe you actually meant that but just didn't explain it as such.)
These options already exist on a wide range of commands, by your reasoning we should go back to all these commands and impose this mutually exclusive treatment to all of them. Sorry, No. I'm sure users can reason this out.
I relent. If you want to support unusual combinations of these because you're doing that elsewhere, who am I to say No? I doubt that I personally have ever tried to say X NU on anything, but then that's just me.
10. How do we deal with handling the prior existence (or not) of the saved file? REP is good to allow for replacing files, but it's ambiguous. It will store a file whether the old one exists or not. I believe that can be kept, since it's an "easy" choice, but it not the only possible one. I would add two more: NEW (like the CUT command does now) and OLD. NEW means, "I insist that the saved file NOT exist". OLD means, "I insist that the saved file DOES exist already".
Sure.
I can see where NEW/OLD might be helpful in macros, where you wanted precise control over the prior existence question.
George
|
|
|
Post by George on Mar 14, 2022 14:14:03 GMT -5
Robert: We're not too far off, all we have to do it come up with a final syntax. No small problem.
BTW: SAVE COND will always have NO other operands, it's unique. e.g. no line ranges, X/NX etc. as it creates ridiculous out of sync file error possibilities.
George
|
|
|
Post by George on Mar 14, 2022 15:16:47 GMT -5
OK, I've created a proposed SAVE syntax. Please ignore that we might support abbreviations for some of these.
And remember, I'm doing this from the point of view of the poor soul tagged to actually write all this stuff.
SAVE [ [ [COND] |
[ * | EDIT | BROWSE | VIEW ] [ KEEP ] filename [ NEW | OLD ]
[ line-control-range ] [ X | NX ] [ U | NU ] ] [
SAVE COND is unique, no other operands allowed.
* | EDIT | BROWSE | VIEW A new session of this type to be created. filename must be specified. * means current mode. KEEP The current Window/Tab will be retained, the new session will be in a new Tab. NEW The filename will be created, it must not currently exist. OLD The filename, if it exists, may be overridden. line-control-range A standard line range operand to limit the line range written to the file X|NX Select X or NX lines only to be written U/NU Select User or non-User lines to be written.
Examples
SAVE Exactly as now SAVE COND Exactly as now SAVE filename [NEW|OLD] Like current CREATE/REPLACE SAVE * filename [NEW|OLD] Like current SAVEAS, replace the session with a new one in the current mode (Edit/Browse/View) SAVE BROWSE filename [NEW|OLD] Like current SAVEAS, replace the session with a new BROWSE(or whatever) session of the new file. SAVE * filename [NEW|OLD] KEEP Like current SAVEAS, open a new session with a new one in the current mode (Edit/Browse/View) in a new tab and keep the current tab.
George
|
|
|
Post by George on Mar 15, 2022 8:40:49 GMT -5
Robert: After sending my last attempt, I of course kept playing with it. I've tried to simplify it greatly. It will still have the ?filename option to display recent PATHS to choose from.
SAVE [ [ [ COND ] |
{ ASFILE | AS* | ASEDIT | ASBROWSE | ASVIEW } filename [ line-control-range ] [ X | NX ] [ U | NU ] ] ]
Changes: I've dropped the KEEP/TAB/... option. No DUAL option to keep things simple.
The weird AS... line is not as bad as it looks. I'd parse as leading char KW scan with ASFILE the 1st test. So the others could be as short as AS*, ASE, ASB etc.
This means formats like:
SAVE A simple SAVE SAVE COND A simple SAVE COND SAVE AS filename The CREATE REPLACE version. It will internally default to NEW, and if the file exists a normal Popup "Do you want to override?" will appear. There will be no OLD (force previous existance) option. SAVE AS* filename Same as above, but like the current SAVEAS command. Same handling of NEW|REP. SAVE ASxxxx filename Same as above, but a forced switch to EDIT|BROWSE|VIEW for the tab.
Line range and X|NX U|NU will all default to all lines.
I know this doesn't have all your bells and whistles, but I think it's clearer
George
|
|