AQL-editor and bidirectional text

[TFeige]

What is the used ANNIS version?
3.4.4 (rev. b53ef2e

What browser and operating system did you use?
Xubuntu 16.04 ; Firefox 49; Chromium 53

What steps will reproduce the problem?

1. Enter a query like: "علقة" & "مضغة" & Regex bug with initial optional parentheses #1 ^3,15 import: level for dominance edges might be not set #2 (Actually it's not correct here, either.)
2. The problem is the handling of e.g quotation marks and arabic text.

What is the expected result?
Expected result would be the correct handling of mixed characters.

What happens instead?
The positioning of characters is not correct. Editing queries or entering new ones is really painful.

Please provide any additional information below. Also please add a screenshot if possible.
As a workaround, we enter the query in an editor and copy-paste it into the AQL-editor.

[thomaskrause]

Whow, the direction changes as soon as I type the first digit in .1,15 and mixes everything up. I'm not even sure if this is any consistent text direction at all. In principle we once decided that we only want to have LTR in the query editor since the query syntax is LTR and only the content of single annotations might be RTL.

My current guess is that the syntax highlighting javascript library we use does something terrible wrong.

[thomaskrause]

It's not the syntax highlighting library but the browsers itself. Any "<rtl>" .1 entered in an HTML textarea is mixed up. I will investigate how I can enforce the correct behaviour.

[thomaskrause]

@TFeige I'm still working my way through the W3C documentation about the intended behaviour of the textarea but there is a workaround that could help you:
The text direction of an textarea component is determined per line, thus if you write the annotation definitions containing RTL text as an extra line the display should work. E.g.

"<rtl>" ^1,15 "<rtl>"

would become

"<rtl>" 
^1,15 
"<rtl>"

or

"<rtl>" 
& "<rtl>"
& #1 ^1,15 #2

[TFeige]

Thank you! That makes searching indeed a bit easier.

[thomaskrause]

We implemented a fix for this behaviour that works without the newline workaround. You can test it in our Experimental ANNIS-instance:

https://korpling.org/annis3-snapshot/?id=fe834c32-5085-4e65-bf82-b9805e626453

It should work in the latest versions of Firefox and Chrome, the latter one needs at least version 59 to work correctly. Also it works better if the opening and closing quotes (" or /) are written together since a non-closed string might confuse the Bidi-algoritms when editing on the fly.
Thanks a lot to @IrinaGlushanok for the fix!