You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 4, 2024. It is now read-only.
Typing "lens" as a filter for a text column gets interpreted as "le ns", that is "<= ns".
There is a workaround of course: typing "= lens" or "eq lens".
I suppose there's some value in being able to type "le something" instead of "<= something", but this should only happen if the "le" is followed by a space.
I'd still prefer to be able to completely disable the text comparison operators. For example, French speakers would be surprised by the results of searching for "le something" compared to "Le Something" - even if their table provided case-insensitive search.
The text was updated successfully, but these errors were encountered:
Interesting behavior! Thanks for bringing this up. 'lens' -> '<= ns' is indeed pretty disturbing and should not behave this way.
The second part is more subtle. As-is, the plain string Le Something would not be handled correctly as the lexer does not support spaces inside "free form" strings and it is not probable that it will in the future. It would need to be either in quotes "Le Something" or escaped Le\ Something in order to be processed correctly; with the above bug fixed. A unquoted le Something will get evaluated to <= Something as intended as part of the filtering syntax.
Typing "lens" as a filter for a text column gets interpreted as "le ns", that is "<= ns".
There is a workaround of course: typing "= lens" or "eq lens".
I suppose there's some value in being able to type "le something" instead of "<= something", but this should only happen if the "le" is followed by a space.
I'd still prefer to be able to completely disable the text comparison operators. For example, French speakers would be surprised by the results of searching for "le something" compared to "Le Something" - even if their table provided case-insensitive search.
The text was updated successfully, but these errors were encountered: