nyamatongwe
commented
7 months ago See earlier Escape of EOL in JS string does not work.
Closed ajtruckle closed 6 months ago
nyamatongwe
commented
7 months ago See earlier Escape of EOL in JS string does not work.
ajtruckle
commented
7 months ago @nyamatongwe Sorry, but what is the linked article really saying specific to my case? Thank you.
mpheath
commented
7 months ago @ajtruckle It is like a note to self as reference. Still as you mention, related to backslash escape though none in the examples at end of line like your example.
@nyamatongwe My curiosity tingles as why single quotes have different styling behaviour to double quotes in Javascript when they are supposed to be interchangable.
Double quotes:
Single quotes:
I would expect these 2 code blocks to be the same. Surely one is right and the other is not. This is why I mentioned the workaround of trying single quotes in the linked post at Notepad++ as an immediate action to correct the styling.
Reference: https://www.javascript.com/learn/strings
nyamatongwe
commented
7 months ago @mpheath
@ajtruckle It is like a note to self as reference.
An issue will often be examined by multiple people and they may accumulate links to reference documents (what does the standard say?) and code history. Its unlikely I'll write a patch for this but I checked git log and git blame to see what occurred. Looking at the history can indicate if this was a deliberate choice - its easy to unfix things. The bug led to change 3fa90846f3268f821b5ef20363908e04639cc3a2.
Still as you mention, related to backslash escape though none in the examples at end of line like your example.
The issue is poorly formatted and a newline can be seen in the first line of script if edit (only admins) is pressed.
<script type="text/javascript">//<![CDATA[
var x = '<table>\
</table>';Possibly the poster battled mark-up and lost or it was a victim of SourceForge changing over time. This was originally bug #3038381 as listed in Lexilla history before SourceForge renumbered all the issues. I have updated the formatting to show the intention.
I would expect these 2 code blocks to be the same. Surely one is right and the other is not.
Some languages have different escape rules for different string quotes so there may be historical reasons or it may just be that the contributor wasn't aware they should be the same.
mpheath
commented
7 months ago @nyamatongwe Thanks for the information. I did not consider the markdown at Scintilla got messed up, my mistake.
As they say, "don't fix if not broke". The bug fix done by Stephen Deibel appears to work with single quoted strings and I cannot seem to break it, so I'll go with the option to apply the same fix to the double quoted strings.
ajtruckle
commented
6 months ago I appreciate your closing the issue. But Notepad++ still renders my file as I originally reported. Does this commit mean Notepad++ will have another update with the newer editor control?
mpheath
commented
6 months ago @ajtruckle The issue is fixed and closed here at Lexilla. Lexilla 5.3.0 has been released with this fix.
Notepad++ will probably have a Pull Request submitted in a few days to merge the new releases of Scintilla and Lexilla. Time may depend on the holiday season.
If everything goes OK, the next release of Notepad++ will have this fix.
In SciTE 5.4.1 which has been just released with the fix looks like:
If you want the fix any quicker, then you may need to compile Notepad++ yourself with the fix.
Does this commit mean Notepad++ will have another update with the newer editor control?
Expectation is yes as to the routine of Notepad++.
I originally reported this issue on the Notepad++ forum. See the linked issue for explanation.
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/14413
You can use
\to split long lines of text over multiple lines in the editor for clarity. But the syntax highlighting goes not respect this. The second line after\should continue as a "string" colour. And ideally the\itself should be a different colour to make it stand out.