0.12.18 released

[lettersquash]

It may also seem a backward step to put every keyword together in alphabetical order, but one of the things that slowed down my introduction to sB was the sections, since it's not immediately obvious which section a keyword might be under. This is especially true when you don't know what you're looking for, but is actually just a logical problem with any tree or discrete section structure. It leads to repetitions, like PEN, which is listed under Console with barely any information, and under Graphics with the full list of parameters. What's ARC, or PTDISTLN, maths or graphics - so it goes on, slowing you down looking stuff up every time you write a new line of code as a newbie. Where should PRINT be, since it can be to the console or a file? It could be useful in an alphabetical list to indicate those categories with each keyword, but they're more like tags than sections.

Do you have any specific suggestion of how you'd like this to appear? I can add it to this page:

https://smallbasic.github.io/pages/reference.html

What tends to work for me is an alphabetical list of keywords on one page, and I guess it would be good if they were on that main reference page, with a link direct to the details page for each keyword. Ideally, each keyword in the alphabetical list would also have a brief explanation next to it. But I'm aware you've got a more important task with the actual language, so if it's just me requesting this, don't make it a priority.

I have made a start on something myself. I don't know if I'll stick at it, but I hope so. I might get inspired. It's helping me learn more of the language as I do it. I've also remembered that there's a lot more to a language than the keywords, so I'll have to work out what to put in and how it might look and operate. It could be useful to have certain special characters like <<, &, @, etc. in the list itself, or headings like Special Characters that link to another page.

I wondered about making it an actual smallBASIC program, but I'm not sure how that would work. Probably better would be to output the data to an html file, adding the tags for the formatting programmatically.

So far, I've gathered the keywords from all the reference categories, sorted them and put them in column 0 of an array, with other columns for reference syntax, tags (largely reproducing the sections of the current help), description, examples, further notes, and related keywords. Most of that is populated by zeros - I've filled in the other bits as far as absmin(). Incidentally, I'm toying with writing them all in lowercase, and putting parentheses at the end when they take them.

It could be tabulated in a single html page, which might give that overview and searchability I wanted, but each item could also link to more detailed discussion or longer examples of code where available. Currently I'm working on displaying the data in the program itself, and routines to deal with structural changes like adding 'columns'. Since it's all in a text file that loads into the array, I can add information to the file in Notepad or whatever and save it, and I can copy a lot of it off the web, but it'll take a bit of time.

[chrisws]

It may also seem a backward step to put every keyword together in alphabetical order, but one of the things that slowed down my introduction to sB was the sections, since it's not immediately obvious which section a keyword might be under. This is especially true when you don't know what you're looking for, but is actually just a logical problem with any tree or discrete section structure. It leads to repetitions, like PEN, which is listed under Console with barely any information, and under Graphics with the full list of parameters. What's ARC, or PTDISTLN, maths or graphics - so it goes on, slowing you down looking stuff up every time you write a new line of code as a newbie. Where should PRINT be, since it can be to the console or a file? It could be useful in an alphabetical list to indicate those categories with each keyword, but they're more like tags than sections.

Do you have any specific suggestion of how you'd like this to appear? I can add it to this page:

https://smallbasic.github.io/pages/reference.html

What tends to work for me is an alphabetical list of keywords on one page, and I guess it would be good if they were on that main reference page, with a link direct to the details page for each keyword. Ideally, each keyword in the alphabetical list would also have a brief explanation next to it. But I'm aware you've got a more important task with the actual language, so if it's just me requesting this, don't make it a priority.

I have made a start on something myself. I don't know if I'll stick at it, but I hope so. I might get inspired. It's helping me learn more of the language as I do it. I've also remembered that there's a lot more to a language than the keywords, so I'll have to work out what to put in and how it might look and operate. It could be useful to have certain special characters like <<, &, @, etc. in the list itself, or headings like Special Characters that link to another page.

I wondered about making it an actual smallBASIC program, but I'm not sure how that would work. Probably better would be to output the data to an html file, adding the tags for the formatting programmatically.

So far, I've gathered the keywords from all the reference categories, sorted them and put them in column 0 of an array, with other columns for reference syntax, tags (largely reproducing the sections of the current help), description, examples, further notes, and related keywords. Most of that is populated by zeros - I've filled in the other bits as far as absmin(). Incidentally, I'm toying with writing them all in lowercase, and putting parentheses at the end when they take them.

It could be tabulated in a single html page, which might give that overview and searchability I wanted, but each item could also link to more detailed discussion or longer examples of code where available. Currently I'm working on displaying the data in the program itself, and routines to deal with structural changes like adding 'columns'. Since it's all in a text file that loads into the array, I can add information to the file in Notepad or whatever and save it, and I can copy a lot of it off the web, but it'll take a bit of time.

Thanks for the clarification. Parts of the web site are generated using SmallBASIC. Have a look here:

https://github.com/smallbasic/smallbasic.github.io/tree/master/_build

I put this all together fairly quickly, but hopefully it's not too indecipherable 

It should be fairly trivial to make the change.

[lettersquash]

Thanks for the clarification. Parts of the web site are generated using SmallBASIC. Have a look here:

https://github.com/smallbasic/smallbasic.github.io/tree/master/_build

I put this all together fairly quickly, but hopefully it's not too indecipherable 

It should be fairly trivial to make the change.

I see you've changed it already! It looks like you've got such a good handle on the data that it is "fairly trivial" to rearrange it, so I'll say a bit more, and you can decide for yourself. What you've put up now solves one issue I found as I started with smallBASIC, having to navigate through sections like "Console" and think where something might be before I go look for it, then backtrack to see if the thing I'm looking for is under "System" or somewhere else. I see those are still there when you click "More..." and linked elsewhere, so hopefully I haven't messed things up for people who liked it the way it was. 

However, personally, I wouldn't put all the keywords in a list with spaces and bullet points, as they're hard to read that way, but down the left hand side with linebreaks (leaving space for short descriptions next to them or under them, ideally, so you might not even have to nagivate - you might just scan for "COSH", for example, to confirm it's there, or for "MSGBOX" to realise it's not there and think, oh yeah, didn't I see something under WINDOW?...). It's easy enough to find something in an alphabetical list by scrolling in a browser page, and easier, IMHO, than reading them in a block.

This has made me rethink my project to write a new, "comprehensive" help file - I don't know what I was thinking, to be honest (blame it on lockdown). I'm far too ignorant of the language, html, github, Android and Linux (and Windows! ), not to mention being easily distracted onto something else! Maybe I can help more with the occasional bug-catch or suggestion for an improvement to the existing details pages, which are lacking on some, very detailed on others.

I must say, having the context-sensitive help on F1 and F2 is absolutely amazing and I use those all the time. It's likely the sections - graphics, console, etc. - will suit many other people, and maybe I find them more useful than I realise now I'm more familiar. And of course it could be cumbersome in the F1 help in the editor to list all the keywords in one go especially as you have to scroll with the arrow keys.

ETA: If you do entertain the idea of a long vertical list as per my suggestion, it might be best not by default on the reference page, but with the sections list as it was and a link, "All keywords...", or "Full alphabetical reference list" (if more than just keywords is included).

Much appreciated,
¬~

[lettersquash]

My god, sorry, I seem to have taken over the whole sB forum! Just to say, on looking again, that new reference page is actually fine as it is, so I hope you don't go to further trouble. My helper script has taken an interesting turn, not now looking at writing html, and more towards an app to run alongside the IDE, so for now I'll keep working on it. Will post a new thread if it's worth sharing.

[round157]

Erm...I dunno, I guess it depends what it involved and if Chris or whoever- the forum owners - asked me, but I'm only slightly familiar with sB really. I ask lots of newbie questions myself. I've got long experience with BASIC, although mostly with an ancient version. Moderating would normally be day-to-day administration, like - if we had sub-boards - moving things to an appropriate place, 'policing' the guidelines, etc., so maybe you're as qualified as me for the role.

With numbers as they are, I don't suppose it would be a big job, but yeah, it looks like something Chris doesn't want to be doing too much of. From what he said earlier, it might also be useful if the moderator was actually fairly proficient with sB and with github - then they could add suggestions and bug reports posted here to the issues list there. Maybe if a moderator is an idea that catches on, the right person will volunteer.

If we don't want to be the moderators, I believe that it is still okay. SyntaxBomb's managment team will still do the moderation professionally!

SmallBASIC really needs several child boards. Do you have any idea? After we come to a final conclusion, we should apply for some child boards in the official suggestion thread.

[round157]

At this stage I'm just making minor incremental changes, mostly from suggestions such as this one!

Do you mean that the development of SmallBASIC nearly stopped? Oh....

No I think he means at this moment small changes are being made, he says nothing about stopping development at all.

Okay! Thanks for explaining.

[chrisws]

Did you see this? Scroll down to "How to help design a better looking editor color theme" https://smallbasic.github.io/pages/sdl.html

Thank you!!! I have edited the text file and the file name is settings.txt. I uploaded to this forum. You can download in this post and the colour combination may be liked by you.

The theme looks really nice. I'm using it in the next update. Just a quick question, mind if I call it "R157"?

Also, the themes will be selectable from the context menu in the start screen. This will be in the SDL and android versions.

I haven't done a huge amount of work on SB but plan to release what I have soon (I got side tracked writing an online cards game to play with family in the c19 shutdown - it's all ready for wave 2 lol).

[iWasAdam]

Another thing to really put time into is how everything fits together with icons color, etc.

Here's a shot of an editor with everything working together:
- On the left is the code view. note the colors and icons.
- On the right is the code editor, note the line numbers with the same icons and colors

[round157]

Another thing to really put time into is how everything fits together with icons color, etc.

Here's a shot of an editor with everything working together:
- On the left is the code view. note the colors and icons.
- On the right is the code editor, note the line numbers with the same icons and colors

The above idea is nice.

[round157]

The theme looks really nice. I'm using it in the next update. Just a quick question, mind if I call it "R157"?

It is an unusual name. However, it is also a very appropriate name.

Also, the themes will be selectable from the context menu in the start screen. This will be in the SDL and android versions.

I tried this new version and the above function is very convenient for users.

I haven't done a huge amount of work on SB but plan to release what I have soon......

You are active and diligent in developing SB. Thank you!