Post by Robert on May 24, 2024 20:01:58 GMT -5
Recently there has been a discussion of how to handle cases where a built-in command has gotten superseded by a macro. A similar issue exists when there is a SET name of the form
SET ALIAS.name = command
where 'name' is the name of a primary command. Up until now, this situation has not received much attention, other than a brief mention in the Help that in fact it's possible to do it.
I always believe it's important to give a good name to a new concept, so that everyone agrees on it and you can have a conversion about it so everyone is on the same page. A name that supersedes an existing command is like an "alias". But, there's already a SET ALIAS feature, and using "alias" for this too would be confusing. There are plenty of long words that could be used, like "impersonate", "pseudonym", and so on. But, the best "concept words" are short, unique and get to the point. After considerable searching on thesaurus web sites, the name "proxy" seemed like the best choice. If anyone has a better idea, I'm all ears. For now, I am going to refer to this idea of superseded command names as "proxy names".
When a macro supersedes a built-in command, we will call this a "MACRO proxy". When a SET ALIAS name supersedes a built-in command, we will call this a "SET proxy". Notably, a SET proxy could possibly refer to a MACRO proxy.
Here are the principles I believe should control command proxies.
1. The existence of command proxies should be considered unusual. Why would someone alter the behavior of a built-in command? Adding an abbreviation is one thing, but replacing or interfering with the the exact spelling of a built-in command is generally a non-standard thing to do. Thus, managing of proxy names needs to take this into account.
2. There have been documented instances where users unknowingly had defined command proxies, either by themselves or inadvertently by an SPFLite install. This situation should not be allowed by default. If someone actually wants to do this, they should specifically enable it. To do that, there should be a new Options checkbox like this:
[x] Allow for use of command proxy names
This option would default to disabled. If anyone wants to override a built-in command, they would have to check this box.
3. The fact that a macro or SET name is a proxy must be detected by keeping a list of all known built-in commands. Let us call this the Standard Command List. In theory, there is a separate Standard Command List for both Primary and Line commands, but the issue of proxies seems to have the biggest impact on Primary commands. And, because almost all letters A-Z have already been defined for line commands, using a proxy for one of them seems unlikely. For now, I will assume that proxies only refer to Primary commands.
4. It is important to make sure users know that a proxy exists. If they have a long list of SET ALIAS name and many macros, it might not be obvious that one of them is in fact a proxy. That is especially true for newer users that haven't memorized the names and abbreviations of all of the existing commands. For that reason, it is important to somehow highlight the name of a SET ALIAS or a MACRO name when that name is one in the Standard Command List. Any workable highlight should be ok, as long as it's something obvious. In the SET EDIT, the line-command area could have a flag like PROXY> to mark it. In the File List for the SPFLite macro folder, PROXY> could be put in the FM line command area. Or, the contents of the SET ALIAS line and the directory entry of the MACRO in question could be highlighted in some loud color, like white on a red background. However it's done, it should stick out like a sore thumb.
5. Item (4) helps to find the definition of a proxy. How do we notify users of the execution of a proxy? George, you recently proposed some kind of notification when a macro is run. But, it seems to me that merely running a macro is commonplace enough that you wouldn't want to alert users every time they used one, since they likely already know that. What is important is knowing that a macro PROXY was run, not just any old macro.
6. Part of the command parser's job is to detect SET ALIAS and MACRO names on the command line. When command proxies have been disabled, you would only look for SET and MACRO names if the name in question is NOT in the Standard Command List. When proxies are allowed, and it is found that a SET or MACRO name is a proxy, you would create a Proxy Notification for that command-attention event. The next time such an event happens (or if just Enter is pressed) the notification would be reset. The notification could be a new entry on the Status Bar, with the obvious name of PROXY. When no proxy usage was detected, this entry could be blank or grayed-out; that would also be how it would appear if proxy usage was disabled. When a proxy is detected, the word PROXY could be highlighted, such as white letters on black or red background - again, something that would stick out.
7. Finally, one use for proxies right now is to define command defaults. For instance, Stefan had a SET for NX that included ALL because he always uses ALL. I believe this concept could be better served by a new type of SET, which would be SET DEFAULT.name. This would apply a default list of command options to a command without actually being a proxy. For instance, the NX usage where ALL is always added could be done with:
SET DEFAULT.NX = ALL
This SET definition is not an ALIAS per se, but it notifies SPFLite that the NX command would always have the ALL keyword added.
The main drawback to this is that what happens when you don't want the ALL used? That is, with the default defined, a command like:
NX 'ABC'
would be treated like NX 'ABC' ALL
I see two possibilities. First, there might be some way to remove the default, like:
NX 'ABC' -ALL
But, this could be tricky to implement, and the syntax could be a problem, since some commands have keywords with leading - signs, like -RED and so on.
The other possibility is to have a notation that means you want the built-in system command and not use the default if one exists. Suppose a 'system' command were denoted by SYS name or SYS.name notation. Then, the NX example would become,
SYS NX 'ABC' --or--
SYS.NX 'ABC'
A quick check shows that it's possible to have a command name with a leading dot. So, if we wanted to use that notation for the "system" or "built-in" version of a command, it would allow use to do it more concisely as,
.NX 'ABC'
That is brief and not too painful.
Something like that would be used to ignore the DEFAULT.NX definition and then ALL would not be added.
As an idea, the points above will be adjusted and tailored as users comment on them and experience is gained to see if the features are serving a useful purpose.
R
SET ALIAS.name = command
where 'name' is the name of a primary command. Up until now, this situation has not received much attention, other than a brief mention in the Help that in fact it's possible to do it.
I always believe it's important to give a good name to a new concept, so that everyone agrees on it and you can have a conversion about it so everyone is on the same page. A name that supersedes an existing command is like an "alias". But, there's already a SET ALIAS feature, and using "alias" for this too would be confusing. There are plenty of long words that could be used, like "impersonate", "pseudonym", and so on. But, the best "concept words" are short, unique and get to the point. After considerable searching on thesaurus web sites, the name "proxy" seemed like the best choice. If anyone has a better idea, I'm all ears. For now, I am going to refer to this idea of superseded command names as "proxy names".
When a macro supersedes a built-in command, we will call this a "MACRO proxy". When a SET ALIAS name supersedes a built-in command, we will call this a "SET proxy". Notably, a SET proxy could possibly refer to a MACRO proxy.
Here are the principles I believe should control command proxies.
1. The existence of command proxies should be considered unusual. Why would someone alter the behavior of a built-in command? Adding an abbreviation is one thing, but replacing or interfering with the the exact spelling of a built-in command is generally a non-standard thing to do. Thus, managing of proxy names needs to take this into account.
2. There have been documented instances where users unknowingly had defined command proxies, either by themselves or inadvertently by an SPFLite install. This situation should not be allowed by default. If someone actually wants to do this, they should specifically enable it. To do that, there should be a new Options checkbox like this:
[x] Allow for use of command proxy names
This option would default to disabled. If anyone wants to override a built-in command, they would have to check this box.
3. The fact that a macro or SET name is a proxy must be detected by keeping a list of all known built-in commands. Let us call this the Standard Command List. In theory, there is a separate Standard Command List for both Primary and Line commands, but the issue of proxies seems to have the biggest impact on Primary commands. And, because almost all letters A-Z have already been defined for line commands, using a proxy for one of them seems unlikely. For now, I will assume that proxies only refer to Primary commands.
4. It is important to make sure users know that a proxy exists. If they have a long list of SET ALIAS name and many macros, it might not be obvious that one of them is in fact a proxy. That is especially true for newer users that haven't memorized the names and abbreviations of all of the existing commands. For that reason, it is important to somehow highlight the name of a SET ALIAS or a MACRO name when that name is one in the Standard Command List. Any workable highlight should be ok, as long as it's something obvious. In the SET EDIT, the line-command area could have a flag like PROXY> to mark it. In the File List for the SPFLite macro folder, PROXY> could be put in the FM line command area. Or, the contents of the SET ALIAS line and the directory entry of the MACRO in question could be highlighted in some loud color, like white on a red background. However it's done, it should stick out like a sore thumb.
5. Item (4) helps to find the definition of a proxy. How do we notify users of the execution of a proxy? George, you recently proposed some kind of notification when a macro is run. But, it seems to me that merely running a macro is commonplace enough that you wouldn't want to alert users every time they used one, since they likely already know that. What is important is knowing that a macro PROXY was run, not just any old macro.
6. Part of the command parser's job is to detect SET ALIAS and MACRO names on the command line. When command proxies have been disabled, you would only look for SET and MACRO names if the name in question is NOT in the Standard Command List. When proxies are allowed, and it is found that a SET or MACRO name is a proxy, you would create a Proxy Notification for that command-attention event. The next time such an event happens (or if just Enter is pressed) the notification would be reset. The notification could be a new entry on the Status Bar, with the obvious name of PROXY. When no proxy usage was detected, this entry could be blank or grayed-out; that would also be how it would appear if proxy usage was disabled. When a proxy is detected, the word PROXY could be highlighted, such as white letters on black or red background - again, something that would stick out.
7. Finally, one use for proxies right now is to define command defaults. For instance, Stefan had a SET for NX that included ALL because he always uses ALL. I believe this concept could be better served by a new type of SET, which would be SET DEFAULT.name. This would apply a default list of command options to a command without actually being a proxy. For instance, the NX usage where ALL is always added could be done with:
SET DEFAULT.NX = ALL
This SET definition is not an ALIAS per se, but it notifies SPFLite that the NX command would always have the ALL keyword added.
The main drawback to this is that what happens when you don't want the ALL used? That is, with the default defined, a command like:
NX 'ABC'
would be treated like NX 'ABC' ALL
I see two possibilities. First, there might be some way to remove the default, like:
NX 'ABC' -ALL
But, this could be tricky to implement, and the syntax could be a problem, since some commands have keywords with leading - signs, like -RED and so on.
The other possibility is to have a notation that means you want the built-in system command and not use the default if one exists. Suppose a 'system' command were denoted by SYS name or SYS.name notation. Then, the NX example would become,
SYS NX 'ABC' --or--
SYS.NX 'ABC'
A quick check shows that it's possible to have a command name with a leading dot. So, if we wanted to use that notation for the "system" or "built-in" version of a command, it would allow use to do it more concisely as,
.NX 'ABC'
That is brief and not too painful.
Something like that would be used to ignore the DEFAULT.NX definition and then ALL would not be added.
As an idea, the points above will be adjusted and tailored as users comment on them and experience is gained to see if the features are serving a useful purpose.
R