Error message for `Blocks` is incorrect

[PaulaHaehndel]

The error message for Blocks suggest that if your input is just a group you additionally need a point, but you actually need a set (or something similar) the group is acting on.

gap> G:=Group((1,2)(3,4),(1,3)(2,4));
Group([ (1,2)(3,4), (1,3)(2,4) ])
gap> Blocks(G,[1..4]);
[ [ 1, 2 ], [ 3, 4 ] ]
gap> Blocks(G);
Error, usage: Blocks(<xset>,<pnt>)
or Blocks(<G>[,<Omega>],<pnt>[,<gens>,<acts>][,<act>]) at /mnt/c/gap/lib/oprt.gd:820 called from
<function "Blocks">( <arguments> )
 called from read-eval loop at *stdin*:4
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue
brk> quit;
gap> Blocks(G,1);
Error, no method found! For debugging hints type ?Recovery from NoMethodFound
Error, no 1st choice method found for `BlocksOp' on 5 arguments at /mnt/c/gap/lib/methsel2.g:249 called from
orbish( G, pnt, gens, acts, act ) at /mnt/c/gap/lib/oprt.gd:858 called from
<function "Blocks">( <arguments> )
 called from read-eval loop at *stdin*:4
type 'quit;' to quit to outer loop

The issue #3364 is related, but different.

[fingolfin]

I think to fix this, we either need to add some additional arguments to OrbitishFO, or do some clever interpretation of the reqs argument, because it turns out that different things defined via OrbitishFO have different combinations of what arguments are allowed and what not; and I think this is incorrectly described for some of them in either the documentation or the error message or both. I suggest we do this:

1. Go through the list of these operations, test what they support and what not
2. Then adjust the documentation.
3. afterwards we can think about how to adjust the error message (in the worst case, part of the error message could be in a new extra argument for OrbitishFO).

For step 1, I'd just generate a .tst file, say OrbitishFO.tst; then create all possible / imaginable argument variants as calls to one of these functions (say, Blocks); this includes testing the cases the produce errors. Then, one can copy&paste those tests a couple times, and replace Blocks in each copy by the name of another copy.

Here is an overview of the affected operations:

lib/oprt.gd:1268:OrbitishFO( "ExternalSubset",
lib/oprt.gd:1294:OrbitishFO( "ExternalOrbit", OrbitishReq, IsCollsElms, true, false );
lib/oprt.gd:1331:OrbitishFO( "Orbit", OrbitishReq, IsCollsElms, false, false );
lib/oprt.gd:1427:OrbitishFO( "OrbitLength", OrbitishReq, IsCollsElms, false, false );
lib/oprt.gd:1502:OrbitishFO( "OrbitStabilizer", OrbitishReq, IsCollsElms, false,false );
lib/oprt.gd:1641:OrbitishFO( "Blocks",
lib/oprt.gd:1676:OrbitishFO( "MaximalBlocks",
lib/oprt.gd:1715:OrbitishFO( "RepresentativesMinimalBlocks",
lib/oprt.gd:2235:OrbitishFO( "StabilizerFunc", OrbitishReq, IsCollsElms, false,false );

[hulpke]

Given the pain it causes and the limited cleverness it provides, is it actually worth to keep the OrbitishFO setup, or would it be worth to simply go back to several similar declarations of ordinary code?