That doesn’t matter, and nor should it. EdgeCommand accepts two parameters – the direction (area of the screen, if you will) and a command to act upon once that condition has been satisfied. That command could be anything – another builtin command, or a complex function (as is the case with your example above).
So we see that we’re calling EdgeFunction, and passing it: “ShowPager m-80p m40p” as parameters. Note that the whole point of complex functions is that to the user, they don’t need to know or care whether the function is just that, or a pre-existing command builtin to FVWM. The only reason we differentiate is for a social and technical reaon; social in that quite often the person using the function wrote it, so they know it’s one through design, and technical because functions have a context associated with them which can affect the operand windows they run on.
I’ve described this concept before anyway: function chaining – the propagation of events from one function to another. There are inherent dangers in doing this, but consider:
DestroyFunc A
AddToFunc A
+ I Function B $*
DestroyFunc B
AddToFunc B
+ I Echo $0
+ I Exec exec $*Yes, A calls B in this case, passing down various things, but so what? It doesn’t matter to you how it works, just that A accepts some parameters in the first place.
Correct – see above.
I’d rather not, if only because trying to describe FVWM in terms of the BNF is pointless; it’s not a programming language, and you shouldn’t try to see it as such. The confusion you’re in probably stems from the fact you think that it can work like a program. But it doesn’t.
– Thomas Adam