Goto Line Enter key not working

[dwlamb]

Recently, an update of my Ubuntu system included an update of Sublime Text to ver. 4 (Build 4107).

If I execute ‘Goto Line’ by menu or keyboard shortcut it is not possible to press Enter and stay on the line I navigated to. Is there a new key to have the software accept the line entered in the small window?

I’ve tried Enter on the alpha or numeric key pads, Tab and Ctrl+Enter. Without a key to accept the input, editing on the new line is not possible. All I can do is hit Escape to close the mini-dialog box but then the cursor returns to the line I was on previous to invoking ‘Goto Line’.

[OdatNurd]

Does it happen in safe mode as well? This sounds like it might be an issue with an errant key binding getting in the way of default functionality.

[dwlamb]

The issue does go away in safe mode.

I have no idea what might be doing this. I have no custom key bindings to alter ‘Goto Line’ or known functions that might alter the use of the Enter key.

Any ideas how to troubleshoot this would be appreciated.

[OdatNurd]

If you open the Sublime console you can enter sublime.log_commands() to turn on command logging, then try it and see if anything is logged. That might point to what’s stealing the key.

Apart from that, something like FindKeyConflicts might help, or you could add all of your user installed packages to ignored_packages and then slowly remove them until you find the one that’s doing it.

Someone else reported something similar and it was a package that did it, although I don’t think they said which one it was.

[dwlamb]

In safe mode with sublime.log_commands() active, the commands log like so:

command: show_overlay {"overlay": "goto", "text": ":"}
command: select

In regular mode with logging active, the commands log as so:

command: show_overlay {"overlay": "goto", "text": ":"}
command: insert {"characters": "\n"}

FindKeyConflicts did not present anything discernible to show what might be inserting “\n” instead of “select”.

I have also noticed since this update (see original post at the top), the plug-in Origami for the function of creating a pane with a file does not work as it should. The pane opens - left, right, above or below - but it does not take the file to the new pane. I have to drag the tab.

Is there a way to revert to a previous build? This build is clearly breaking functionality I have had for a while and am in the middle of a couple of projects that I don’t have time to troubleshoot and fix this “upgrade”.

[OdatNurd]

The fact that it works in safe mode is an indication that there’s an explicit key binding in one of the packages that you’ve installed (or in your User key bindings) on the enter key that’s explicitly executing the insert command. As such, that’s not a break in functionality per se.

You can manually download the previous version from here: https://www.sublimetext.com/3

[dwlamb]

I could not find a way to download a previous version of Sublime Text 4. So I had no choice but to go through the steps of a new user profile. There is something fundamentally different with Build 4107.

On a fresh profile with only Package Manager and Origami installed, Origami’s function of ‘Creating a Pane with File’ (below, above, to the left or right) would only open the new pane. There was no difference in the logging of commands output between the old and new profiles.

After reinstalling all the packages from the old profile, I could not replicate the challenge of “Goto line…” not accepting enter. To do the package reinstall I worked from a list of the packages installed on the old profile and installed them anew on the new profile. Lastly, I copied the user keyboard shortcuts file from the old profile to the new profile. Nothing in the keyboard shortcuts created a problem for “Goto line…” not accepting enter.

The only factor that I can find to account for this problem was the upgrade to Build 4107. Prior to that, no packages had been installed for about 7-10 days prior. I don’t even remember the last time I needed to modify a keyboard shortcut.

For reasons unknown, a change to Sublime itself can break how packages interact with the software.

[OdatNurd]

Other people having this problem took the (ill-advised) step in the past of using a package like PackageResourceViewer to manually edit the default key bindings in place instead of just adding the appropriate bindings to the User package.

The result of that is that it locks the default key bindings into whatever they were in that version, blocking any Sublime update from being able to provide updated changes to the key bindings at all (such as if there is a significant update that changes what keys are bound to). In such a case, Sublime is entirely acting as expected in that it’s honouring overrides that the user specifically put in place.

You can tell if that happened to you by using Preferences > Browse Packages and seeing if you have a folder named Default with a sublime-keymap file in it. If so, deleting that will allow the default bindings to reassert themselves properly.

Running in Safe Mode effectively does that temporarily, and using a completely fresh configuration directory does as well, which is why either of those actions resolve the issue.

[fredcallaway]

I was able to resolve the enter key issue by adding the following to my user key binding file

    { "keys": ["enter"], "command": "select", "context":
        [
            { "key": "overlay_visible", "operator": "equal", "operand": true }
        ]
    },

It is quite unfortunate that sublime is not able to tell you where key bindings are set (as e.g. Atom can).

[rkreutzlandry]

I ran into the same issue. It worked in safe mode, didn’t work when I disabled all the user installed packages by setting ignored_packages, and worked with the hack from fredcallaway above. I ended up comparing the default keybinding file from my machine to a coworker who also had the latest version and mine was two hundred lines shorter.

I was able to paste in the contents of their default OSX key bindings file into mine and it now works without the hack. I’m assuming something somewhere borked the actual default file in such a way that upgrading wasn’t modifying the default file properly.

[OdatNurd]

I don’t know that I would classify setting key bindings by putting what you want in your User key bindings to ensure that they take effect as a “hack”.

I was able to paste in the contents of their default OSX key bindings file into mine and it now works without the hack.

This sounds very much like your default key bindings file is overriden as outlined in my post above.

I’m assuming something somewhere borked the actual default file in such a way that upgrading wasn’t modifying the default file properly.

If you have an override, then this is actually working as intended in as much as creating a folder named Default in the Packages folder and putting a key binding file in it specially tells Sublime “No matter what, for the rest of all time only use this file and ignore the one you ship with”.

In such a case, it’s doing exactly what you said. It’s entirely likely that this happened through not fault of yours because the internet is full of advice on how to achieve various things in Sublime that tell you the “How” without telling you the “Why” or the ramifications of doing so.

For example, the package PackageResourceViewer has historically been used to tweak key bindings and other package files at their source, and it’s extremely easy for that to happen without your realizing it, including overriding a whole package or every package.

With the disclaimer that I’m the author, the OverrideAudit package was created precisely to make sure that this sort of thing doesn’t happen without you realizing it.