Post by Robert on Sept 23, 2023 13:14:52 GMT -5
This idea is an outgrowth of the prior post about the MACLIB feature. Since the comments below are lengthy, it's better to pull them out of the MACLIB discussion.
Currently, MACLIB is an attribute of a PROFILE. As such, it only is in effect for a file having a non-default MACLIB setting. That can be good and bad.
The "good" part is that when multiple Edit tabs are open, each tab could potentially have a different MACLIB. That offers a lot of editing flexibility.
One "bad" part is that it doesn't work in FM. FM must use the default macro library, which is located in the SPFLite MACROS folder under the config folder - a global setting. But more to the point, the MACLIB design doesn't fully address the reasons why someone would want to use it in the first place.
To give a real-world example, I have some specialized files that define dead-key tables in a keyboard definition. The keyboard itself is complex, having over 3,600 unique symbols, and is multi-lingual, allowing 'native' keying in Latin, Cyrillic and Greek. To allow this, I need to post-process these definition files with some tricky macros. The macros get periodically changed, and I want the 'current' versions to get backed up when I back up my project. Without MACLIB support, there is no easy way to do this without backing up my entire MACROS folder, a thing I don't want to do. So, I appreciate having MACLIBs.
But, I need more than just access to MACLIBs. When I resume work on my project, I need to do other things too, like:
- Get the FM File Path list to show the main folder where my project is in, and make sure it's displaying in the right order
- Run a large macro that loads a list of Unicode definitions (many thousands of them) into global macro storage
- If there were a way to define the global default MACLIB without changing the SPFLite config folder (mine is C:\Users\Owner\Documents\SPFLite\ ) then when I resume working on my project, then I would like to issue an FM MACLIB command to set it as needed.
(P.S. Right now, there IS no such FM MACLIB command. But, I believe this is a natural outgrowth and will show up, sooner or later.)
- Perhaps I need to define special-purpose SET values that I only need temporarily. Right now, SET values are permanent, global values within an instance. If I wanted to 'restore' a prior SET value, there is no way to do that, except by perhaps defining two macros, one for the list of 'normal' SET values, and one for the 'special-purpose/temporary' Project values.
Performing such project-related "setup actions" is what I had in mind when I first mentioned the idea of a PROJECT, which then got framed in terms of an enhanced implementation of INSTANCE. But, George didn't like the idea of making changes to INSTANCES, as the current implementation is evidently tricky and fraught with difficulties.
Further, what I have in mind probably doesn't fit into the INSTANCE architecture either - even if George could make them dynamic, which seems unlikely at this point.
Well, what DID I have in mind? When a user basically does the same thing with SPFLite all day long, there is no real need for "projects", and maybe not INSTANCES either. All you'd need to do then is to set your global defaults and go. I personally only run with the default instance myself.
But, suppose you are involved with multiple projects, each of which had different, possibly conflicting resource requirements. It would be nice if 'project setup values' and 'default initialization macros' could be 'packaged' in one place. There are, in fact, languages that use the term PACKAGE to collect together a set of common resources, which are usually stored in a library of some kind. One example of that is JAVA. Other languages use concepts such as "NAMESPACE" for a similar purpose.
However, in the context of an editor, terms like PROJECT, PACKAGE, NAMESPACE and even INSTANCE can be kind of geeky, and even if people liked one of those names, editing activities are not nearly as rigid, disciplined or formal as writing a program. And, most users performing editing tasks value flexibility above all.
Instead, when we start editing something, there may be some overriding reason just WHY we are doing so. If it's part of a regular editing activity, what we do most often would likely be something we'd call a TASK. A "task" in SPFLite should be thought of in its most general sense: a "bunch of stuff" we frequently need to do at the same time. When that "stuff" is needed, as a rule, just after startup, we would call it a type of "setup" or "initialization".
[ SPFLite supports a Windows command-line option of -DO to run keyboard-macro commands at startup. In a sense, this is "somewhat" like a task, but it only runs at startup, and has other limitations. ]
Right now, our initial editing "tasks" are most likely done manually - startup steps that we just remember and "know".
Is a TASK the same thing as a macro? As of this writing, I don't know, but I suspect the answer (for the moment) is NO. I say NO because initialization activities that might be needed for a task could include things that can't be done in a macro. Why not? Consider the kinds of changes you can make in the Global Options GUI. A very few might be settable via a macro, but most are not.
But, it isn't just the lack of macro capabilities at issue. Go back to my comment above, where I said there ought to be a way to set the (FM) global MACLIB without changing the location of the config folder. Even if a macro allowed you change that global MACLIB (assuming there was one in the first place), that change would still be a permanent, global one.
But, requiring permanent, global changes for fleeting, intermittent tasks, seems like overkill. I'd really want any setting made in the course of setting up a TASK to be temporary.
How could a temporary setting be made? The most logical way to implement that is to have any TASK settings and values be stored in a "stack" fashion.
Here is an EXAMPLE. Suppose I need a SET value for a TASK, like this:
SET ABC = DEF
But, assume the "normal" value of ABC is XYZ. If I go in and override ABC, then later I would have to restore it, or otherwise I just broke the SET value for ABC and it's lost. And, let's say I really don't want to lose it.
I don't want to get into concrete implementation specs here, because it's too soon. But, let's say that a TASK is some kind of 'resource' that is macro-like or script-like, and it has some kind of name, known as its TASK NAME.
Within a task, commands that change 'global' resources (like SET) would be temporary. The "temporary-ness" of such commands would be enforced by dividing the list of SET values into two parts: The "permanent" part that currently exists, and the temporary part that is stored in (a "stack"?) memory somewhere, if/when this TASK concept were implemented. When a SET value is defined or altered within a TASK, its value goes into the temporary, TASK settings.
How "temporary" is a temporary TASK setting? TASK settings go away:
- At SPFLite shutdown
- At the start of another TASK
- At the end of the current TASK. This would require some kind of command like TASK END or something.
Making task setting "go away" would amount to "popping the stack" of those task values. When functions like grabbing a SET value are then run, the 'stack' would only contain the global values, so the 'standard' global SET values would be effectively 'restored'.
If my TASK activities are enabled, but I wanted to change a SET value permanently, what then? I don't know yet. Maybe SET values are only set temporarily within a "task script" (whatever that would be). Or, maybe we need a variant of the SET command, like "TASK SET". These are questions that will work themselves out over time.
Probably the biggest question users will have at this point is, Why would I want to use a TASK? If all you do is open a text file, change a few lines, and exit, you are unlikely to need a task. So who would? Someone with elaborate editing requirements, who is using SPFLite in conjunction with some major undertaking. George, the author of SPFLite, is probably such a user. People who use SPFLite in a multi-node networking environment (Stefan?) and/or perhaps in conjunction with Hercules and MVS or z/OS may also be such users. Maybe we have SPFLite users out there that use the editor as part of their business, and they have business-related tasks they would like to automate.
The biggest impact of implementing TASK, aside from the usual work of creating primary commands and so on, is changing instances of 'resource searching' so that any resources that could have temporary TASK settings would search the temporary values first. That could potentially be a big change, and so, it is envisioned that supporting TASKs would have to be done in a phased implementation. There is also the question of whether a TASK would be a macro, or some new script or resource that could itself refer to macros. That part I don't know as of now.
However a TASK is handled, my intent is that the activation and use of a TASK *should* impose very minimal runtime overhead. For instance, finding a temporary SET value would require searching of two SET lists - the temporary one and the permanent one. It is likely that most users don't have very big SET lists. I have used SPFLite pretty much from the beginning, and my own list has just 100 entries, most of which are alias definitions. So, checking an extra list shouldn't slow things down much.
I don't want to give the impression that a TASK is only used for temporary SET and MACLIB definitions. I discussed these only to provide concrete examples. Are there any more possible examples? Well, let me try this:
When SPFLite starts up, and you enable the correct check box in the global options, the list of files that were open the last time SPFLite was closed will get reopened. That is a valuable feature, because it "reestablishes the editing context". That way, you don't have to manually locate and open each one of the files you were working on. The same principle applies to STATE values, which save the editing context of a file when its profile has STATE ON defined.
[ Hopefully, you can see by now that the underlying intent of a TASK is a formal, systematic way to "reestablish an editing context". ]
Now, suppose you had more than one "list" of files, and let's say each list was associated with a TASK. Then, when you started a task, all the files in the "TASK Open-List" would get opened, because having access to those files would be part of your "task" - the "bunch of stuff" you need to do to "get going already" with the work you need to do.
Suppose you had some OTHER files open, as a result of some previous TASK that you started? If so, starting a new TASK would (likely) close the current set, to make room for the new ones.
I will repeat that this is an EXAMPLE of a "task activity". It would be much harder to implement then having temporary SET values, for instance. And, any particulars of how this actually worked would have to be carefully planned out.
I foresee that, as experience with the concept of TASKs grows, new uses for task activities will evolve over time. That follows the learning curve for SPFLite itself. George, you called your editor "LITE" because (I think) you saw your editor as a poor, wimpy imitation of the "big boy" ISPF from IBM. Well, it's not wimpy any more. It's serious business, but it took years to get here.
I don't want to create a large, hypothetical list of possible uses of TASKs, because that would constrain our users' imaginations, and we don't want to do that.
Instead, I ask that you all USE your imaginations. Ask questions. Draw on your own editing experiences, especially you users that are into heavy-weight, complex activities. What sorts of task automation could help you, things that are not strictly 'instances' or 'macros'? That is what I envision this TASK idea as being able to help.
Comments invited.
R
Currently, MACLIB is an attribute of a PROFILE. As such, it only is in effect for a file having a non-default MACLIB setting. That can be good and bad.
The "good" part is that when multiple Edit tabs are open, each tab could potentially have a different MACLIB. That offers a lot of editing flexibility.
One "bad" part is that it doesn't work in FM. FM must use the default macro library, which is located in the SPFLite MACROS folder under the config folder - a global setting. But more to the point, the MACLIB design doesn't fully address the reasons why someone would want to use it in the first place.
To give a real-world example, I have some specialized files that define dead-key tables in a keyboard definition. The keyboard itself is complex, having over 3,600 unique symbols, and is multi-lingual, allowing 'native' keying in Latin, Cyrillic and Greek. To allow this, I need to post-process these definition files with some tricky macros. The macros get periodically changed, and I want the 'current' versions to get backed up when I back up my project. Without MACLIB support, there is no easy way to do this without backing up my entire MACROS folder, a thing I don't want to do. So, I appreciate having MACLIBs.
But, I need more than just access to MACLIBs. When I resume work on my project, I need to do other things too, like:
- Get the FM File Path list to show the main folder where my project is in, and make sure it's displaying in the right order
- Run a large macro that loads a list of Unicode definitions (many thousands of them) into global macro storage
- If there were a way to define the global default MACLIB without changing the SPFLite config folder (mine is C:\Users\Owner\Documents\SPFLite\ ) then when I resume working on my project, then I would like to issue an FM MACLIB command to set it as needed.
(P.S. Right now, there IS no such FM MACLIB command. But, I believe this is a natural outgrowth and will show up, sooner or later.)
- Perhaps I need to define special-purpose SET values that I only need temporarily. Right now, SET values are permanent, global values within an instance. If I wanted to 'restore' a prior SET value, there is no way to do that, except by perhaps defining two macros, one for the list of 'normal' SET values, and one for the 'special-purpose/temporary' Project values.
Performing such project-related "setup actions" is what I had in mind when I first mentioned the idea of a PROJECT, which then got framed in terms of an enhanced implementation of INSTANCE. But, George didn't like the idea of making changes to INSTANCES, as the current implementation is evidently tricky and fraught with difficulties.
Further, what I have in mind probably doesn't fit into the INSTANCE architecture either - even if George could make them dynamic, which seems unlikely at this point.
Well, what DID I have in mind? When a user basically does the same thing with SPFLite all day long, there is no real need for "projects", and maybe not INSTANCES either. All you'd need to do then is to set your global defaults and go. I personally only run with the default instance myself.
But, suppose you are involved with multiple projects, each of which had different, possibly conflicting resource requirements. It would be nice if 'project setup values' and 'default initialization macros' could be 'packaged' in one place. There are, in fact, languages that use the term PACKAGE to collect together a set of common resources, which are usually stored in a library of some kind. One example of that is JAVA. Other languages use concepts such as "NAMESPACE" for a similar purpose.
However, in the context of an editor, terms like PROJECT, PACKAGE, NAMESPACE and even INSTANCE can be kind of geeky, and even if people liked one of those names, editing activities are not nearly as rigid, disciplined or formal as writing a program. And, most users performing editing tasks value flexibility above all.
Instead, when we start editing something, there may be some overriding reason just WHY we are doing so. If it's part of a regular editing activity, what we do most often would likely be something we'd call a TASK. A "task" in SPFLite should be thought of in its most general sense: a "bunch of stuff" we frequently need to do at the same time. When that "stuff" is needed, as a rule, just after startup, we would call it a type of "setup" or "initialization".
[ SPFLite supports a Windows command-line option of -DO to run keyboard-macro commands at startup. In a sense, this is "somewhat" like a task, but it only runs at startup, and has other limitations. ]
Right now, our initial editing "tasks" are most likely done manually - startup steps that we just remember and "know".
Is a TASK the same thing as a macro? As of this writing, I don't know, but I suspect the answer (for the moment) is NO. I say NO because initialization activities that might be needed for a task could include things that can't be done in a macro. Why not? Consider the kinds of changes you can make in the Global Options GUI. A very few might be settable via a macro, but most are not.
But, it isn't just the lack of macro capabilities at issue. Go back to my comment above, where I said there ought to be a way to set the (FM) global MACLIB without changing the location of the config folder. Even if a macro allowed you change that global MACLIB (assuming there was one in the first place), that change would still be a permanent, global one.
But, requiring permanent, global changes for fleeting, intermittent tasks, seems like overkill. I'd really want any setting made in the course of setting up a TASK to be temporary.
How could a temporary setting be made? The most logical way to implement that is to have any TASK settings and values be stored in a "stack" fashion.
Here is an EXAMPLE. Suppose I need a SET value for a TASK, like this:
SET ABC = DEF
But, assume the "normal" value of ABC is XYZ. If I go in and override ABC, then later I would have to restore it, or otherwise I just broke the SET value for ABC and it's lost. And, let's say I really don't want to lose it.
I don't want to get into concrete implementation specs here, because it's too soon. But, let's say that a TASK is some kind of 'resource' that is macro-like or script-like, and it has some kind of name, known as its TASK NAME.
Within a task, commands that change 'global' resources (like SET) would be temporary. The "temporary-ness" of such commands would be enforced by dividing the list of SET values into two parts: The "permanent" part that currently exists, and the temporary part that is stored in (a "stack"?) memory somewhere, if/when this TASK concept were implemented. When a SET value is defined or altered within a TASK, its value goes into the temporary, TASK settings.
How "temporary" is a temporary TASK setting? TASK settings go away:
- At SPFLite shutdown
- At the start of another TASK
- At the end of the current TASK. This would require some kind of command like TASK END or something.
Making task setting "go away" would amount to "popping the stack" of those task values. When functions like grabbing a SET value are then run, the 'stack' would only contain the global values, so the 'standard' global SET values would be effectively 'restored'.
If my TASK activities are enabled, but I wanted to change a SET value permanently, what then? I don't know yet. Maybe SET values are only set temporarily within a "task script" (whatever that would be). Or, maybe we need a variant of the SET command, like "TASK SET". These are questions that will work themselves out over time.
Probably the biggest question users will have at this point is, Why would I want to use a TASK? If all you do is open a text file, change a few lines, and exit, you are unlikely to need a task. So who would? Someone with elaborate editing requirements, who is using SPFLite in conjunction with some major undertaking. George, the author of SPFLite, is probably such a user. People who use SPFLite in a multi-node networking environment (Stefan?) and/or perhaps in conjunction with Hercules and MVS or z/OS may also be such users. Maybe we have SPFLite users out there that use the editor as part of their business, and they have business-related tasks they would like to automate.
The biggest impact of implementing TASK, aside from the usual work of creating primary commands and so on, is changing instances of 'resource searching' so that any resources that could have temporary TASK settings would search the temporary values first. That could potentially be a big change, and so, it is envisioned that supporting TASKs would have to be done in a phased implementation. There is also the question of whether a TASK would be a macro, or some new script or resource that could itself refer to macros. That part I don't know as of now.
However a TASK is handled, my intent is that the activation and use of a TASK *should* impose very minimal runtime overhead. For instance, finding a temporary SET value would require searching of two SET lists - the temporary one and the permanent one. It is likely that most users don't have very big SET lists. I have used SPFLite pretty much from the beginning, and my own list has just 100 entries, most of which are alias definitions. So, checking an extra list shouldn't slow things down much.
I don't want to give the impression that a TASK is only used for temporary SET and MACLIB definitions. I discussed these only to provide concrete examples. Are there any more possible examples? Well, let me try this:
When SPFLite starts up, and you enable the correct check box in the global options, the list of files that were open the last time SPFLite was closed will get reopened. That is a valuable feature, because it "reestablishes the editing context". That way, you don't have to manually locate and open each one of the files you were working on. The same principle applies to STATE values, which save the editing context of a file when its profile has STATE ON defined.
[ Hopefully, you can see by now that the underlying intent of a TASK is a formal, systematic way to "reestablish an editing context". ]
Now, suppose you had more than one "list" of files, and let's say each list was associated with a TASK. Then, when you started a task, all the files in the "TASK Open-List" would get opened, because having access to those files would be part of your "task" - the "bunch of stuff" you need to do to "get going already" with the work you need to do.
Suppose you had some OTHER files open, as a result of some previous TASK that you started? If so, starting a new TASK would (likely) close the current set, to make room for the new ones.
I will repeat that this is an EXAMPLE of a "task activity". It would be much harder to implement then having temporary SET values, for instance. And, any particulars of how this actually worked would have to be carefully planned out.
I foresee that, as experience with the concept of TASKs grows, new uses for task activities will evolve over time. That follows the learning curve for SPFLite itself. George, you called your editor "LITE" because (I think) you saw your editor as a poor, wimpy imitation of the "big boy" ISPF from IBM. Well, it's not wimpy any more. It's serious business, but it took years to get here.
I don't want to create a large, hypothetical list of possible uses of TASKs, because that would constrain our users' imaginations, and we don't want to do that.
Instead, I ask that you all USE your imaginations. Ask questions. Draw on your own editing experiences, especially you users that are into heavy-weight, complex activities. What sorts of task automation could help you, things that are not strictly 'instances' or 'macros'? That is what I envision this TASK idea as being able to help.
Comments invited.
R
