[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.

[avila]

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

good to hear! Im on build 4113 (On Pop-OSPop!_OS 20.04 LTS x86_64; Gnome). Looking forward to 4116 hitting the stable channel.

[BenjaminSchaaf]

Going to close as this should be fixed for build 4116.

[naclomi]

Hitting this issue on Build 4121 + Linux Mint 20 + Cinnamon 5.0.5 + X11.

Just started happening for me a few days ago, and it happens often. I can't figure out exactly what triggers it, but feel like it's often correlated with switching desktop workspaces. None of the reproduction instructions on this thread trigger the issue, but the solution of dragging an area around the stuck caret does fix it. When it happens again I can keep the buffer open to investigate further :) .

[bdelespierre]

Having the same issue here with Build 4121 + Ubuntu 20.04.3 LTS + X11

Started after I upgraded to ST4. Closing and reopening the file fixes the issue but I lose my cursor position and history. I also had a bunch of issues with old themes (Ayu + Monokai pro), I will try reinstalling them.

[mattmitchell22]

Ubuntu 20.04.9 - Build 4113, Having the same issues.

[BenjaminSchaaf]

Going to reopen this. Note @mattmitchell22 build 4113 doesn't have this issue fixed, you should update.

[amine-err]

I experience this bug too, the only solution is to close the file and reopen it the cursor stays stuck on one line and it moves when scrolling the page but won't change by clicking with mouse or using arrows. ST4 build 4143, Arch linux, Kde plasma

[evdcush]

• ST 4143
• 5.15.0-58-generic 20.04.1-Ubuntu

Same issue.

[hugmanrique]

Just hit this issue on ST4 build 4143 with KDE Plasma 5.27.2 under Wayland. The cursor recovered after dragging any selected piece of text, but would quickly freeze after cutting some other text. Restarting Sublime fixed the issue and I cannot get it to reproduce again [edit: I can reproduce using stsaz's steps below].

[stsaz]

Steps to reproduce (100% reproducable with ST#4126 on Linux/Wayland):

• Unpack ST#4126 for Linux from the official tar archive.
• Exec ST. It starts up with a new empty document.
• Type asdf
• Select asdf with the mouse
• Drag-n-drop the selected area onto itself
• Press Ctrl+C twice
• Observe that the text cursor disappears

Adding this setting into Preferences:

"drag_text": false,

fixes the issue for me (because now I'm unable to drag-n-drop text with the mouse, obviously).

I'm willing to help you to test and debug the issue, if necessary.

P.S. I'd suggest you to set "drag_text": false by default so that new users won't experience this issue until it's properly fixed (but that's just a suggestion).

[DDR0]

I'm getting this issue too., on build 4143 on Wayland. I've got "focus follows mouse" on, and to trigger the issue I just need to mouse over any other window and back to Sublime.

However, this behaviour itself is very intermittent. Mostly it works fine.

stsaz's fix doesn't affect me, I guess, because I'm triggering the issue another way.

[gnat]

vanilla Ubuntu 22.04 on X11. Version 4155 of Sublime.

Getting the bug intermittently. I always have "drag_text": false so that has never has been the cause for me.

stsaz's fix doesn't affect me, I guess, because I'm triggering the issue another way.

Same

[BenjaminSchaaf]

When this is happening what's the result of entering view.is_in_edit() into the console (View > Show Console)?

[tomashejatko]

I encounter this quite often on latest Plasma + Wayland on Arch Linux. (Sublime build 4152)

When this is happening what's the result of entering view.is_in_edit() into the console (View > Show Console)?

result is False

[bf]

I have the same issue on plasma+wayland with subl 4 build 4169. Worked fine for many years on gnome/wayland.

For me issue starts when I cut text with ctrl+x and want to paste it somewhere, then the cursor is stuck.

[bf]

I think I found a workaround: Add to Preference.sublime-settings "hide_pointer_while_typing": false,

For me the issue was triggered by CTRL-A; then CTRL-X and CTRL-V. Then the cursor was stuck. Above config change fixed it for me.

[bf]

Unfortunately it reappeared again after re-enabling opengl. However, I've found a way to consistently reproduce the issue with Sublime Text Build 4169 on arch linux with wayland/plasma.

1. Open document, move cursor somewhere
2. Open "View" menu in the menu bar
3. Close the menu by pressing ESC key
4. Now the cursor/caret is stuck. You can click anywhere else and it highlights the line but the cursor it self is stuck.

Interestingly, I cannot reproduce this issue in safe mode.

My installed packages are:

"CJSX Syntax",
"Dockerfile Syntax Highlighting",
"Formatter",
"Generic Config",
"Git",
"Gitignored File Excluder",
"JavaScriptNext - ES6 Syntax",
"LaTeXTools",
"LogView",
"LSP-rust-analyzer",
"Package Control",
"Pretty YAML",
"Quick File Move",
"RawLineEdit",
"Rust Enhanced",
"RustAutoComplete",
"RustAutoImport",
"Syntax Highlighting for Sass",
"Theme - Aristocat",
"Vue Syntax Highlight",

My custom settings are:

{
    "caret_style": "smooth",
    "drag_text": false,
    "hide_pointer_while_typing": false,
    "gtk_client_side_window_decorations": false,
    "always_show_minimap_viewport": true,
    "draw_minimap_border": true,
    "hardware_acceleration": "opengl",
    "inactive_sheet_dimming": false,
    "animation_enabled": false,
    "extra_file_exclude_patterns":
    [
        "*.pyc",
        "*.pyo",
        "*.exe",
        "*.dll",
        "*.obj",
        "*.o",
        "*.a",
        "*.lib",
        "*.so",
        "*.dylib",
        "*.ncb",
        "*.sdf",
        "*.suo",
        "*.pdb",
        "*.idb",
        ".DS_Store",
        "*.class",
        "*.psd",
        "*.db",
        "*.sublime-workspace"
    ],
    "extra_folder_exclude_patterns":
    [
        ".svn",
        ".git",
        ".hg",
        "CVS",
        "node_modules",
        ".nuxt"
    ],
    "file_exclude_patterns":
    [
        "*.pyc",
        "*.pyo",
        "*.exe",
        "*.dll",
        "*.obj",
        "*.o",
        "*.a",
        "*.lib",
        "*.so",
        "*.dylib",
        "*.ncb",
        "*.sdf",
        "*.suo",
        "*.pdb",
        "*.idb",
        ".DS_Store",
        "*.class",
        "*.psd",
        "*.db",
        "*.sublime-workspace",
    ],
    "folder_exclude_patterns":
    [
    ],
    "font_size": 12,
    "ignored_packages":
    [
        "Rust",
        "Vintage",
    ],
    "word_wrap": true,
    "theme": "Default Dark.sublime-theme",
    "update_check": false,
    "index_files": true,
    "color_scheme": "Mariana.sublime-color-scheme",
}

[themilkman]

FWIW, after "ages" it just appeared again on Kubuntu 23.10 (so KDE), wayland, with HWA enabled. Build 4168. I kinda had the feeling that its an DE (or wayland, whatever) problem as I also noticed problems on copying texts in Firefox. But not I I am not 100% sure in retrospect..

Edit: Yeah, there's definitively something wrong on a higher level. I now have it constantly in ST but the DE generally does behave strange. I am sure a reboot will resolve it here. Interestingly Firefox & KRunner seem affected, Chromium not. Or maybe all coincidences..

[bf]

Yes, I've had various issues with ST4 in recent weeks as well. It was both on GTK/Wayland and QT5/Wayland and QT6/Wayland (Plasma6). I'm not super happy that sublimetext has so many small quirks in terms of window decoration which ultimately affect cusor rendering.

I'm paying for the ST4 license and was close to switching editors. Now I'm back on GTK/Wayland but there should maybe a QT version of ST4 and a GTK version of ST4. Or maybe a wrapper?

I have done so many modifications for my ST4 that I'm kinda ready to switch to a new editor with sane defaults and a good integration into the current Gnome/Plasma dark themes.

[gnat]

For people struggling: Drag some text + undo. This will fix it; but yes it's mildly aggravating.

I'm kinda ready to switch to a new editor

I keep coming back because it's fast on non-trivial length files- But I do admit, Sublime REALLY needs to catch up on:

• move files with mouse in folder view
• drag window to create dual-pane view
• auto-focus on existing open tab if you already have a file open.
• maybe a generated UI for settings (this would help me onboard more new devs without them complaining!)

Sublime has great bones, plugin development is the best out of all editors. But it really needs a UX pass.