Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(basic) Closing quotation marks are not required for a PRINT statement (gwbasic) #3996

Open
Ruard opened this issue Feb 22, 2024 · 7 comments
Labels
enhancement An enhancement or new feature good first issue Should be easier for first time contributors help welcome Could use help from community language

Comments

@Ruard
Copy link

Ruard commented Feb 22, 2024

Describe the issue
I may be wrong and this probably depends on basic dialect, but it seems (I found some old code that runs) that for gwbasic closing quotation marks are not required for a PRINT statement. The interpreter seems to assume that the end of the line closes the string (like there was a quotation mark).

In this case, when an ending quotation mark is omitted, the following line(s) are part of the string until a quotation mark is found.

afbeelding

Which language seems to have the issue?
basic. And in my case specifically for gwbasic code.

Are you using highlight or highlightAuto?
highlight: language-basic

Sample Code to Reproduce

10	CLS
20	INPUT "Hoeveel paarden ";H:CLS
30	LOCATE 1,1:PRINT "╔════════╦════════════════════╗
40	PRINT "║ nummer ║ naam               ║
50	PRINT "╠════════╬════════════════════╣
60	FOR F=1 TO H
70	LOCATE 23,2:PRINT "Paard";F:LOCATE 23,10:INPUT P(F)
80	GET #1,P(F)

Expected behavior
At line 30 the symbols after " should be highlighted as string for the rest of the line. Line 40 however should start with the normal highlighting as it is not part of a continued string.

It mentioned the PRINT statement but this is also the case for e.g. CHAIN and LOAD.

@Ruard Ruard added bug help welcome Could use help from community language labels Feb 22, 2024
@joshgoebel
Copy link
Member

What is the behavior of most other basic intepretters I wonder when a line break is inserted in the middle of a string?

@akhtarmdsaad
Copy link
Contributor

In Python also, string highlighting goes wrong

Line break in Python

Same goes for cpp
Cpp

This mode may help to overcome this issue
https://highlightjs.readthedocs.io/en/latest/mode-reference.html#endswithparent
Any suggestions ... ?

Is there any need to open issue for them (python and cpp)??

@joshgoebel
Copy link
Member

I don't see any issues with python or cpp examples provided. We do not care about invalid syntax.. If invalid syntax highlights poorly (or not at all), that is not our concern. We do our very best to highlight valid syntax.

@Ruard
Copy link
Author

Ruard commented Feb 29, 2024

What is the behavior of most other basic intepretters I wonder when a line break is inserted in the middle of a string?

I'm not into basic interpreters, so don't take my word for it. But I suppose there is a difference between e.g. Qbasic and GWbasic. The first one reads blocks of code while GWbasic reads one line of code, though this line may contain multiple statements separated by colons. If I'm correct Qbasic allows line numbers while for GWbasic the line numbers are mandatory.

I think your other comment about invalid syntax is interesting. Though in this case the syntax is valid and code will run, you can argue that it is at least bad code. Like invalid XML that works because the browser fills in the gaps. This is a thin line.

The solution I had in mind (if this is not too complicated or too much work) is to create a rule for basic code that has line numbers. When (all) lines start with a line number then an 'open string' is closed when either a quotation mark or line break is encountered and in other cases this rule is ignored. But I can live with it when you decide to close this issue as 'will not repair', because of this thin line.

@joshgoebel
Copy link
Member

Though in this case the syntax is valid and code will run

The one python example I tried was not valid. But valid or not the highlighting looked "fine" to me for most or all the cases - so it's not clear to me what behavior you're expecting in the CPP or Python cases if you don't show a "correct" version (perhaps from another highlighter, etc).

@Ruard
Copy link
Author

Ruard commented Mar 1, 2024

@joshgoebel Please note, this issue is not about Python or CPP, it's about Basic. So can we please focus on Basic?

@joshgoebel
Copy link
Member

I go where the wind blows. :-)

I did some quick research. I think we'd be open to a PR that allows BASIC strings to terminate with EITHER the first " or newline that is found - whichever comes first.

@joshgoebel joshgoebel added good first issue Should be easier for first time contributors enhancement An enhancement or new feature and removed bug labels Mar 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An enhancement or new feature good first issue Should be easier for first time contributors help welcome Could use help from community language
Projects
None yet
Development

No branches or pull requests

3 participants