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

Cannot escape search operators #3867

Larivact opened this issue Mar 30, 2019 · 3 comments


None yet
3 participants
Copy link

commented Mar 30, 2019

Setup and configuration

  • SMW version: 3.0.1


While the documentation claims that search comparators can be escaped:

Here and in all other uses of comparators, it might happen that a searched for value really starts with a symbol like <. In this case, SMW can be prevented from interpreting the symbol as a comparator if a space is inserted after ::. For example, [[Property:: <br>]] really searches for pages with the value "<br>" for the given property.

they apparently cannot. This is probably a regression.

demo at

If this gets fixed, I think all search operators (also !, ~ and !~) should be made escapable.


This comment has been minimized.

Copy link

commented Mar 30, 2019

demo at

A bug/issue report contains a clear, concise description of an issue. It is not my job to go around looking at links and try to interpret the intent or issue. Links are there to make references and clarify things, even help demonstrate an observation but the issue report needs a clear description of what has been observed by the reporting person as in: "The documention says [0] ".... " that white-spacing can be used in case of ... such as [[Has text:: <br>]] but it seems that ..." and so on.

This is probably a regression.

This not a regression to the previous release. In fact, there is no test that covers this use case and despite the description in the documentation " ... can handle those cases, value notations are white-space sensitive. To avoid confusion a space is inserted after :: ..." I would not support white-spacing as escaping pattern. There is an established \ character that signals an escaping intent so that should be relied upon to make that intent clear.

As for the matter of white spacing (untrimmed) the following may (haven't tested this) require a change to avoid trimming a "chunk".

@@ -579,11 +579,11 @@ class LegacyParser implements Parser {
 		$innerdesc = null;
 		$continue = true;
 		while ( $continue ) {
-			$chunk = $this->readChunk();
+			$chunk = $this->readChunk( '', true, false );

But you would we need additional changes to keep avoiding <br> from being HTML escaped.

I think all search operators (also !, ~ and !~) should be made escapable.

Same as above, for any one interested in implementing this, use \ as escaping character.


This comment has been minimized.

Copy link

commented Mar 30, 2019

I apologize for the caused hassle, updated the description accordingly and will keep that in mind. Regressions can go unnoticed for multiple releases (especially if there is no test). I agree that a backslash is more fitting.


This comment has been minimized.

Copy link

commented Apr 1, 2019

I am pretty sure that this worked in 1.8.x but this was years ago and I cannot tell when this went bellies up. Anyways a solid solution with backslash for all operators will be nice to have. Though this is technically a bug I will label this as an enhancement.

@kghbln kghbln added the enhancement label Apr 1, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.