Multiline IF-THEN line endings

It’s very easy to write a multiline IF ... THEN ... ENDIF structure in BASIC and leave a trailing space or two after the THEN, which results in the code on the next line being unconditionally executed. And it can sometimes be a pain to debug when this happens, since the code visually looks fine. I can set StrongED (which I use) to strip all end of line spaces when the file is saved, but this is inconvenient when, say, submitting revisions to the sources to ROOL (as it will look like there are loads of edits to the source when it comes for review). And I could make control characters visible when editing, but I personally find this hinders readability in all other respects.

So my question is: would it break anything if BASIC’s interpreter changed its treatment of trailing spaces in this case? Would it be feasible/desirable to just ignore trailing spaces after a THEN?

I can set StrongED (which I use) to strip all end of line spaces when the file is saved, but this is inconvenient when, say, submitting revisions to the sources to ROOL (as it will look like there are loads of edits to the source when it comes for review).

The stripping of unwanted trailing spaces is probably a good thing anyway, so having this happen on a one-time submission shouldn’t be seen as negative.

So my question is: would it break anything if BASIC’s interpreter changed its treatment of trailing spaces in this case? Would it be feasible/desirable to just ignore trailing spaces after a THEN?

If the system variable Basic$Crunch is set, then BASIC will do that for you. (and a whole lot more useful optimisation as well)

Also using !Edit rather than !StrongEd will also strip trailing spaces when the file is saved. As !Edit was there first, I would suggest that !StrongEd is what should be fixed.

I would suggest that !StrongEd is what should be fixed.

I don’t think there’s anything wrong with StrongED – the default behaviour is, I think, just like Edit’s. I turned it off after submitting a small change to ROOL that looked as if hundreds of alterations had been made. In that case, clearly lots of spaces needed stripping :)

Obviously there are a few workarounds here, such as one-time ‘cleaning’ submissions, etc. But I’m still wondering if anything would be lost by changing the interpreter’s behaviour, so that this little quirk never arises in the first place.

The usual BASIC problems apply here – a program will only run correctly if it’s running in an appropriate version of the interpreter. So although we probably could change the interpreter to ignore trailing spaces, the effect would only be visible for people who are running the new version. That may cause issues when trying to distribute your software.

A BASIC linter which is able to spot trailing spaces and other potential issues would be nice, and could potentially be integrated with ROOL’s gitlab to help with reviewing submissions.

would it break anything if BASIC’s interpreter changed its treatment of trailing spaces in this case?

Probably. We’ll need to await Steve (who has rummaged around in BASIC more than most of us) to provide specifics, but I would say that given the amount of weird rubbish that can follow a THEN in BASIC, the logic for multiline/singleline is probably whether or not anything follows the THEN statement.

that looked as if hundreds of alterations had been made.

Does this imply that the software is bug-ridden, or do you mean trailing spaces elsewhere?

I think all of the main editors are able to strip off errant spaces. This…probably should have been done in the first place.

the logic for multiline/singleline is probably whether or not anything follows the THEN statement.

As pointed out in this thread BASIC also looks for THEN at the end of a line when skipping over nested IF statements. Allowing spaces after THEN will therefore break other IF statements…

The usual BASIC problems apply here – a program will only run correctly if it’s running in an appropriate version of the interpreter. So although we probably could change the interpreter to ignore trailing spaces, the effect would only be visible for people who are running the new version. That may cause issues when trying to distribute your software.

Ah, yes. Of course.

Does this imply that the software is bug-ridden, or do you mean trailing spaces elsewhere?

The latter :)

A BASIC linter which is able to spot trailing spaces and other potential issues would be nice, and could potentially be integrated with ROOL’s gitlab to help with reviewing submissions.

Well it seems part of the OS release (Edit) does the trailing space removal (as do various other editors) so that’s part of the job done :)

The stripping of unwanted trailing spaces is probably a good thing anyway, so having this happen on a one-time submission shouldn’t be seen as negative.

The problem is when the text editor does it whilst saving a one-line fix for something else…

A BASIC linter which is able to spot trailing spaces and other potential issues would be nice, and could potentially be integrated with ROOL’s gitlab to help with reviewing submissions.

Isn’t all RISC OS source BASIC stored as text which is run through a build process anyway? Presumably that could (or does?) strip trailing spaces if they were considered unnecessary.

Based on my notes for Tokenize, CRUNCH already does this when asked to strip whitespace from within lines.

Isn’t all RISC OS source BASIC stored as text which is run through a build process anyway?

No, of course it is not. Perhaps when building a ROM but the vast majority of RISC OS BASIC source is stored in tokenised form. Good editors (such as !Zap) strip trailing spaces on any line when saving an edited programme. Whether !Zap also strips trailing spaces on a line that isn’t being edited is another matter.

It would be very useful if when LISTing a programme any IF … THEN clause that has trailing spaces or colons but no keywords (or line numbers) following the THEN is shown with a printable character following the ‘THEN’ and the best such character (which would not affect the line functionally, retainig its meaning as a single-line IF clause rather than a multi-line one) would be a colon. Then an offending line would be shown thus:

  100 IF a>b THEN :

rather than the form in which it is held in memory

  100 IF a>b THEN [invisible space]

No, of course it is not.

Really? So what are all the arguments about why the stuff in GitLab needs to be plain text and not tokenised BASIC, with C pre-processor stuff embedded in it?

Note that I said “RISC OS source”. Since this was about “submitting revisions to the sources to ROOL”, as was the subsequent discussion about the problems of auto-stripping spaces when committing to a VCS, what you or I do for our non-OS stuff is irrelevant.

It would be very useful if when LISTing a programme any IF … THEN clause that has trailing spaces or colons but no keywords (or line numbers) following the THEN is shown with a printable character following the ‘THEN’ and the best such character (which would not affect the line functionally, retainig its meaning as a single-line IF clause rather than a multi-line one) would be a colon.

Zap’s approach of highlighting trailing spaces seems to work quite well already.

Really? So what are all the arguments about why the stuff in GitLab needs to be plain text and not tokenised BASIC, with C pre-processor stuff embedded in it?

+1

I recall the discussions in the forums – was that 2019 or early 2020?

Note that I said “RISC OS source”. Since this was about “submitting revisions to the sources to ROOL”…

I hadn’t realised that this item was still ‘on topic’.

And I could make control characters visible when editing, but I personally find this hinders readability in all other respects.

You can set StrongED to only highlight trailing (EoL) spaces. Another useful option might be to define a search to find THENs with trailing spaces.

StrongED 4.70 is back to the original behaviour of only stripping trailing spaces on edited lines rather than stripping all trailing spaces on save.

StrongED 4.70 is back to the original behaviour of only stripping trailing spaces on edited lines

Is that an improvement from version 4.71?

I hadn’t realised that this item was still ‘on topic’.

It’s worth noting that the text which I quoted and replied to was…

A BASIC linter which is able to spot trailing spaces and other potential issues would be nice, and could potentially be integrated with ROOL’s gitlab to help with reviewing submissions.

So yes, definitely still “on topic”. I was specifically responding to a comment on the ROOL submission process…

FWIW, I do something similar, in that I rely on Tokenize stripping trailing spaces on build. I used to have my text editor strip them on saving, but it’s something that you only get wrong once on code being submitted to a shared project before turning the option off… (as the other Chris noted at the start of the thread).

Is that an improvement from version 4.71?

4.71? I haven’t even finished 4.70 yet. ;-)

To explain in more detail, originally StrongED would trim EoL spaces of an edited line when the cursor was moved away using the keyboard but not when moved away with the mouse.

In an attempt to get rid of this inconsistency I made StrongED strip all EoL spaces when the text was saved (if the option was on). Then someone (not the other Chris) complained that this resulted in many more lines being changed than those actually edited. Which created a problem when using a CVS system.

So I pondered this problem for a while and came with a way to trim EoL spaces in StrongED regardless of how the cursor was moved away from the edited line. That’s the way SE 4.70 does it; back to more surgical, less sledgehammer. :-)

Pondering – wasn’t there a utility at one time that took BASIC and indented it, removed the “fluff” and a number of other features?¹

Something to tidy up BASIC, C and assembler source files would be rather useful.
Set indents and spacing in the assembler, comments on lines neatly lined up (OCD) – all done to match the ROOL specified alignment.

¹ and one that checked a BASIC program to list how many times a PROC was called and list ones that were not used.

The issue with cvs (or any other source control) is mute. Once you decide that spaces at the end of lines is bad, you should do a single commit removing them from all files. Then mandate that all editors have this setting, so subsequent edits only affect the lines actually changed.

Which created a problem when using a CVS system.

Which solved a problem that had been hidden until then.

wasn’t there a utility at one time that took BASIC and indented it,

The problem with that is that by inserting spaces a line can become longer than the permitted length.

BB4W solves this by auto-inserting indentation during editing.

So I pondered this problem for a while and came with a way to trim EoL spaces in StrongED regardless of how the cursor was moved away from the edited line. That’s the way SE 4.70 does it; back to more surgical, less sledgehammer. :-)

That sounds like a very useful change, Fred :)

BB4W solves this by auto-inserting indentation during editing.

StrongED’s BASIC mode has a function to indent a text or a selection, tied to Ctrl-Shift-R. The function uses an implementation of the ‘Variable Based Indenter’ that Anders Lund added to Kate.

Another way to indent a BASIC text in StrongED is to use Ctrl-E, Ctrl-I. This loads the text into BASIC and then saves it back out using TEXTSAVEO.

If necessary the indentation can be removed before saving with the ‘Remove leading spaces’ option in the view’s menu.