Post by George on Jul 17, 2018 11:24:10 GMT -5
This is a chicken and the egg problem.
Processing KB primitives is done in the KB handling routines.
All Primary and Line commands are basically executing INSIDE the KB handling routines (typically when processing the (Enter) KB primitive.
The (Enter) KB routine does not complete until all the triggered Line and Primary commands complete and do their nested Returns. Add in what a MACRO call does and you are now incredibly deep down a module chain.
Now all you want is for the deeply nested DO command to somehow reach back and inject primitive commands back into the top level KB processing.
Way too incestuous for me to even conceive of DOing.
George
--- I wouldn't tell Linda about that incent thing :-))
You are totally confusing me. Who said anything about injecting primitive commands? Not me. What do you mean, a "deeply nested DO command"? I have no idea what you're talking about. "Nested"? Nested in relation to what? I am totally, utterly lost here. You need to explain this better.
If I understand how KEYMAP strings handle primary commands, they only really work for one of them. Anything else you have to do the hard way, by issuing (home) and [command-name] and (enter) fields.
Honestly, I think you are over-complicating things. Allow me to try to explain.
You have two use cases. One is when a keymap string contained a DO command. The other is if you type DO on the command line. OK so far?
1. Suppose you have a key-mapped DO. How does a mapped key work now? You detect a key, you locate its string value, then you interpret the string. Correct? Now, what would you do with a DO command that is mapped? Seems to me, you would do this:
(a) locate the file in question, and read its contents into memory.
(b) assuming you only supported primary commands, take each line and wrap them in "(home)[" and "](enter)"
(c) glue the whole thing back together into a big string, pretend it was a key mapping string, and go interpret it
2. How to handle DO from the command line:
(a) locate the file in question, and read its contents one line at a time
(b) interpret each line directly, one at a time
Are you saying it isn't that simple? If so, why not?
----------------------------------------------------------------------
You asked for a Primary DO command, that's what I was answering. And by 'nesting' I mean the simple logic flow - routine A calls routine B, B calls C, c calls D etc. As a primary command, you're asking for the DO routine to reach back and inject a command back at the routine A or B level. The whole set of routines which handle commands are simply not recursive.
As to doing it all in the KB mapping routines, Primary commands always end the mapping loop, that's why you can't have additional primitives following a Primary command. Altering that would mean some major restructuring of the whole KB processing. THAT you can forget, ain't going to happen.
George
==================================
Alright, I will admit I don't know and don't understand the internals here. Allow me to try to convince you that it could work.
Here's the idea.
1. OK, let's say that we supported this DO idea, and ON THE SURFACE it might appear that they were the same, but in reality they were totally different.
2. For a primary command DO, it would ONLY accept primary commands, including LINE … which is also a primary. The only thing special about this is that you would allow the DO file to have a list of primary commands. NO keyboard primitives would be allowed. OK?
3. For a key-mapped DO command, you would read the file in question, wrap each line you found in (home) and (enter) and enclose the commands in [ ]. The DO command itself would appear as the only entry in the keymap for that key, and DO would NOT be allowed anywhere else. So, you would be treating DO as a special case. A key-mapped DO file could not contain DO, nor could the main keymap entry have DO anywhere but the very first part of it's definition; anything else would be illegal. Still OK?
4. For a key-mapped DO, the DO file *ought* to be able to include keymap primitives. The way I see it, you would automatically wrap real Primary commands in (home) and (end) and enclose in []. The net result would be (maybe really long) string, but just a string like any other keymap string. You would then interpret that string. So, the file could have Primary commands and key primitives interspersed.
Say a key-mapped DO file contained this:
FIND C'abc'
The idea of this -made up example is that you are trying to find "abc" and when you do, you overwrite "a" with "A".
Say this gets assigned to F5. In the F5 key map entry, there would be this:
DO FIXABC
The user presses F5.
You read the definition for F5 and see "DO FIXABC".
You go read the DO file at \SPFLite\Macros\FIXABC.DO.
At this point, you would scan the DO file, wrapping any Primary commands you found into equivalent key commands.
That would give you a string that looked like this:
(home)[FIND C'abc'](enter)(end)(left:3)
You then interpret that string, the very same way that you would if F5 directly contained this value.
So tell me, if F5 actually contained (home)[FIND C'abc'](enter)(end)(left:3) AND you were able to interpret and execute that string, why couldn't you create such a string yourself and then interpret it? How is it any different?
