|
|
Post by Stefan on Apr 2, 2021 5:44:15 GMT -5
George, et al,
FM command structure I note that we are inventing more commands (eg: MAKELIST) and it seems that just about every FM function can be invoked by primary AND line command. I'm usually all for flexibility, but I think that FM is perhaps unnecessarily confusing to, especially new, users. And the sheer variety of ways of doing the same thing leads to complex line command naming because the 'natural' choice of letter is already taken. I respectfully suggest that a little simplification and standardisation, combined with a common look-and-feel to the EDIT sessions might make FM less cluttered and more intuitive to use.
Examples:
Line commands 'S/SS' (Select) is currently used to select entries in a few certain circumstances. I suggest it should be the default 'select entry' marker for primary-only commands. Where relevant, you could allow any valid primary command to select its entries with 'S'. Line commands DFA/DFB (yes I know I suggested these, but I've changed my mind) are not needed. Outside FM, DIFF is a primary-only command. So remove DFA and DFB and simple allow two 'S' line commands together with primary DIFF to select the protagonists. Line Command PURGE and its odd abbreviations. PURGE is potentially very destructive. I reckon it is also quite rarely used and thus an ideal candidate. Change it to a primary-only command, only abbreviation PUR, and select the file entries with 'S' line commands. Line command 'C' (commonly understood to mean copy) is currently only used to select entries in conjunction with primary command CUT. That already fits this proposed new structure, albeit by using the 'C' line command for entry selection. Allow 'S' as well and retain 'C' for compatibility. Because 'C' without CUT has no current meaning, it can be used without CUT to mean CLONE. Better still, we could also replace CLONE with COPY. Other possibilities for primary-only commands MULTIEDIT/MEDIT to use 'S' to select entries. MAKELIST to use 'S' to select entries. .Profile-Name, %iMacro-name, /Xform-name primary entries to use 'S' to select entries. I also wonder if frequently used line commands should have single-character invocations and less frequently use ones use two-chars, eg: - 1-char commands for Browse, Copy, Delete, Edit, Job-Submit, Lines, Open, Print, Rename, Select, Touch, View - 2-char commands for Add to Fav, Bac Kup, FOrget, FProperties, Multi Edit, Re Store, EXclude - Long line commands DIR, WDIR You may wish to retain " X" and " F" as single commands for compatibility. Other possibilities for line-command rationalisation Do we need both FORGET and EXCLUDE? To make the " PFK Help Line display" at the bottom of the FM screen easier to read, it would be helpful if it showed commands as above, ie: - with 2 blanks between each entry - with the 'trigger characters' in a contrast colour - perhaps use OPTIONS SCREEN "PFK Help Lines" column 'BG2' colour to 'lift' the trigger chars. - Would it fit better on the (narrower) displays if you used the smaller font, as deployed for the bottom STATUS line?
|
|
|
|
Post by George on Apr 2, 2021 9:01:17 GMT -5
Stefan:
All good suggestions. I'd like to hear from others as this is a significant change.
George
|
|
|
|
Post by George on Apr 2, 2021 14:14:53 GMT -5
All: You know I believe there is a lot of de-clutter that could/should be done. Way back we went on a 'make sure we're ISPF compatible kick" and added a bunch of stuff to 'be more compatible'.
I'm not convinced that's even needed any more, I think SPFLite can stand on it's own, with its own command set. e.g do we really need to support (and document) that you can do a Browse with BROWSE or B or BR or BRO? Or Exclude with EXCLUDE or EX or EXC or X?
They're individually nits, but it is just clutter, and frankly I doubt if some of these aliases are ever used. BROWSE/B and EXCLUDE/X are more than sufficient. And these aren't the only examples. We recently had EDITSET/EDSET show up which I'm sure we have all forgotten about or never, ever used.
Alternate ways to do things are not always bad, but like Windows, where almost everything can be done in multiple ways it can just be confusing. Although her vision no longer lets her use a computer, I can remember struggling to explain to my wife how simple stuff like Cut/Paste were done.
Well, you can do it like this, or you can do it like that, or you can ..... and getting the blank stare back that says "You've got to be kidding!"
I think we should be striving to avoid that.
George
|
|
|
|
Post by George on Apr 2, 2021 14:24:51 GMT -5
Another comment on Stefan's initial post.
I've tried to stress this in the past, the FM display and it's support are totally separate from the support provided to Edit sessions. We've tried to make it 'sort of' the same, but it is all unique code.
So requests for niceties like interaction between S type line commands and Primary commands is not just a case of some minor variation of current support. Nor are requests to move lines with some equivalent of M / A line commands.
FM is its own world, what's possible in an edit session can be very difficult to provide in FM.
George
|
|
|
|
Post by Stefan on Apr 3, 2021 4:41:44 GMT -5
George,
Line entry selections I did consider the command-related selection syntax. For CUT (and potentially COPY) primary command, C/CC may be appropriate, but only to keep with the 'de facto' standard from EDIT. One could add line selection commands that 'mirror' their respective primary command, e.g. PURGE would select entries with P/PP, but that quickly leads to confusion. MAKELIST using M/MM! That says MOVE to me. Not nice!
SPF CompatibilityI agree that a lot of ISPF/PDF 'compatibility' is probably unnecessary. In over 40 years of working with everything from SPF to ISPF/PDF to SPF/PC to SPFLite, I have NEVER typed BROWSE, EDIT, FIND or CHANGE, etc. in full in the normal flow of things. However, I DO use the full command name in preference to the abbreviation for better documentation purposes in macros. I suspect most users would accept the concept of the full command name plus one abbreviation. BUT - and I stress this because it is important and really useful (and works despite what the Help doc suggests) 1) I do use ALIAS overrides for the abbreviation, e.g I have an ALIAS for 'L' defined as "LOCATE TOP" and I can still execute standard 'LOCATE' as well. 2) I have macros called the same name as the abbreviation for a primary command to enhance that primary command. The macro invariably has to call the standard primary command at some stage and that call uses the full command name, ie. effectively providing the ISPF 'builtin' concept. Conflation ('look the same should be the same') I support Robert's 'look the same should be the same' concept. I think the fact that FM 'looks the same' as EDIT is a good thing. And I think that re-using commands that do logically the same thing (e.g. CUT) is a good principle. (I considered that the MAKELIST capability could be provided by an extension to CREATE/REPLACE eg: CREATE/REPLACE FLIST name APPEND SYM options. Afterall FLISTS are just files like any other, albeit 'SPFLite-internal' files. You could even expand the concept to other 'internal' file types, like AUTO, MACRO, etc to avoid casual users having to poke about in the SPFLite 'Home' folder. Hee hee - I can already hear your objection that CREATE/REPLACE already contain complex coding).
FM may be coded completely separately to EDIT, but the user does not 'see' or care about that. (And in my opinion they SHOULD NOT see or feel that). If FM appeared completely alien to EDIT, there would be little point in having FM at all. You could achieve much of FM's features with a MENU (or two) extention for Windows Explorer and pass stuff from there into SPFLite via messages or OLE, with the added benefit that 'Explorer FM' could appear alongside EDIT in a separate window.
For users unfamiliar with ISPF, that may be much more intuitive, but they probably don't feel entirely comfy with SPFLite's EDIT appearance either. You know where I stand on that idea, given that I operate SPFLite with what is basically a 'green on black' scheme on steroids!
|
|
|
|
Post by Stefan on Apr 3, 2021 6:17:06 GMT -5
Robert, I get the impression that you're comfortable with additions to SPFLite but really do not like CHANGES to the product. Maybe that explains your mostly negative arguments.
My post is intended to flush out opinions and counter-proposals and you put a fair amount of effort into your initial reply so I'll retort, if only to explain my reasoning in more detail.
(1) Where did I suggest that this doesn't need planning. This post is intended to encourage discussion. I'm not making policy here, I'm suggesting things that may be useful. (2) I didn't ask questions, except possibly in the very last line. (BTW, I think the tone of point (2) is inappropriate). (3) I didn't 'force' anyone to do anything. The DEFAULT command does not overrule everything else. The whole distinction between 'E' and 'S' and the DEFAULT command is one of the very things that are, shall we say, sub-optimal and, to use your words, 'conflating' in FM. (4) Your '...better idea...' appears to be a choice between do nothing or a complete rewrite? I leave it up to George to assess the effort involved and weigh up the cost/benefit ratio. The suggestions are about improving the user experience and everyone has a vote. Ultimately the only one that counts is George because he knows what is practical and what is impractical and at what cost. We all know from experience that code that grows organically over time, becomes increasingly hard to support. (5) I didn't say 'S/SS' for Select would be 'better'. I suggested it should be the default for selections to be consistent. I also said that we should retain 'C/CC' in some cases to maintain compatibility with EDIT. (Even though the OCD in me always cringes because C/CC is the only acceptable method for line selection in MACROS. Certainly no compatibility with ISPF there.) (6) A excellent point! I admit, I forgot about the need to scroll the page to enter more 'S' selections. The current function assigned to 'S' will have to be changed to a different letter as it is the only line command that would have a double meaning in the new scheme. But as mentioned above, the distinction between 'S' and 'E' which gave rise to the DEFAULT primary command is a pain anyway. (7) It's not about protection. It's about the benefit of the command as a whole. It just DELETE bypassing the Recycle Bin. I contend it really isn't needed. Users who don't like the Recycle Bin, probably disable it via the Recycle Bin properties anyway. And who deletes files to regain disc space these days? Even if they did, it wouldn't kill them to 'Empty Recycle Bin" after typing DELETE. Thus PURGE is a rarely used and quite possibly completely superfluous command which uses the, unintuitive, 'U' abbreviation, thereby preventing yet another letter from being deployed for a more frequently used command. (8) Counter proposal welcome! But I think it is a patch over the legibility wound but doesn't heal the injury. There is a reason why the "PFK HELP" display appears last in my post. Basically, I believe we should not need it at all. Why is it there today? The most likely answer is "the commands were once perceived as too unusual to be remembered". This exactly is what we're seeking to address. We have many more line commands in EDIT than in FM. And we don't have a 'line command help display' at the bottom of the EDIT screen. So I think that with a bit of command simplification and synergy with EDIT, the chances are good that most users will simply turn off the display in the OPTIONS FM setting to regain 3 lines on the FM display. But if an 'FM aid memoire' must remain, it should be clearer (not necessarily just larger). (9) I have no idea. I don't use either. That said, I support 'X' to exclude (ie. temporarily Hide) entries that re-appear next time. That is totally consistent with 'X' in EDIT. I have issues with FORGET. If there's an entry in in a file directory then I WANT to see it. What use is a File MANAGER that doesn't show me ALL the files in a folder/directory. If we're talking about a file-list based on an FLIST, I edit the FLIST in question to remove the entry. There is only two FLISTS where that wouldn't work because SPFLite keeps changing them, 'Recent Paths' and 'Recent Files'. I figure 'Oh Dear, How Sad, Never mind'. My issue with FORGET is that if I subsequently use NORM to tidy up the FLIST, it will also remove the 'forgotten' entries. And, at the risk of paraphrasing ex-President Clinton, I wouldn't remember that I forgot files earlier).  |
|
|
|
Post by George on Apr 3, 2021 10:44:34 GMT -5
Just to clarify FORGET in 2.4, as it seems to be slightly misunderstood.
In 2.4 FORGET is handled differently than in 2.3.
FORGET can only be used when an FLIST is displayed (Recent Files, Recent Paths, private FLISTS)
You can no longer 'forget' an line item created from a generic folder scan, like you could in 2.3, you can only forget specific entries. This means you no longer have to Edit an FLIST to remove an entry. But you can no longer do a RESET to reverse a FORGET operation.
George
|
|
|
|
Post by George on Apr 3, 2021 12:00:04 GMT -5
OK, no particular order here, but a list of what might be done: - General removal of extra FM primary command aliases BOT BROWSE BRO DEF ED EX EXC KEY KBD KEYS LOC ML XSUB
- General removal of extra FM line command aliases ADD BRO BROWSE BACKUP BACK CANCEL DEL DELETE DFA DFB EDIT FORGET FPROP JOB SUBMIT KLONE LINE LINES MEDIT NORM OPEN OPENV OPENB PRINT REN RENAME RESTORE RESTORET SEL SELECT TOUCH VIEW
- Remove FM PURGE command entirely.
- Remove FM Help lines, enable a Pop-Up window to display command summary.
- I'm open to using S as a general line select to use with FM Primary commands, but due to it's prior use, to invoke the DEFAULT function (Edit) I have to wonder if it will cause confusion. Maybe the DEFAULT itself should be removed, I know I've never used it.
- I agree that for CUT it should accept C/CC as well as S/SS. (just for familiarity).
- Not all FM Line commands have an equivalent Primary command, like CAN, should they? To be consistent? If so, what about END which has a unique meaning already as an FM Primary command?
Comments?
George
|
|
|
|
Post by Stefan on Apr 4, 2021 3:46:52 GMT -5
George,
Quick answers from my perspective (YMMV): Abbreviations: If we abandon the initial "100% ISPF compatibility" requirement, I cannot immediately see why any (EDIT or FM) primary command needs more than one abbreviation - discuss! DEFAULT S/E: I don't use it either. I don't understand why it is needed.
- PURGE removal: Agreed.
- Should all line commands have a primary equivalent: I reckon NOT. More code complexity for potentially very limited return, but possibly useful for selected commands. But any command that doesn't do what the user expects, should not have the same name as the 'common' function for that name. I'm unclear why you classify END in that context. Note that I'm approaching this from a 'user experience' perspective. The user does not 'see' (or care) how different the code is for the FM-version to the EDIT-version of a given command. If they (like me) perceive 'END' to mean 'complete current activity and take me back one level', then END is the right command, even if the code in FM is very different.
Apologies, I can't deal with the line & primary command aspects of this at once (Easter beckons), so let me start with thoughts on improving the user experience for...
FM Primary commands(I've taken this from the HELP DOC's FM Primary commands commands section. There may be undocumented others!)From the user perspective, the primary commands available in FM fall into 3 broad categories:
a1) Those that work anywhere in SPFLite, ie. they operate independently of on-screen data. Users expect these to have the same syntax, abbreviations, etc as they do in EDIT. BOTTOM, BROWSE, CLIP, CLS, CMD, CRETRIEV, DEFAULT, DO, DOWN, EDIT, END, HELP, KEYMAP, NOTIFY,
OPEN, OPTIONS, PRINT SETUP, PROF, RECALL, RESET, RETF, RETRIEVE, SET, SWAP, TOP, UP, VIEW, XSUB
(For the most part, these shouldn't need much if any changes)
a2) Those that work anywhere in SPFLITE, but operate slightly differently in FM Users expect these to have the same syntax and abbreviations but with 'context-relevant' operand differences. EXCLUDE, FIND, FF, LOCATE, RFIND (Except for tiying abbreviations, these shouldn't need any changes) b) Those that are specific to FM and require command-line operands and/or line selections CLONE/COPY, MAKELIST, MEDIT (Aside from adding an 'ALL' operand to MAKELIST and MEDIT, these may need little change)
c) Those that are specific to FM and require line selections to be supplied CUT, DIFF, plus any 'line commands' which you think would be useful as primary command plus S/SS selections (Slight change to DIFF, CUT is already done, any extras you wish to add)
I found some odd things while making this list. - ALL is a primary command that executes the same line command against all entries. This must be a relatively rare event. There are few line commands that do not prompt the user for info. And with the ability to select multiple entries with 'S/SS', I suggest that the ALL command is no longer needed. To be consistent with EDIT, I propose we add an 'ALL' operand to any relevant primary command. Example: ALL MEDIT would be replaced by MEDIT ALL That's consistent with EDIT. - FF clashes with EDIT's FF abbreviation for FIND and the HELP DOC clumsily tells users not to confuse them (same for FIND by the way). I think FM's FF could be called FiF (more sensible) with an FF abbreviation for backward compatibility (if deemed necessary). EDIT's FF should be abolished as I'll bet 99.9% of users use 'F' to abbreviate FIND in EDIT.
At first glance, you can see that, on the primary command front, there is (I think, but you judge) relatively little code that needs changing).
Sorry George, but this is as far as I've got before family duties take me away. I'll expand my thoughts when I get more time.
HAPPY EASTER (...and don't spend all of the weekend coding!)
|
|
|
|
Post by Jo on Apr 4, 2021 18:19:20 GMT -5
I'm not as young and agile as you all, so please do not change too much, my memory is ....
Jo
===> Me too, Jo, my own memory is not as good as it used to be, at least not that I recall  - Robert |
|
|
|
Post by George on Apr 5, 2021 12:05:52 GMT -5
Guys: I don't plan on anything much at all right now, I really want to get 2.4 out-the-door. This kind of cleanup, while I think it's worthwhile, takes time to track down all the bits and pieces, and worse than that is doing the same through the documentation.
You'd be amazed at how out of date some parts of the Doc have been. I stumbled on all kinds of "Ooh! Obviously forgot to update THAT item."
George
|
|
- Robert