Seems to be caused by unrecognized INCLUDEs: T171934

+ strings starting with a single quote

Could you please give an example of a query, and maybe a screenshot?

this

It would be good to have a way to de-activate this.

Do you mean the dots under WITH ?

This is the client side SPARQL validation which is complaining about named subqueries which are not part of the spec, but supported by Blazegraph.
Maybe they will eventually add this to the parsing engine of SPARQL.js

If you like I could make the client side validation appear yellow.
Would this make it better for you?

Depending on the query, half the page is red and the query still works fine.

It's just distracting to see it colored.

T172126

With http://tinyurl.com/y9ekltr7 WITH and its parts in "{ ... }" get sometimes dotted and I agree that it is distracting. It would be better with SPARQL.js switched off then or something like

.error-line {
    border-bottom: 2px dotted white;
}

Or whatever.

Interestingly enough, what I see with the query above is just "WITH {" being underlined, but the rest is fine. Browser differences?

Update: spoke too soon, in fact when you edit it, the whole part inside WITH is red-lined. It is pretty distracting, I wonder if it's possible to do something about it.

@Smalyshev Try to add an empty newline at the top. That usually does it.

As fixing WITH highlighting was declined (T171934) can we just get rid of this feature? It isn't of much use if it's based on wrong assumptions.

In T171935#3516719, @Jonas wrote:

Reported to upstream:
https://github.com/RubenVerborgh/SPARQL.js/issues/43

This should be Stalled or Open, not Resolved, if the task is an upstream fix, only to be closed when we get a pull from upstream.

In my opinion it is not outside the component developer, as the SPARQL.js just could be disabled here on WDQS. In my opinion the red dots confuse more than syntax highlighting helps (when there is no WITH). If WDQS could be personalized I would switch SPARQL.js off.

The recent update of the query service GUI has just too many defects. I think we'd better revert to the previous one.

@Lydia_Pintscher why isn't there anything being done about the defective query service GUI ?

So, I am a little confused about the escalation here ...

1. We reported the problem upstream.
2. For me it seems named sub queries are a rare edge case only used by experts.
3. We should empathize with beginners and think of the usefulness of that feature for them.
4. It is just a optical glitch comparable to a wrong spelling correction annotation.

So, please comment on this ticket https://github.com/RubenVerborgh/SPARQL.js/issues/43#issuecomment-321711123 and the issue will be fixed soon.
Thanks.

I just want to know why we got an incompatible syntax highlighter.

I'm sure the highlighter is perfectly helpful on other websites, but the GUI at Wikidata Query Service has deteriorated over the last two weeks and this is one of its causes.

It's possible that the discussion of this shouldn't take place in the ticket about the problem. Apparently, it's a known issue that just isn't consider relevant by the person who changed the GUI.

I wonder how hard would it be yo just temporarily remove the dots thing altogether, pending the upstream fix. We can keep the syntax highlighting, but drop the dots part for a while.

I think someone pointed to error-line{border-bottom:2px dotted red} (I forgot who). https://query.wikidata.org/css/style.min.0d7eafbda8bb1aa11051.css. Changing red to white seems to do it.

This is the line to disable the SPARQL.js error highlight
https://github.com/wikimedia/wikidata-query-gui/blob/master/wikibase/queryService/ui/App.js#L262

Change 371470 had a related patch set uploaded (by Smalyshev; owner: Smalyshev):
[wikidata/query/gui@master] Temporarily disable highlighting parse errors

https://gerrit.wikimedia.org/r/371470

Change 371470 merged by jenkins-bot:
[wikidata/query/gui@master] Temporarily disable highlighting parse errors

https://gerrit.wikimedia.org/r/371470