Sublime Forum

Keyboard gets stuck [RESOLVED]

#1

I’ve added quite a bit of API-based modifications to my ST environment recently, including some listener functionality. Some of my changes produces a funny artefact (I have difficulties tracing it, as it occurs rather rarely, once in a few days).

Let me list some symptoms.

  1. The keyboard becomes “typing disabled”: I can use it to invoke (apparently, all) modifier-key-accompanied keyboard shortcut, but regular “typing attempts” are just ignored. This occurs both in the text- editing area and in the buffer.
  2. Even while ST is stuck in that state, other applications are not affected. Other windows of ST, I think, are (I may have to double-check this next time).
  3. I tried the “usual suspects”: pressing the modifier keys (both single and combinations); physical disconnecting, then reconnecting the external keyboard – each of these things can help sometimes, but not always.
  4. Usually after a minute of two of playing with random keys everything returns to normal.
  5. Something that might give a good hint: when pushing random keys leads to eventual restoration, the first typed character is some unusual symbol: usually a latin letter with some exotic accent (I can post some examples when this happens again).

This might be related to undo/redo – either to the “native” operations themselves or to the API activity of my command listeners (some of them react to undo/redo commands only).

It feels more feasible to try and recognise the keyboard symptoms (rather then to start some fuzzy debugging of this hard-to-reproduce behaviour).

Any thought would be appreciated! :slight_smile:

0 Likes

#2

I just installed Sublime fresh on an Alma 8.10 box (sublime-text-4180-1.x86_64). I was using the previous version of Sublime on CentOS 7.

I have the same issue as @qwe - when Sublime opens I can’t type anything into the main editor window. I can use any of the menu options just fine, can paste into the editor window (ctrl-V or middle-button), but when I type text nothing appears. I also cannot type into things like the find box, the “goto anything” box, etc.

I tried moving “.config/sublime-text-3” aside – that did not fix the issue.

This is extremely frustrating - to pay for the upgrade, install the upgrade, and now effectively not be able to use sublime at all.

0 Likes

#3

Thank you for the response!

Well, time-wise for me the appearance of this issue closely coincided with the installation of version 4180 – so, there is a chance that my recent API interference isn’t the one to blame. You see, I did play with the undo/redo behaviour, while the appearance of that keyboard “temporary lock” seems to be positively correlated with undoing while editing. Maybe that wasn’t me, after all?

0 Likes

#4

Does it happen in safe mode?

0 Likes

#5

I tried installing older releases (back to 4113) on Alma 8.10, and running in sublime “safe mode” on 4180 – same problem.

I can open a file (ctrl-O), move the cursor with the arrow keys, select text with the mouse, but when I type text nothing happens. No issue with any other app (PyCharm, Konsole, etc).

I’m running KDE Plasma 5, tiger vnc 1.13.1.

0 Likes

#6

I do not know, as in my case it is not deterministically reproducible.

0 Likes

#7

OK - i restarted my VNC server, now it seems to be working. No idea why this would only screw up sublime; but I guess I’m just happy it’s fixed. :slight_smile:

0 Likes

#8

This has happened again: indeed, after playing with undo/redo.
Lasted a few minutes with random key pushes: next time I should try to wait longer without touching anything, to see whether the problem cures itself.

My current hypothesis is that ST has some low-level mechanism for registering key presses (in particular, of the modifier buttons), and the tiny delays caused by my procedures (including the listeners both “on_text_command” and “on_post_text_command”) once in a while (empirically, might be close to 1% probability) interfere with that mechanism.

Is there any method to reset the the “ST-internal” status of all keyboard modifiers? As I wrote earlier, pushing the modifiers and physically reconnecting the keyboard during that hanging helps sometimes, but not always.

0 Likes

#9

Sublime Text doesn’t track the status of keyboard modifiers, that’s done by the operating system. Could you post the logs from View > Show Console?

0 Likes

#10

That’s the thing: nothing unusual there, I always do check!

Shall I run any command there to get some additional useful information next time this happens?

By the way, normal keyboard input doesn’t work there either (like in all ST windows when this is happening), but I can copy and paste from a non-ST window.

P.S.
And when the keyboard comes back alive – same thing, nothing in the console! While things are stuck, that only affects normal typing, all short-cuts seem to work as usual: including Ctrl+` for the console window.

This thing doesn’t happen too often, so frankly, it is more puzzling than annoying at this point :slight_smile:

0 Likes

#11

Can you please post the full logs?

0 Likes

#12

Do you mean the full log in the console?

I do not have any user-installed packages besides my own, the one where I put all my code, it is called “User.dgCommands”,

Upon start-up the log on the console looks like this:

UI scale: 1.302 (gtk text scale)
startup, version: 4180 linux x64 channel: stable
executable: /opt/sublime_text/sublime_text
application: /opt/sublime_text
working dir: /home/***
packages path: /home/***/.config/sublime-text/Packages
state path: /home/***/.config/sublime-text/Local
zip path: /opt/sublime_text/Packages
zip path: /home/***/.config/sublime-text/Installed Packages
ignored_packages: ["Vintage", "LaTeXTools"]
pre session restore time: 0.15175
loading dictionary Packages/Language - English/en_GB.dic
loading dictionary Packages/Language - Ukrainian/Sans Lat/Ukrainian_uk_UA.dic
startup time: 0.472468
first paint time: 0.526829
reloading plugin Default.arithmetic
reloading plugin Default.auto_indent_tag
reloading plugin Default.block
reloading plugin Default.colors
reloading plugin Default.comment
reloading plugin Default.convert_color_scheme
reloading plugin Default.convert_syntax
reloading plugin Default.copy_path
reloading plugin Default.echo
reloading plugin Default.exec
reloading plugin Default.fold
reloading plugin Default.font
reloading plugin Default.goto_line
reloading plugin Default.history_list
reloading plugin Default.html_print
reloading plugin Default.indentation
reloading plugin Default.install_package_control
reloading plugin Default.keymap
reloading plugin Default.kill_ring
reloading plugin Default.mark
reloading plugin Default.new_templates
reloading plugin Default.open_context_url
reloading plugin Default.open_in_browser
reloading plugin Default.pane
reloading plugin Default.paragraph
reloading plugin Default.paste_from_history
reloading plugin Default.profile
reloading plugin Default.quick_panel
reloading plugin Default.rename
reloading plugin Default.run_syntax_tests
reloading plugin Default.save_on_focus_lost
reloading plugin Default.scroll
reloading plugin Default.set_unsaved_view_name
reloading plugin Default.settings
reloading plugin Default.show_scope_name
reloading plugin Default.side_bar
reloading plugin Default.sort
reloading plugin Default.switch_file
reloading plugin Default.symbol
reloading plugin Default.transform
reloading plugin Default.transpose
reloading plugin Default.ui
reloading plugin CSS.css_completions
reloading plugin Diff.diff
reloading plugin HTML.encode_html_entities
reloading plugin HTML.html_completions
reloading plugin User.dgCommands
plugins loaded

And it remains like that unless I update the content of some configuration files or of “dgCommands.py”: those rare keyboard “freezes” add nothing to it.

Certainly, more in-depth help would require me to post the content of “dgCommands.py”, which I would rather not do. My hope was that someone would be able to recognise the symptoms, rather than debug my python code for me.

Thank you!

0 Likes

#13

Can you enable input logging using sublime.log_input(True); sublime.log_commands(True) in the console?

0 Likes

#14

Done, that’s already a great idea, thanks!

I’ll post updates here if anything suspicious comes up around the next time it hangs.

0 Likes

#15

Quick update: no news yet.

The keyboard locking hasn’t occurred since then: for the first few days I had the logging enabled (everything else was the same) – the logging process itself might have decreased the chances of that “locking event”; then I didn’t use ST for some time.

Now I am again using it, with essentially the same ST set-up, but on a different machine. I have not enabled logging on the new machine yet: I would do that as soon as the same behaviour is observed here for the first time.

0 Likes

#16

I have found it! :slight_smile:

Very simple, as it turns out:

  1. I have Ctrl+Shift+U bound to “soft_redo”
  2. Once in a while – apparently, when I “exhaust” the redo buffer – it works as good old “Enter Unicode”: triggering the Unicode-character expectation regime.

To leave the regime, if is enough to press, say, CAPITAL A or CAPITAL B (I guess, up to capital F, though I didn’t check; what is noticeable and made it hard to find was that lower-case letter didn’t work, neither did the numbers alone: so Shift+… really had to be pushed for some hexadecimal-encoding “…” in order to restore the input).

By the way, note that this perfectly fits all the phenomena that I described above.

bschaaf, thank you again: your input-logging idea gave me the hint: I saw

 chr evt: ෝ (0xddd)

in the console after the input was restored!

0 Likes