[Implemented] Very long statements

[blueznl]

Well, then how come my implementation works?

Have you ever tried it?

(It works because I use [space][underscore] at the end of a line, OR [underscore][space] at the start of a line, thus not conflicting with variable names.

[Kaeru Gaman]

Well, then how come my implementation works?

because it eliminates the _ as variable and makes it the connector.
your example will not work when you use _ as a variable name.
not a PART of a name, a NAME.

Code: Select all

_ = 1

a = 3 * _

Debug a

runs WITHOUT your code, _ is a variable name.

[benco5000]

Well thank you very much. I downloaded codecaddy and now my code looks perfect. Onward and upward.

[blueznl]

Well, then how come my implementation works?

because it eliminates the _ as variable and makes it the connector.
your example will not work when you use _ as a variable name.
not a PART of a name, a NAME.

Code: Select all

_ = 1

a = 3 * _

Debug a

runs WITHOUT your code, _ is a variable name.

You are not serious, right? Using an underscore by itself as a variable name is about as bad as using 20 colons on a single line, or using Goto's... No, it's even worse! Brrrr.... I hope I never have to maintain any of your code if consider a single underscore by itself a sensible variable name... brrrr...

To me, it's amazing it's even allowed! Well, there's one feature I'm more than happy to say goodbye to, in exchange for multilining. That definitely is little of a sacrifice IMHO etc. etc.

[Kaeru Gaman]

sure it's bad style.

but it is allowed like every single-char-name using a valid first charakter...

using _ for a connector breaks this.
no matter it is something it's no pity to be broken - but you have to be aware of it.
and it may be causing a problem when trying to implement it as a native IDE feature.

not that I could care less...
I neither care for _ as a variable name nor for long lines, both is bad style.
but I realize there is a conflict.
"interesting" would Spock say - less than "fascinating" but "interesting".

[blueznl]

I neither care for _ as a variable name nor for long lines, both is bad style.

Your opinion, not mine.

[Kurzer]

If I remeber correct, there is a cheat for the IDEs Scintilla editor gadget to enable the word wrap feature.
Sorry, no link available, but I'm sure this feature exist.

You can install this cheat as a PB IDE tool to switch on/off the feature.
(I'm at work now so no time to search the related thread)

[ts-soft]

If I remeber correct, there is a cheat for the IDEs Scintilla editor gadget to enable the word wrap feature.
Sorry, no link available, but I'm sure this feature exist.

You can install this cheat as a PB IDE tool to switch on/off the feature.
(I'm at work now so no time to search the related thread)

Code: Select all

EnableExplicit

Define scintilla = Val(GetEnvironmentVariable("PB_Tool_Scintilla"))
If scintilla
   SendMessage_(scintilla, #SCI_SETWRAPVISUALFLAGS, #SC_WRAPVISUALFLAG_START, 0)
   SendMessage_(scintilla, #SCI_SETWRAPSTARTINDENT, 16, 0)   ; <-- indent amount
   SendMessage_(scintilla, #SCI_SETWHITESPACEFORE, #True, RGB($70, $50, $d0))   ; <- colour of marker
   SendMessage_(scintilla, #SCI_SETWRAPMODE, 1 - SendMessage_(scintilla, #SCI_GETWRAPMODE, 0, 0), 0)
EndIf
End

but i can't say the author

[#NULL]

DoubleDutch posted two tools for toggling line-wrap in the IDE:
http://www.purebasic.fr/english/viewtop ... 85&start=0

[epidemicz]

I neither care for _ as a variable name nor for long lines, both is bad style.

Your opinion, not mine.

How come everyone else hates the _. _ seems the easiest to implement, a C style would be way more complicated.

_ isn't ugly!

[Foz]

Macro _
s
EndMacro

Of cour_e it i_n't ugly, we would ju_t not u_e it in normal _peech.

[blueznl]

Epidemicz, _
I have _
no clue...

[Melissa]

3 pages and still no mentions of infamous '..' ? Pathtetic.

[blueznl]

3 pages and still no mentions of infamous '..' ? Pathtetic.

I think that's because it would take one character more

[Rescator]

A naturally line breaking is preferred, like:

Code: Select all

If x=1 Or
  z=4
  ;blabla
EndIf

The Or clearly indicate there is more, if the parser sees a line break following or a ; comment (any whitespaces before end of line is obviously ignored as well)
the parser looks at the next line, if the two lines concatenated does not produce an error then it's likely correct,
if it causes an error then the coder did a mistake most likely.

Similar with this:

Code: Select all

 Define.i event=#Null,window=#Null,gadget=#Null,menu=#Null,type=#Null,
          quit=#False,timer=#Null,result=#False,selected,id,i,text$

Again the line is incomplete (broken) so the parser concatenates with the following line.
In 99.99% (!) of all code there is a "natural" break, like a , or + or | or - and so on.
Only issue might be really long text strings, but then you could always use "blah" + "blah" in those cases I guess.

Again the example above, but this time coded wrong intentionally obviously (Define line appears complete):

Code: Select all

 Define.i event=#Null,window=#Null,gadget=#Null,menu=#Null,type=#Null,quit=#False
          ,timer=#Null,result=#False,selected,id,i,text$

Or this which is also wrong (missing , ):

Code: Select all

 Define.i event=#Null,window=#Null,gadget=#Null,menu=#Null,type=#Null,quit=#False
          timer=#Null,result=#False,selected,id,i,text$

Here the parser has no indicator that it's incomplete and it wont throw an error on the 2nd line at all, which could be an issue, but...

My suggestion Fred is to ONLY allow this natural line breaking to be used if EnableExplicit is ALSO used,
as EnableExplicit will catch the mistake above (since timer is not defined previously).

If EnableEplicit is not used then do not allow natural line breaks and throw the error it would currently throw if you try the second to last example above,
the last example however would be ok without EnableExplict, but again if those who wish to use natural break points in statements is told they also need to use EnableExplicit such errors will get caught.

PS! Regarding EnableExplicit, it would also be nice to have a way to enable it by default in compiler options somewhere. But that's just me nitpicking (or make it default always and add a DisableExplicit maybe)

Edit:
Just a quick rundown on how the parser would handle it:
1. The parser strips off any comment at the end if found, it also trims whitespace (I'm assuming this is how it currently does it)
2. The line seems to end with a , or some other operator like + Or And | & and so on that can act as a natural break point for a line.
3. If EnableExplicit is on then check if the next line concatenated with current line is syntactically right and a syntax error if not, and if EnableExplicit is off throw a syntax error immediately.

Unfortunately there is no easy way to check both EnableExplicit is off and something like the last example is encountered, then again, with EnableExplicit off a lot of weird bugs are possible anyway, like text="test" when you intended to type text$="test" etc.

I see no point in introducing a line continuation character at all,
no matter how tempting it might be,
it's also more natural to use "natural" break points,
like in this paragraph where I've used , as the natural break point of a long line.