Post by George on Jun 30, 2022 11:47:17 GMT -5
Missed your intervening post.
Robert: Very thorough, as expected.
However, this is needlessly complicated.
Here’s my take. (I’ve used your text as the basis and modified it)
__________________________________________________________________
For the benefit of those who have not been following the FFT thread, here's the idea in a (big) nutshell:
1. The name of this new feature is CMDPAD and it consists of some small SPFLite changes. A new reserved Clipboard name for the CUT command (CMDPAD), and a new Keyboard Primitive – (CmdPad). Both parts are needed to make this work.
The intended usage of the “Command Pad” is to hold a list of commands that a user would probably want to execute repeatedly, but which may not justify saving as a customized KEYMAP mapping.
2. The "command pad" is an SPFLite internal area in memory, it is not an external file. Think of it as a special purpose reserved clipboard. Being memory resident, it ‘goes away’ at SPFLite termination. However, the actual data comprising that list of commands MAY or may NOT be temporary. That's up to the user.
3. Placing the commands in the CMDPAD is accomplished with the CUT CMDPAD command. All normal CUT selection options may be used. (CMDPAD becomes a reserved private clipboard name) This will copy the selected text from any non-FM edit tab (New(Empty), Edit, Browse, View, Clip, etc) to the CMDPAD area. As is normal after a CUT, what is done with the data in the tab after, is entirely up to the user – save it, discard it etc. The CMDPAD data itself is entirely separate.
The contents of the CMDPAD can be replaced as often as desired, from any active tab. Once data is copied to the CMDPAD, there is no relationship maintained as to the tab in which it originated.
4. At this point the KB primitive (CmdPad) may be used in any tab to inject the CMDPAD commands into the keyboard stream.
5. The contents of the CMDPAD can be edited at any time using a CLIP CMDPAD command.
6. In a multi-instance SPFLite environment, each SPFLite instance does its own unique CMDPAD handling. CMDPADs are not sharable across instances.
7. The (CmdPad) keyboard primitive has a straight-forward function. It verifies that there is currently data in the CMDPAD area and if so, the contents are "executed", exactly the same as if it were a DO file.
8. A common source of CMDPAD data might be the result of a keyboard (Record) session. This data can be opened for review with a simple CLIP command. To make it available in CMDPAD, issue a CUT ALL CMDPAD.
9. For the sake of users that issue a (Record) function to record keystrokes, the CUT CMDPAD variation will restructure the data being placed in the CMDPAD to be easier to cope with. For example, a keyboard (Record) session typically produces a (possibly long) string of commands like this:
(home)[F TAB](enter)(down)
That could be hard for users to cope with, especially if this recorded command list were lengthy. CUT CMDPAD would automatically "split" this into logical pieces, so you'd have discrete parts on individual lines, like:
(home)
[F TAB]
(enter)
(down)
If the user did not want the contents of the file "split" as shown above, perhaps the RAW keyword of CUT could be used to indicate this.
10. The user would have to pick some key to launch the (CmdPad) function from. For users having a numeric keypad on their keyboard, the KeyPad Enter might be a nice choice. But like all other aspects of using KEYMAP, that is entirely up to the user.
George
Robert: Very thorough, as expected.
However, this is needlessly complicated.
Here’s my take. (I’ve used your text as the basis and modified it)
__________________________________________________________________
For the benefit of those who have not been following the FFT thread, here's the idea in a (big) nutshell:
1. The name of this new feature is CMDPAD and it consists of some small SPFLite changes. A new reserved Clipboard name for the CUT command (CMDPAD), and a new Keyboard Primitive – (CmdPad). Both parts are needed to make this work.
The intended usage of the “Command Pad” is to hold a list of commands that a user would probably want to execute repeatedly, but which may not justify saving as a customized KEYMAP mapping.
2. The "command pad" is an SPFLite internal area in memory, it is not an external file. Think of it as a special purpose reserved clipboard. Being memory resident, it ‘goes away’ at SPFLite termination. However, the actual data comprising that list of commands MAY or may NOT be temporary. That's up to the user.
3. Placing the commands in the CMDPAD is accomplished with the CUT CMDPAD command. All normal CUT selection options may be used. (CMDPAD becomes a reserved private clipboard name) This will copy the selected text from any non-FM edit tab (New(Empty), Edit, Browse, View, Clip, etc) to the CMDPAD area. As is normal after a CUT, what is done with the data in the tab after, is entirely up to the user – save it, discard it etc. The CMDPAD data itself is entirely separate.
The contents of the CMDPAD can be replaced as often as desired, from any active tab. Once data is copied to the CMDPAD, there is no relationship maintained as to the tab in which it originated.
4. At this point the KB primitive (CmdPad) may be used in any tab to inject the CMDPAD commands into the keyboard stream.
5. The contents of the CMDPAD can be edited at any time using a CLIP CMDPAD command.
6. In a multi-instance SPFLite environment, each SPFLite instance does its own unique CMDPAD handling. CMDPADs are not sharable across instances.
7. The (CmdPad) keyboard primitive has a straight-forward function. It verifies that there is currently data in the CMDPAD area and if so, the contents are "executed", exactly the same as if it were a DO file.
8. A common source of CMDPAD data might be the result of a keyboard (Record) session. This data can be opened for review with a simple CLIP command. To make it available in CMDPAD, issue a CUT ALL CMDPAD.
9. For the sake of users that issue a (Record) function to record keystrokes, the CUT CMDPAD variation will restructure the data being placed in the CMDPAD to be easier to cope with. For example, a keyboard (Record) session typically produces a (possibly long) string of commands like this:
(home)[F TAB](enter)(down)
That could be hard for users to cope with, especially if this recorded command list were lengthy. CUT CMDPAD would automatically "split" this into logical pieces, so you'd have discrete parts on individual lines, like:
(home)
[F TAB]
(enter)
(down)
If the user did not want the contents of the file "split" as shown above, perhaps the RAW keyword of CUT could be used to indicate this.
10. The user would have to pick some key to launch the (CmdPad) function from. For users having a numeric keypad on their keyboard, the KeyPad Enter might be a nice choice. But like all other aspects of using KEYMAP, that is entirely up to the user.
George