IDE improvements (v1.5)

[RhoSigma]

As there's a lot movement in the IDE development lately, I'd like to remind you about this proposal, already made before v1.4 became offical:
https://www.qb64.org/forum/index.php?topic=2103.msg113469#msg113469

Maybe v1.5 can make it possible.

[Petr]

Just a little thing, Fellippe. I downloaded the latest IDE from Github for the _MOUSEMOVEMENT test (this works great now). The IDE tells me that it will compile to the folder where QB64 is. OK. Then check the option to compile to the source folder. A message appears stating that it will be compiled to the source folder. It's alright. BUT, if after this option you don't at least make a space in the source code, you just don't take any action, you just change the option and choose to run, the new compilation won't take place.

[FellippeHeitor]

Just a little thing, Fellippe. I downloaded the latest IDE from Github for the _MOUSEMOVEMENT test (this works great now). The IDE tells me that it will compile to the folder where QB64 is. OK. Then check the option to compile to the source folder. A message appears stating that it will be compiled to the source folder. It's alright. BUT, if after this option you don't at least make a space in the source code, you just don't take any action, you just change the option and choose to run, the new compilation won't take place.

It is an expected behavior, Petr, but thanks for bringing it to light, I'll maybe add a more informative message.

PS: @Petr the latest dev build pushed today has this behavior reworked. Please try it when you can and let me know.

[Petr]

Hi Fellippe. Is it this version? https://github.com/QB64Team/qb64  I see more information texts, but is possible having this output: Open blank IDE, write there just CLS, click to RUN - START. Untitled.exe is created and then run. Now Save your work as test.bas. Click to RUN - MAKE EXE ONLY. You give info, that untitled exe is already created - but your program name now is different. It is just detail, i know. I don't want to be an eternal troublemaker and grumbler ... of course otherwise the IDE is absolutely great!!!

[FellippeHeitor]

The latest version is always at https://www.qb64.org/portal/development-build/

I'll see about that detail - but you gotta agree that your program was already compiled as is, even though the name is different, right? 😉

The latest version will not only say it already created the EXE, but will also link to it in the status area, so you can just click it to go there.

[Petr]

Yes, you're right :) I'll look again, this time at the correct version. You have a lot of patience with me :)

[Petr]

Now the IDE monitors the previously described problem and compiles after changing the folder, without user interference to the program. Good job!

[Petr]

Hi, @FellippeHeitor  I remembered one more thing if you wanted to deal with it... but it's really a small thing. Field name letters when used with LBOUND or UBOUND are still different. This is still such a small fly in the IDE. I'm running to work with _MEMSOUND. :)

[FellippeHeitor]

Proper array name capitalization in UBOUND/LBOUND calls is my greatest IDE defeat to this day! 😂

[FellippeHeitor]

@RhoSigma I promised to look, but ended up forgetting since the issue wasn't mentioned in the repository. I'm having a look at it now.

Edit: Looking at the code you provided, it seems troublesome to deal with already. For example, this:

Code: QB64: [Select]

1. IF 1 THEN
2. a$="Hello "+_
3.    "World "+_
4.    "!!"
5. END IF
6.  

would not be turned into this:

Code: QB64: [Select]

1. IF 1 THEN
2.     a$="Hello "+_
3.        "World "+_
4.        "!!"
5. END IF
6.  

But instead into this:

Code: QB64: [Select]

1. IF 1 THEN
2.     a$="Hello "+_
3.     "World "+_
4.     "!!"
5. END IF
6.  

You see how the intentional indentation added by the user gets lost immediately. I, for one, use line continuation for the exact purpose of string concatenation (with the occasional IF line that gets too long). So I'll write something like:

Code: QB64: [Select]

1.             IF TotalSUBs = 0 THEN
2.                 l$ = l$ + "  Type  Arguments"
3.                 lSorted$ = l$
4.                 lSized$ = lSized$ + " Line count  Type  Arguments" + sep
5.                 lSortedSized$ = lSortedSized$ + " Line count  Type  Arguments"
6.             ELSE
7.                 num$ = LTRIM$(STR$(TotalLines(TotalSUBs)))
8.                 IF pInsideDECLARE THEN num$ = "external"
9.                 lSized$ = lSized$ + CHR$(195) + CHR$(196) + pn$ + "  " + _
10.                           CHR$(16) + CHR$(2) + SPACE$(9 - LEN(num$)) + num$ + "  " _
11.                           + psf$ + CHR$(16) + CHR$(16) + pargs$ + sep
12.             END IF

And I'd hate to have it automatically turned into:

Code: QB64: [Select]

1.             IF TotalSUBs = 0 THEN
2.                 l$ = l$ + "  Type  Arguments"
3.                 lSorted$ = l$
4.                 lSized$ = lSized$ + " Line count  Type  Arguments" + sep
5.                 lSortedSized$ = lSortedSized$ + " Line count  Type  Arguments"
6.             ELSE
7.                 num$ = LTRIM$(STR$(TotalLines(TotalSUBs)))
8.                 IF pInsideDECLARE THEN num$ = "external"
9.                 lSized$ = lSized$ + CHR$(195) + CHR$(196) + pn$ + "  " + _
10.                 CHR$(16) + CHR$(2) + SPACE$(9 - LEN(num$)) + num$ + "  " _
11.                 + psf$ + CHR$(16) + CHR$(16) + pargs$ + sep
12.             END IF

Keep in mind the IDE wouldn't go as far as detecting these subtleties.

If you have any suggestions on how to proceed, I'm open to hear them.

[RhoSigma]

Thanks for looking into this Fellippe,

my thinking about it was to do something like a sub-formatter instead of running the concatenated line through the auto-formatter.

When the auto-formatter is processing a sourcefile, then I assume it always know the current indention level at any arbitrary line, i.e. it knows how many spaces need to be added in front of each line.

Now when the auto-formatter detects a line continuation (underscore at end of line), then it should enter some kind of sub-loop, in which it just adds the known amount of spaces right in front of the lines (I mean each single line, no need to concatenate the full line). This sub-loop is repeated until the line continuation ends (no more underscore at line end), then it falls back to the regular auto-formatting until the next continuation is found.

I'm not looking for a complete formatting, but just for correct indention, to avoid the disruption of the block alignment.

Code: QB64: [Select]

1. IF this THEN
2.     'the following is hand-formatted
3.     a$ = "Hello " +_
4.          "World " +_
5.          "!!"
6. END IF
7.  

If I later need to add e.g. another IF block, then the following will happen,

Code: QB64: [Select]

1. IF this THEN
2.     IF that THEN
3.         'the following is hand-formatted
4.     a$ = "Hello " +_
5.          "World " +_
6.          "!!"
7.     END IF
8. END IF
9.  

Now here it's easy to see, so I'd probably hand-adjust it again, but imagine a big block with 100 lines or even more which are out of my sight in the moment when I insert the new IF, then I'll probably forget about them.

[SMcNeill]

I’ve never played around with underscore continuation too much, but the issue might have to do with continued spaces from line to line.
     DO_
     NOT x

Now, is that a DO NOT x statement, or a call to sub DONUT x??  Where’s the space in that code?  How the heck do we deal with those?  I honestly don’t know, and aren’t at a PC to check at the moment.

If there’s no concern of lost spaces from line to line, then the solution might be as simple as having the IDE strip off any leading spaces on line two, and then auto-indenting to the proper place to line up as before.

With that, you’d end up with:

Code: QB64: [Select]

1.  IF this THEN
2.     'the following would be auto-formatted
3.     a$ = "Hello " +_
4.     "World " +_
5.     "!!"
6. END IF

Though I’d suggest adding one additional indent level to continued lines, just to make them stand out a little differently.

[STxAxTIC]

     DO_

If your line is so long that this is necessary, you're DOing wrong.

[SMcNeill]

If your line is so long that this is necessary, you're DOing wrong.

It’s just an example to highlight the concern.  I certainly don’t think anyone is using it for such short lines.  Feel free to imagine 200 characters of stuff in front of that DO, and then see it leads or trails spaces.

[RhoSigma]

If there’s no concern of lost spaces from line to line, then the solution might be as simple as having the IDE strip off any leading spaces on line two, and then auto-indenting to the proper place to line up as before.

No, that's exactly what causes the loss of user intended allignment, instead we just need to add the proper indention, BUT WITHOUT stripping any leading whitespace in the 1st place.

BTW - Thanks for the DONUTs :)