Topics

Syntax colouring

Richard Russell
 

On Mon, Mar 2, 2020 at 06:39 PM, Leslie Baker wrote:
I don't use colours in the code, I find it more confusing than helpful
I must say that surprises me.  I find syntax colouring very helpful, not least in identifying 'at a glance' when I have inadvertently started a variable name with a keyword, something that is particularly easy to do in BBC BASIC and can lead to non-obvious errors if you haven't spotted it.  For those who like to enable lowercase keywords, something that I don't recommend, the likelihood of this happening is much higher.

Another use for syntax colouring that I wouldn't want to be without is to draw attention to having quotation marks incorrectly 'paired' in a string expression.  When you have a complex expression like OSCLI "font """ + @iib$ + "DejaVuSans"", 14" it's only too easy to put one too few or one too many quotation marks (there are three in a row in that expression).  But when the 'quoted' (literal) strings are shown in a different colour this really stands out.

 

On 03/03/2020 17:19, Richard Russell wrote:
On Mon, Mar 2, 2020 at 06:39 PM, Leslie Baker wrote:
I don't use colours in the code, I find it more confusing than helpful
I must say that surprises me.  I find syntax colouring very helpful, not least in identifying 'at a glance' when I have inadvertently started a variable name with a keyword, something that is particularly easy to do in BBC BASIC and can lead to non-obvious errors if you haven't spotted it.  For those who like to enable lowercase keywords, something that I don't recommend, the likelihood of this happening is much higher.

Another use for syntax colouring that I wouldn't want to be without is to draw attention to having quotation marks incorrectly 'paired' in a string expression.  When you have a complex expression like OSCLI "font """ + @iib$ + "DejaVuSans"", 14" it's only too easy to put one too few or one too many quotation marks (there are three in a row in that expression).  But when the 'quoted' (literal) strings are shown in a different colour this really stands out.
_.
I do understand Richard, I think it is due to habit having used commercial basics that don't use colours. I haven't done too much with BB4W recently, and I am having to re-learn it. One thing I find annoying (but it might be my fault) is that when I have an error in the code that stops the program the position of the text cursor bears no relationship to where the error is, and I can't remember how to track it down. I sometimes have to start at the top and read every line until I see the typo etc. Is there a quick way to locate the error in bbcsdl?

nbadderley
 

I absolutely agree. But wouldn’t colour coding matched parentheses be even better!


On 3 Mar 2020, at 17:19, Richard Russell <news@...> wrote:

On Mon, Mar 2, 2020 at 06:39 PM, Leslie Baker wrote:
I don't use colours in the code, I find it more confusing than helpful
I must say that surprises me.  I find syntax colouring very helpful, not least in identifying 'at a glance' when I have inadvertently started a variable name with a keyword, something that is particularly easy to do in BBC BASIC and can lead to non-obvious errors if you haven't spotted it.  For those who like to enable lowercase keywords, something that I don't recommend, the likelihood of this happening is much higher.

Another use for syntax colouring that I wouldn't want to be without is to draw attention to having quotation marks incorrectly 'paired' in a string expression.  When you have a complex expression like OSCLI "font """ + @iib$ + "DejaVuSans"", 14" it's only too easy to put one too few or one too many quotation marks (there are three in a row in that expression).  But when the 'quoted' (literal) strings are shown in a different colour this really stands out.

Richard Russell
 

On Tue, Mar 3, 2020 at 05:35 PM, Leslie Baker wrote:
I think it is due to habit having used commercial basics that don't use colours.
Syntax Colouring is common in other BASICs (e.g. Liberty BASIC), and my BASICs are "commercial", even if only BB4W is paid-for!

when I have an error in the code that stops the program the position of the text cursor bears no relationship to where the error is,

It should!  I've just checked it here and in both BB4W and BBCSDL (Windows edition, in Debug mode) an untrapped error highlights the line which triggered the error and the text cursor (caret) is moved to that line in the editing pane.  So I'm puzzled that this doesn't seem to be happening for you, and it obviously needs investigating.  Maybe it's a difference between Windows and Linux but that is hard to understand.

When I get an opportunity I'll run up a Linux machine and check the error highlighting there.

Richard Russell
 

On Tue, Mar 3, 2020 at 06:12 PM, nbadderley wrote:
But wouldn’t colour coding matched parentheses be even better!
I've not encountered any BASIC that does that.  It's significantly easier to check correct pairing of parentheses, by inspection, than quotes for the simple reason that left and right parentheses have different symbols, whereas left and right quotes don't!  And of course quotes don't "nest" whereas parentheses do,

Richard Russell
 

On Tue, Mar 3, 2020 at 06:24 PM, Richard Russell wrote:
When I get an opportunity I'll run up a Linux machine and check the error highlighting there.
I've just checked it on my Raspberry Pi 4, as the quickest and easiest Linux platform for me to run up, and I can't make it fail.  An untrapped error seems consistently to be highlighting the faulty line and moving the caret there.  Of course this is another 32-bit platform so I ought to check a 64-bit Linux machine to see if that's a factor.

The reason, incidentally, why BB4W highlights the error line always and BBCSDL only in Debug Mode is because in BB4W the BASIC program runs in the same process as the IDE and in BBCSDL they run in separate processes.  So in BBCSDL there's no way the IDE can possibly know anything about what the BASIC program is doing without the debugger being attached, whereas in BB4W the IDE can monitor the BASIC program even when running 'normally'.  In most respects running the IDE and BASIC program in the same process is a bad idea, because a crash will often kill both, but it does have this one benefit.

Richard Russell
 

On Tue, Mar 3, 2020 at 06:53 PM, Richard Russell wrote:
Of course this is another 32-bit platform so I ought to check a 64-bit Linux machine to see if that's a factor.
I've now run up a 64-bit Linux PC (Ubuntu 18.04) and that's working as expected too.  I deliberately introduced an untrapped error in a program and then ran it in Debug Mode; the BASIC program itself exited to immediate mode, of course, but shortly afterwards the error line was highlighted in the editing pane of the IDE (SDLIDE, for the avoidance of doubt, not Andy Parkes' BBCEdit).  When I closed the program window the highlight was automatically cleared, but the caret remained on that line.

This is exactly how it was designed to work, so I remain highly puzzled that it's seemingly not working for you.  Software can be so frustrating!

 

On 03/03/2020 19:52, Richard Russell wrote:
On Tue, Mar 3, 2020 at 06:53 PM, Richard Russell wrote:
Of course this is another 32-bit platform so I ought to check a 64-bit Linux machine to see if that's a factor.
I've now run up a 64-bit Linux PC (Ubuntu 18.04) and that's working as expected too.  I deliberately introduced an untrapped error in a program and then ran it in Debug Mode; the BASIC program itself exited to immediate mode, of course, but shortly afterwards the error line was highlighted in the editing pane of the IDE (SDLIDE, for the avoidance of doubt, not Andy Parkes' BBCEdit).  When I closed the program window the highlight was automatically cleared, but the caret remained on that line.

This is exactly how it was designed to work, so I remain highly puzzled that it's seemingly not working for you.  Software can be so frustrating!

Thank you for your investigation and comments. I just tried it again, I changed a letter in a PRINT statement and ran it. It told me 'Bad use of array' (It was followed by a TAB), I then had to close the display window with the X. The cursor was about 12 lines below the error. Don't worry any further it is really a small problem that I can tolerate.



Richard Russell
 

On Tue, Mar 3, 2020 at 08:43 PM, Leslie Baker wrote:
Don't worry any further it is really a small problem
It is NOT a small problem.  I pride myself that my software products have no bugs, and that if any are discovered I try to fix them quickly (I know I still haven't updated BB4W after the recent bug was discovered, but I am working on it).  So I do worry, and I am very concerned about this apparent malfunction, not least because I can't reproduce it here.

I changed a letter in a PRINT statement and ran it. It told me 'Bad use of array' (It was followed by a TAB),
> I then had to close the display window with the X.


We are talking about BBCSDL running on a Linux platform, yes?  So you didn't 'have to' close the program's window with an X since it is running in a different process from the IDE, indeed it's better not to if you want the error line to remain highlighted.  What did you mean by "had to" there?

The cursor was about 12 lines below the error.

Strange.  You are definitely running my SDLIDE and not Andy's BBCEdit?  There is definitely no ON ERROR statement in your BASIC program?

Would you please be kind enough to repeat the test you did, but to save the program with the deliberate error to file and send it to me as a zipped email attachment (don't post it here, send it as a personal email).  That will make it easier for me to reproduce exactly what you did.

Richard Russell
 

On Tue, Mar 3, 2020 at 09:05 PM, Richard Russell wrote:
Strange.  You are definitely running my SDLIDE and not Andy's BBCEdit?  There is definitely no ON ERROR statement in your BASIC program?
And, just for absolute clarity, you definitely ran the program in Debug Mode by clicking on the 'beetle' button (or Run... Debug Program in the menu)?

 

On 03/03/2020 21:05, Richard Russell wrote:
On Tue, Mar 3, 2020 at 08:43 PM, Leslie Baker wrote:
Don't worry any further it is really a small problem
It is NOT a small problem.  I pride myself that my software products have no bugs, and that if any are discovered I try to fix them quickly (I know I still haven't updated BB4W after the recent bug was discovered, but I am working on it).  So I do worry, and I am very concerned about this apparent malfunction, not least because I can't reproduce it here.

I changed a letter in a PRINT statement and ran it. It told me 'Bad use of array' (It was followed by a TAB),
> I then had to close the display window with the X.


We are talking about BBCSDL running on a Linux platform, yes?  So you didn't 'have to' close the program's window with an X since it is running in a different process from the IDE, indeed it's better not to if you want the error line to remain highlighted.  What did you mean by "had to" there?

The cursor was about 12 lines below the error.

Strange.  You are definitely running my SDLIDE and not Andy's BBCEdit?  There is definitely no ON ERROR statement in your BASIC program?

Would you please be kind enough to repeat the test you did, but to save the program with the deliberate error to file and send it to me as a zipped email attachment (don't post it here, send it as a personal email).  That will make it easier for me to reproduce exactly what you did.


The display window the program opened up was almost full screen. I suppose I could have dragged it down to see the code? Next time I get chance I will do that rather than close it in case the closing moves the cursor in the editor window?



Richard Russell
 

On Tue, Mar 3, 2020 at 09:21 PM, Leslie Baker wrote:
The display window the program opened up was almost full screen. I suppose I could have dragged it down to see the code?
Minimize it, don't close it.  To help with debugging you may want to read something from the List Variables window, and closing the program causes this window to close as well as the error highlight to be cleared.

 

On 03/03/2020 21:18, Richard Russell wrote:
On Tue, Mar 3, 2020 at 09:05 PM, Richard Russell wrote:
Strange.  You are definitely running my SDLIDE and not Andy's BBCEdit?  There is definitely no ON ERROR statement in your BASIC program?
And, just for absolute clarity, you definitely ran the program in Debug Mode by clicking on the 'beetle' button (or Run... Debug Program in the menu)?


I have two desktops, both with the same op system and SDLIDE. I am showing my ignorance again .. Sorry. I tested on both machines, and when I clicked the beetle a smaller window came up with all variables and the error'd statement listed. The problem was occurring because I was using the normal RUN from the menu. Sorry to waste your time Richard. You have done a good job with this IDE.



Richard Russell
 

On Tue, Mar 3, 2020 at 09:39 PM, Leslie Baker wrote:
The problem was occurring because I was using the normal RUN from the menu
Did you not read this, which I posted earlier in the thread:

"I've just checked it here and in both BB4W and BBCSDL (Windows edition, in Debug mode) an untrapped error highlights the line"

Or this, also from earlier:


"The reason, incidentally, why BB4W highlights the error line always and BBCSDL only in Debug Mode..."

What more could I have said to make it clear that, in BBCSDL, highlighting the error line only works in Debug mode?  I even gave a detailed technical explanation of why that is, on the basis (I hoped) that understanding something makes it easier to remember than simply being told it as a fact.