When printing function bodies, avoid some redundant spaces

[fingolfin]

In particular, don't print 'if x then', but rather 'if x then' (note the extra space in the former), and similar after "local", and before "do".

Resolves #473

This PR will fail lots of tests, because so many of them contain printed code, which now of course is "formatted wrong". It shouldn't be too hard to fix all that with some calls to sed or perl, but I don't have the time to do that now, and perhaps somebody wants to step up and do it?

[ChrisJefferson]

I like this. My only comment is if there are other changes we want to make at the same time.

[fingolfin]

@ChrisJefferson I am not sure whether your comment is a question, or a statement (in the latter case, could you say what you have in mind?)

[olexandr-konovalov]

This would be good to do. I should be able to push to this branch - may try.

[frankluebeck]

This PR will fail lots of tests, because so many of them contain printed code, which now of course is "formatted wrong". It shouldn't be too hard to fix all that with some calls to sed or perl, but I don't have the time to do that now, and perhaps somebody wants to step up and do it?

Are you aware that GAP has tools to change test files and manuals?

For test files: see ?Reference: Test, in particular the entry .rewriteToFile of the options record.

For manual examples: see GAPDoc: RunExamples, in particular the entry .changeSources in the options record (this even works if the manual is collected from many program files).

[frankluebeck]

Concerning the content of this pull request: All changes look sensible to me.

[fingolfin]

@frankluebeck Yes, I am aware, I just couldn't be bothered to figure out how to pass those options to TestDirectory correctly; and then there are the manual examples, too, which probably need some manual work (but hopefully only a very few are affected).

So this is not a difficult task, just one that takes time (which I rather want to spend on other things right now)

[olexandr-konovalov]

@fingolfin looking at

# But found:
function (  )
    local a, b, c;
    if IsBound( a) then
        Print( "1" );
    fi;
 ...

Is it also possible to add a padding after a in the line if IsBound( a) then ?

[codecov]

Codecov Report

Merging #1498 into master will increase coverage by 0.09%.
The diff coverage is 90.9%.

@@            Coverage Diff             @@
##           master    #1498      +/-   ##
==========================================
+ Coverage   64.44%   64.54%   +0.09%     
==========================================
  Files        1002     1002              
  Lines      326861   328423    +1562     
  Branches    13216    13485     +269     
==========================================
+ Hits       210661   211990    +1329     
- Misses     113334   113530     +196     
- Partials     2866     2903      +37

Impacted Files	Coverage Δ
src/c_methsel1.c	67.61% <ø> (-0.03%)	⬇️
hpcgap/src/c_type1.c	70.17% <ø> (ø)	⬆️
src/c_filter1.c	95.85% <ø> (ø)	⬆️
src/c_type1.c	72.59% <ø> (ø)	⬆️
hpcgap/src/c_filter1.c	96.44% <ø> (ø)	⬆️
hpcgap/src/c_oper1.c	86.4% <ø> (ø)	⬆️
hpcgap/src/c_methsel1.c	67.39% <ø> (ø)	⬆️
src/c_oper1.c	87.42% <ø> (-0.05%)	⬇️
src/stats.c	73.07% <100%> (ø)	⬆️
src/calls.c	52.82% <100%> (ø)	⬆️
... and 18 more

[olexandr-konovalov]

@fingolfin rebased and pushed with tests updated and extended. Waiting for CI results.

[fingolfin]

Use Display instead of Print to make the tests pass (I think).

[olexandr-konovalov]

@fingolfin thanks - pushed the fix to see the effect, will edit the branch later while rebasing

[fingolfin]

That push seems to have helped.

[olexandr-konovalov]

@fingolfin rebased and squashed into one commit - waiting for CI results.

[fingolfin]

@alex-konovalov looks good to me, but I can't approve this, as it's my PR ;-). Also, you really did by far the most work, and that commit is now authored by me. Perhaps change the commit author to yourself, and then merge? (I don't mind if it is merged as is, just want to make clear that I think Alex did by far most of it).

Also: should this be mentioned in the released notes? Personally, I consider it not important enough, but it is user visible, so it is a border case...

[olexandr-konovalov]

@fingolfin thanks, but idea was yours and the initial study and modification of the code too,
so I am sure it should be yours. I can amend the commit message and mention there parts that I have added (it was not practical to keep them in a separate commit, since they would not be atomic otherwise).

I'd mention this in release notes, exactly by the mentioned reason.