|
|
Post by Stefan on Mar 30, 2022 17:27:02 GMT -5
The recent changes to the RESET command appear to be a little too draconian.
A plain RESET command without any operands, now also removes
- Retained line commands, e.g. C&5 Should not be removed according to help doc "Extended Line Command Modifiers" section, sub section "Retain line-command modifier".
- Line handles - Are STATE-saved so removing them is counter-productive. Should be kept according to "Working with line Handles" subsection "Internal Properties". |
|
|
|
Post by George on Mar 31, 2022 9:41:43 GMT -5
Guys: Well I just compared the current Reset code to that in 21186. The only change I see is a minor 1-liner related to resetting the FIND Hi-Lite.
So I'm unclear what 'draconian' change has taken place. Whatever is happening has been happening that way for a long time. Still, it's not correct, so I'll go have a look.
George
===> I agree. It may be a bug, but "draconian" should be reserved for bugs that delete the Master Boot Record on the C: drive.
R
[UPDATE]
Corrected. It has to do with handling RESET commands issued by the user, and internal RESET commands issued by other parts of the code. The RESET COMMAND is actually two flags, and the code was mis-handling them.
But this IS a very old bug, not recently created.
George[/UPDATE]
|
|
|
|
Post by Stefan on Mar 31, 2022 11:36:02 GMT -5
George,
I offer my most sincere apologies for the use of the word 'draconian'. I meant no disrespect.
Staying with the RESET subject and the concept of words, I just tripped over the inclusion of the WORD operand in the scope for RESET ALL. After some head-scratching to diagnose some sudden odd behaviour, I started wondering if WORD should be a feature of the RESET command at all.
The WORD scope is a PROFILE item, in that it is saved there and closely related to the 'grammar' of a particular filetype's 'language'. E.g. some languages (e.g. REXX, BASIC, etc) allow underscore in variable names and other terms and thus _ must be within the WORD scope for those. As a PROFILE item, it is user-managed just like the other PROFILE settings. I wouldn't expect RESET to affect the EOL settings either.
If WORD must remain a part of RESET, perhaps it should be treated like RETRIEVE and require a deliberate effort (RESET WORD) to reset its value.
|
|
|
|
Post by George on Mar 31, 2022 12:08:31 GMT -5
Stefan: Good catch. I wasn't even sure at first what RESET WORD was supposed to do.
It has now been altered to be exempt from ALL (it was before, but handled poorly) I've also added SOURCE and HIDE to the same handling.
George
|
|
|
|
Post by George on Mar 31, 2022 14:20:37 GMT -5
Robert: RESET WORD was not part of the RESET ALL, but was logically handled poorly internally. Now corrected.
George
|
|
|
|
Post by George on Mar 31, 2022 14:33:30 GMT -5
Robert: Got it.
|
|
|
|
Post by Stefan on Apr 2, 2022 8:03:27 GMT -5
(BTW, I do the plain RESET so often that I have an alias for it: SET ALIAS.RE = RESET Robert,
That made me smile as I can't type RESET either, it always ends up as REST! Luckily I can type RES, which SPFlite provides as abbreviation for RESET.
I can't type SAVE reliably either, so I have a SET ALIAS.asve = SAVE definition!
|
|
|
|
Post by Stefan on Apr 18, 2022 6:37:55 GMT -5
Stefan: Good catch. I wasn't even sure at first what RESET WORD was supposed to do. It has now been altered to be exempt from ALL (it was before, but handled poorly) I've also added SOURCE and HIDE to the same handling. George Hi George,
I only just noticed that you mentioned SOURCE.
RESET SOURCE does indeed work, but it isn't a documented operand.
A little doc change the next time you're in the vincinity of the documentation.
You also mentioned HIDE.
I haven't paid much attention to HIDE before, but actually find it quite useful, especially in combination with NEXCLUDE (NX) and the 'S' (show) line commands. Hence I wonder why the HIDE status is not a part of the PROFILE settings, rather like COLS ON, TABS ON or MARK ON, etc.
|
|
|
|
Post by Stefan on Apr 18, 2022 12:09:58 GMT -5
Robert, Thanks for the explanation. I'd completely forgotten that HIDE was even a 'thing' with ISPF. (Memory can be dodgy thing!) I thought about an IMACRO, but decided that a KEYMAP was a more flexible way to go. So I mapped a key with
(SaveCursor)(Home)(EraseEol)[MyHIDE](Enter)(RestoreCursor)
and used a MyHide.Macro below to toggle the HIDE value. Works a treat.
' MyHIDE.MACRO
'-----------------------------------------------------------------------------------------
' This is Edit Macro myHIDE (Version 1) Stef 18/04/22
' This macro TOGGLES the ON/OFF state of HIDE.
'-----------------------------------------------------------------------------------------
LOCAL AS NUMBER myRC
LOCAL AS STRING hStat$
hStat$ = Get_SETVar$("MyHIDE") ' Obtain current HIDE Status
IF hStat$ = "" OR hStat$ = "OFF" THEN ' If none found, OR status is OFF
hStat$ = "ON" ' Set it ON
ELSE ' Else
hStat$ = "OFF" ' Set it OFF
END IF
SPF_Cmd ("HIDE "+hStat$) ' Implement desire state
myRC = Set_SETVar("MyHIDE",hStat$) ' Create/Update MyHIDE SET variable
IF myRC <> 0 THEN Halt(WARN,"Unable to store HIDE Status")
Halt(OK,"Hide is "+hStat$)
|
|
|
|
Post by George on Apr 18, 2022 14:20:28 GMT -5
Robert: I remember (well, I think so ...) in the past we did a 'cleanup' of this kind of thing to normalize what was done.
It's not that fixing things is difficult, it's the slow process of going through each command, possibly tweaking it, and then (ugh!) reviewing the Doc. to make everything agree.
Yes, a make work project.
George
|
|
|
|
Post by George on Apr 19, 2022 9:27:07 GMT -5
Robert: I had thought at one point about replacing all the ON/OFF type settings with one command:
TOGGLE xxxx
After all, a PROF display shows everything, QUERY is available for a single item (or macro). It would discard a lot of command code and reduce the Doc. as well.
But then, it's not ISPF compatible. (Do we really, after all this time, still make that our Credo?)
George
|
|
|
|
Post by George on Apr 19, 2022 12:41:43 GMT -5
Robert: If I did anything, it would be to make them all toggles, with the message indicating the new state. Maybe I could modify the command table to send them all to some common code to do the work, rather than individual chunks of code.
George
|
|
|
|
Post by George on Apr 19, 2022 13:59:25 GMT -5
There's a lot of stuff Query handles that isn't simple ON/OFF, like AUTOSAVE, BNDS, CAPS, CHANGE, EMACRO/IMACRO, ENUMWITH, EOL, etc, etc.
George
|
|
|
|
Post by George on Apr 19, 2022 15:41:27 GMT -5
Robert: The period and ? options are nice and simple alternatives. But having them appended to the command is a bit more of a problem, as the basic parsing is word (blank delimited) style. I'm not sure HEX . or HEX ? are as nice. (Although it's not a show-stopper) But then maybe a parse kludge can turn XXX. into xxx . and pass it on.
George
|
|
|
|
Post by Stefan on Apr 20, 2022 6:52:09 GMT -5
For what it's worth...
(1) I've never used the QUERY command.
(2) I don't recall the last time I wanted to query a status "in the run of play", but that's probably more important in a macro which may wish to set something and later return to the original setting.
I wonder how many macros out there in the wild would need changing. My guess is that most folks would cope with such changes easily, especially if the change is 'simple', eg. replace SPF_CMD("HIDE") with SPF_CMD("QUERY HIDE") (or ?Hide or whatever <char> you choose)
(3) Users would get used to the toggle effect if <command> is entered without operands, but I would caution against a toggle if the command has more complex options than a simple ON/OFF.
As Robert said, what do you do about the 'extra' part, e.g. AUTOSAVE [ON | OFF] [PROMPT | NOPROMPT]
(4) On my UK (Lenovo) keyboards, the following are all available without SHIFT. \ , . / # ' ; ] [ ` = - and these need SHIFT (but the first 4 are easily reached one-handed anyway) : @ ~ ? > < } { + _ | ¬ ! " £ $ % ^ & * ( )
(5) I'd prefer the syntax <command><blank(s)><char> to just <command><char> , where <char> is a . or / or ? or whatever you chose, but I appreciate this is perhaps trickier to parse. If there is to be no blank(s) between them, I'd vote for the syntax <char><command> e.g. ?HIDE
(6) I have been wondering for a while about how close SPFLite should remain to ISPF.
I believe that adopting a 'looser', perhaps more logical, approach is difficult at this, comparatively late, stage in the game. How many users still have access to, or actively use both? And many who only use SPFLite, tend to be we older folk, dyed in wool and glad we don't need to re-learn everything we thought we knew.
One would have to maintain the 'old' syntax alongside the 'new' syntax, which only serves to make the code, maintenance and documentation more complex. (And I always disliked products made complex by offering serveral different ways to achieve the same result)
I think we're stuck with the way it is, and by implication therefore also constrained in the manner new 'features' are implemented.
(7) Returning to the ON/OFF toggling debate, I guess it affects mostly PROFILE settings. I always thought that IBM's implementation of the PROFILE concept via a myriad of separate commands for the settings was 'clunky'. Probably driven by growth over time, some settings have a command, some have a line command, some have both, some are inherited from the file, etc. There's no single 'PROFILE Settings' management capability. The =PROF=> lines are 'read-only', but =TABS=>, etc are not, etc. It's messy.
SPFLite tries via FM - CONFIG, but one still cannot enter/maintain all profile settings in one place.
As I said, I think we're stuck with it. Maybe the easiest way, path of least resistance if you wish, to integrate TOGGLING into the whole package, is to add a 'TOGGLE' (or 'FLIP') operand to each affected command. That way we 'extend' the existing user interface to 'enhance' the product. And as you guys already said, there is plenty of 'precedent' for that approach already.
|
|
