I don’t know if this is a problem in Prism or in Obsidian. It’s not listed as a known failure in Prism - Known failures ▲ Prism
If a string literal enclosed by ‘single quotes’ ends on a , syntax highlighting fails to recognize the end-of-string character.
declare @path nvarchar(10) = 'd:\temp\' -- this is colored as part of the string
declare @s2 nvarchar(2) = '2' -- this is colored as part of the string
The problem does not occur with strings that are enclosed by “double quote”, but in languages like SQL that uses single quotes for strings it can cause rather weird results. It’s not a huge problem but nice if it’s an easy fix.
(As a workaround, one can add a single quote in a comment. Obsidian highlighting ends the string there, but the code is still correct since it’s in a comment.
declare @path nvarchar(10) = 'd:\temp\' -- '
declare @s2 nvarchar(2) = '2' -- this line is correctly colored, due to the final singlequote on line 1.
It seems like a rand case related to using backslash as an escape character, so it might be “fixed” if you use a double backslash, which is the proper way to do it. (In some language you could also double (or triple) up on the quotes).
Using a double backslash is a poor solution. Yes, it fixes the highlighting problem, but it changes what the code does (i.e. it changes the output if I copy the code into Management Studio and run it unedited). The workaround I described in the first post - adding " – ’ " at the end of the line - is better as a workaround, since it doesn’t involve changes to the non-comment part of the code.
Sorry, if I was a little too brief in my previous reply as I was on mobile, but wanted to give a little input. My point was to illustrate that we potentially are in a little grey area, since backslash is often an escape character, and as such could need escaping.
When looking a little closer into your specific case within SQL, and as you state it’s legal code for SQL Server, just syntax colored wrong. However, this seems to be a Prism thing, and not Obsidian, if I’m not mistaken.
If you go to Test drive ▲ Prism, and enter your statements, you’ll get the same behavior, as shown in the following output:
Whether it’s a bug/feature/… in Prism someone else needs to respond to, but I’m kind of assuming it’s a tricky one since they’ve only got one SQL language specification, so it might need to allow for backslash as an escape character, which again means that it’s supposed to be a part of the string (due to the general nature of it specification).
