highlightjs / highlight.js

JavaScript syntax highlighter with language auto-detection and zero dependencies.
https://highlightjs.org/
BSD 3-Clause "New" or "Revised" License
23.31k stars 3.52k forks source link

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

Open Ruard opened 4 months ago

Ruard commented 4 months ago

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.

joshgoebel commented 4 months ago

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

akhtarmdsaad commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

joshgoebel commented 4 months ago

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.