This issue is partially described here on SO

Under some circumstances, keyboard text entry is reversed after a backslash is entered. The steps to reproduce below describe the only occurrence of this behavior I've seen, but there may be more. I assume it's related to TS's autocomplete functionality since it occurs with backslash.

I think the problem is that in these circumstances, TS is keeping the cursor immediately to the right of the entered backslash, essentially turning on the old 'insert' mode as if you've pressed on the 'insert' key on a PC keyboard.

Please see the attached archived video demonstrating the undesired behavior, and to see how the behavior is not perfectly reproducible.

Environment

• TeXstudio: hg 2.12.8
• Qt: 5.10.0
• OS: Mac
• TeX distribution: TeXLive

Expected behavior

Text entry after a backslash should be in the order of keys pressed, so if I type 'alpha' I should see 'alpha' on the screen.

Actual behavior

The ordering of letters is reversed, so typing 'alpha' results in 'ahpla' being displayed in the editor.

How to reproduce

1. In an open TeX document in the TS editor, double click a word to select the whole word
2. Type 'alpha' and the order of the letters is reversed

there needs to be something else. I have never seen that behaviour on mac or linux.

I’m not the only one experiencing it (see linked SO page in OP). It’s very weird and annoying. Are there logs I can upload to help diagnose?

I have seen this frequently. It is very annoying indeed. But also hard to reproduce

is option/advanced editor/automatically insert LRM ... activated ?

@sunderme For me this problem sometimes occurs despite 'automatically insert LRM characteres' not being activated.

I have had 'automatically insert LRM' permanently disabled and I get it.

I got the same problem using Win 10 and MiKTeX as TeX-distribution.

I have the same issue with TeXstudio 2.12.8 on Windows 10. For me it sometimes happens when I want to insert something like textit{...} (I have a german keyboard layout).

when I want to insert something like textit{...}

For this specific case, it would be easier to use the Ctrl+i shortcut (or, even better: Ctrl+Shift+e, since emph is generally more advisable than textit).

I'm experiencing this same issue
TeXstudio 2.12.8 (hg 2.12.8-1-g68cd350)
Using Qt Version 5.8.0, compiled with Qt 5.8.0 R on Windows 10.

It was not occurring in the previous version. Although I too do not have an exact reproduction case, it does seem to occur after typing .. and then backspacing the to type normally. Restarting the application resolves the issue.

Likely something removes the auto update flag from the qeditor cursor

I have encountered this issue in the latest stable (2.12.10) and I have a way to realiably reproduce the issue, though I am not sure if there are still other ways to trigger it. I had been using a development version (2.12.9.something compiled after the patch commit) for a while and didn't encounter the issue, though I never tested the trigger explained below as I just found it.

Trigger:

1. I type a few characters (let's say 'abcdef').
2. I select 'abc' using the mouse.
3. Using the mouse, I drag-drop the selected text to the right of 'def', such that the text now reads 'defabc'.
4. Now, when I type 'ghi', I end up with 'ihg' in the same manner as described in previous posts.

If it is still unclear, I can provide a screen recording of the issue.

My system: Windows 10, 64 bit, TexStudio 2.12.10, as provided on the official website. UI set to German.

For me, the issue is independent of the flag option/advanced editor/automatically insert LRM.

I duplicated @psisquared2 's description on MacOS 10.13.5 with:

TeXstudio 2.12.10 (git 2.12.10)
Using Qt Version 5.11.1, compiled with Qt 5.11.1 R

My UI is set to English language.

I found this behavior in several version, but couldn't reproduce it. With psisquared2's method I can now.
Current version I just installed for verification:

Windows 7

TeXstudio 2.12.10 (git 2.12.10)
Using Qt Version 5.8.0, compiled with Qt 5.8.0 R

the one before was 2.12.8

Clearly what @psisquared2 mentioned is a bug. However, has anyone seen the issue manifest during normal typing (i.e., without the drag/drop) in 2.12.10? Since upgrading to 2.12.10, I have seen it while just typing. I have not used it very heavily, but I have used it a good amount.

@ZaydH :

have seen it while just typing

Do you mean that you have seen it more or less since upgrading? Since afd3df8 I have not encountered the issue during normal typing. I'd still be keen to know if the trigger I found is another standalone problem or if its fix will potentially remove other triggers we haven't found yet.

I've just encountered this issue by accidentally performing the steps described by psisquared2

I'm using windows 10 64bit, and the UI is all English.

This is not surprising, because I think 2.12.10 was released on 6 July and the fix was applied on 13 July, so it isn't part of the current stable release.

That being said, I (rarely) encountered the bug using yet another trigger, however I have no way to reproduce it right now. If I figure out a way to reproduce it, I will update this bug report.