[ST4] Cursor position on document bugs out on Linux

[jdoss]

Description

Sometimes the cursor and the position on the document bugs out on Linux.

In this image I am typing on line 22 but my cursor is flashing on line 19.

Steps to reproduce

It is pretty hard to reproduce but I noticed it happens a lot when I am copy and pasting on Linux from the primary clipboard buffer (middle click paste).

Expected behavior

A cursor that stays in the right position.

Actual behavior

An insolent and churlish cursor.

Environment

• Build: 4102
• Operating system and version: Fedora Linux 33
• [Linux] Desktop Environment and/or Window Manager: GNOME Shell 3.38.4

This also is the case on Fedora Linux 34 Beta with GNOME Shell 3.40.0.

[ISSOtm]

I also got this, but through multi-cursor; I think that this triggered it, though I wasn't paying fully attention:

• Selected the letter e with the mouse (it's an ASM register name)
• Pressed Ctrl+D to select next occurrence, which selected a e in the line's comment
• Canceled selection, though I'm unsure whether that was with the mouse or Escape
• Pressed Ctrl+D twice in quick succession to correctly select the next occurrence of the word e
• Cursor was bugged

The cursor appears to be stuck on a line relative to the top of the view, but in reality this is merely graphical, and the actual cursor can go anywhere: It also adjusts to the width of the line it appears to be on, not the line the actual cursor is on.

Spawning a new cursor does not fix the issue, and does not appear to create a second visual cursor.

Environment

• issotm@sheik-kitty ~% pacman -Q sublime-text-4-dev xorg-server i3-wm
  sublime-text-4-dev 4.4102-1
  xorg-server 1.20.10-3
  i3-wm 4.19.2-1
  

• Arch Linux, uname -rms reports Linux 5.11.13-arch1-1 x86_64

[BenjaminSchaaf]

Are you using wayland or X11?

[jdoss]

Fedora 33 defaults to Wayland. @ISSOtm seems to be running X11.

[ISSOtm]

Yes, I'm using X11. I also noted the Xorg server version I'm currently running.

[cem-okulmus]

I can confirm that this bug also sporadically occurs for me. I never used mutl-cursor when it occurred to me, and I haven't been able to find a clear trigger for it to happen. It's "fixed" when I restart Sublime, or close and open the document again. It also happens only for one document, not for all documents in the current session.

I'm using Ubuntu 20.10, running Gnome 3.38, running X11. Build: 4102.

[BenjaminSchaaf]

Does it reset when you drag some text? If it happens frequently for you does it still happen if you use the setting "drag_text": false?

[cem-okulmus]

I will check how dragging text affects things when it occurs again. Might take a while since the bug doesn't occur very often for me.

[ctheune]

I've experienced something similar on MacOS but can't currently say what triggered it. I'll try to review the things described here when it happens the next time.

[saveman71]

Am hit by this as well. It doesn't reset when dragging text.

Also the cursor is "frozen", but can move when scrolling (it stays at the same y position).

It also doesn't disappear when switching from a left pane to a right pane for example, whereas a non-bugged cursor does disappear when losing focus.

[saveman71]

I have the bugged cursor right now, and I'll try to keep it as long as possible if someone can indicate further debug steps

EDIT: I moved the tab to a new window and it's still frozen

[BenjaminSchaaf]

@saveman71 Which OS and build are you using?

[saveman71]

@BenjaminSchaaf sorry. Build is 4103, OS is arch linux, Xorg and i3.

[saveman71]

Damn, I just fixed it by selecting as you suggested earlier. Previously I was selecting an area outside the bugged cursor.

Selecting an area containing the cursor fixes it. Sorry I don't have the cursor available to debug now :sweat:

[saveman71]

The selection fix doesn't work for this instance of the bug I have now, unfortunately. I have this bug every day multiple times.

[ISSOtm]

The issue happened again on some instance while I was doing multi-cursor on a Rust program, with the Rust Enhanced extension, which uses I believe they're called "phantoms"? I noticed one of the cursors appeared in a wrong position, and the bug was in fact triggered.

[ISSOtm]

By the way, I'm keeping the bugged instance open and leaving it alone (opened a new one), so we can experiment on it. Please get in touch if you believe this can help! [EDIT] I have to reboot, sorry!

Build 4107, by the way.

[fili]

Also have this problem, ubuntu 20.04lts, xorg, using wacom tablet, dual screen setup, 4107 build

[felipemontoya]

Does it reset when you drag some text?

I was having this exact issue (build 4107, linux mint 20) everyday. It did reset when dragging text. I turned "drag_text": false, and will be watching for this to see if it happens again.

[felipemontoya]

I left "drag_text" turned off for the last 7 days and today I had the problem again. I had to turn it on again in order to fix the issue without closing the file.

[saveman71]

I left "drag_text" turned off for the last 7 days and today I had the problem again. I had to turn it on again in order to fix the issue without closing the file.

To add to that, I have "drag_text": false since a few weeks and didn't have the issue since

[gs-dbs]

Cursor freeze issue occurs on Debian Buster as well. (ST build 4107)

[themilkman]

Could just reproduce in safe-mode, 4109, kubuntu 21.04 with and w/o drag_text option set to true.

Cursor keeps it position and is not moving anymore - the line highlighter shows the correct position and I may type there.

[oleg-vinted]

"drag_text": false looked promising at first, but I could reproduce the bug even with drag_text set to false.

[hartsublime]

There's MR with a fix for the case in which "drag_text": true.

@oleg-vinted do you have any more details of the steps to reproduce the behaviour when "drag_text" is set to false?

[oleg-vinted]

Sadly, no, I don't know how to reproduce this consistently, seems quite random.

[ratijas]

Got this glitch few times lately too. Quite random, but definitely scoped to something with text selection. Can't cancel it even by switching tabs — only reopening file helps.

I think cursor gets lost and torn apart from its selection range, and later application can't associate them back together, which is why cursor visually gets stuck. I'd suggest to look for chunks of code that update one, but not the other?

Also, from what I know Linux/X11 clipboard is async (unlike Win & OS X), which is an additional pain to implement in a cross-platform way, and might be the reason some people experienced this glitch which copy/pasting or dragging text.

[hartsublime]

Latest build 4014 should contain a fix for majority of instances of this bug as result of dragging text. If anyone could submit any further reports of occurrences it would be appreciated.

[jdoss]

Thanks for the update @hartsublime! One thing I did find that fixed the glitch was highlighting a bunch of text and dragging it somewhere on the file then ctrl+z to undo the drag. It would fix it every time.

[avila]

I also encounter this issue quite regularly and I've found a dirty workaround to "fix" it that does not require restarting ST4 or reopening the current file.

Description of GIF: To get the cursor back is to make a range selection with the mouse that "covers" the location of the stuck cursor, starting from a position around (above or underneath) the stuck cursor and then selecting over the cursor so that it would "push" it to a new location. It does not work every time (in the gif it worked on the 3rd time) but it is better than closing the file and opening again.

Small note: Sometimes you can even "move" the cursor by rearranging the text around it, (as it happens in the gif) but it remains stuck, the only way I can get it back is by selecting a new range with the mouse, I tried selecting a range with the keyboard (Shift+Arrows) and it didn't work...

[hartsublime]

@avila what build are you using? There should be a fix in build 4116.