Is there a way to configure Sublime Text 4 so that the Go To Definition context menu item works for imports/requires?
I'm not having any issues with the go to definition for things defined myself, but when trying to view the imported module type definitions. Looking for behavior similar to VSCode's with this, or at least alternative but similar end result behavior.
This is on a clean install of ST4, node_modules is not in any exclude path in the settings.
Had to set the "index_exclude_gitignore": false to get ST4 to index the node_modules folder to get this behavior working.
Related
The normal mac behavior for command+shift+? is to open the help menu search, which is super convenient to do menu commands without a mouse.
Unfortunately a sublime text package I have installed has mapped that key binding to the settings menu. Here's the relevant section of the package Default (OSX).sublime-keymap file
[
{ "keys": ["super+shift+/"], "command": "open_settings" }
]
Based on Related to How to unbind a key binding in Sublime Text 2?
I went ahead and overrode their keybinding in my user keybinding. Here's my user Default (OSX).sublime-keymap file.
[
{ "keys": ["super+shift+/"], "command": "noop" }
]
This stops the package from open settings when I press the key sequence. Same behavior if I use unbound for the command, excluding the command files package keybinding. However, it doesn't bubble up to the Mac layer which opens the help search menu.
I can get things to work the way I want to by modifying the package's key binding file directly, but that's going to get overwritten the next time the package upgrades.
Is there a supported way to remove a keybinding without stopping it from bubble up to the operating system?
The only way to completely remove a key binding in a way that Sublime won't react in any way is to remove it from the sublime-keymap file. This is true whether you want to fully remove a file from the Default/Default (PLATFORM).sublime-keymap (there is one for each platform) that ships with Sublime to remove a default key binding as well as any that might be added by a third party package.
As long as the key remains in a sublime-keymap anywhere, Sublime will see it and try to do something with it, even if the key is bound to a command that doesn't exist such as noop (although that is a good way to block a default key from doing anything if that's your ultimate goal).
Editing the package file
One way to solve the problem is to directly modify the packaged file itself, as you've already mentioned. In most cases that would mean unpacking the related sublime-package file (which is just a zip file), modifying the content of the file, and then repacking it.
As you've already noted, that's not a good way to go because when a package gets updated, the entire sublime-package file gets clobbered away, so your changes will also get discarded.
Overriding the package file
A safer way to do this would be to create a package override file instead. This only works if the package in question is installed as a sublime-package file, which covers all of the packages that ship with Sublime as well as most third party packages.
To do this, you would create a folder in the same name of the package in the Sublime Packages folder, which you can get at via the Preferences menu item Browse Packages.... Once that's done, extract just the file you want to override and place it into that folder, and edit it as desired.
When Sublime loads packages from a sublime-package file, as it loads each file it checks to see if any similarly named "unpacked" files exist in the Packages/PackageName/ folder. If such a file exists, the version inside of the sublime-package file is ignored and the unpacked file is used instead.
This means that even if the package gets updated, since your unpacked version is still there, it will still be used and so your change will remain in place.
The easiest way to create such a file is to use the PackageResourceViewer package. You can use it's PackageResourceViewer: Open Resource command from the command palette to find and open the offending file. If you make changes to the file and save it, PRV will automatically create the override for you.
There are a couple of caveats to this process:
If the package in question is installed already unpacked in the Packages folder, you can't create an override. In this case there's not a lot you can do other than vigilantly re-modify the file when it updates.
Most packages won't fall under this restriction because few actually need to be installed that way (only packages that contain files that need to be exposed outside of Sublime need to be installed this way).
Note also that Sublime Text 2 only installs packages as unpacked, so in that particular case you also can't do this.
When a package override exists, it's always used in place of a packed file of the same name, no matter what. This has the unfortunate side effect that if the package update actually modifies the file that you're updating in any way, those changes are masked from you without warning.
Will the full caveat/disclosure that I'm the one that wrote the package, the OverrideAudit package for Sublime can warn you when this happens by checking every time a package gets updated to see if the version of the packaged file is newer than your overridden version so that you know this is happening and can take appropriate action.
Sublime Text 2 notes
Your question is tagging Sublime Text 2 and Sublime Text 3. In the case of Sublime Text 2, the information above about needing to remove a key binding completely in order to allow the OS to see it still holds.
However as far as I'm aware Sublime Text 2 doesn't support the idea of package overrides because it always installs all packages unpacked. As such the only solution in that particular case is to modify the packaged file and keep an eye out for changes.
At this point with Sublime Text 3 officially released there are not many compelling reasons to keep using ST2. If you purchased your license for ST2 sometime mid/late 2013 or later your license should be valid for ST3.
This is particularly important in that ST2 is no longer supported and as of High Sierra when Apple removed Python 2.6, various Sublime packages will now no longer work.
When you save a project, Sublime Text will create a .sublime-workspace file. In this file, there is an array of buffers, and for each buffer there is a color_scheme property. This is set to whatever color scheme was chosen when the buffers and workspace were created.
I recently changed my theme and color scheme in my user settings file. How can I refresh all of my project's workspaces so that way it uses my new color_scheme provided in my user preference file without needed to edit each project's workspace file one-by-one?
Expanding on the answer given by Tot you can do this for all views in all windows that are open by using a nested list comprehension (remember this is Python so we can be pretty flexible):
[ v.settings().erase("color_scheme") for views in [ w.views() for w in sublime.windows() ] for v in views ]
This way you don't have to run the command in each tab individually.
The only way I found to reset tabs to user's chosen color scheme is to enter this in the console :
view.settings().erase("color_scheme")
This will reset the color scheme of the selected tab - unfortunately you'll have to do it for each tab. But it's still quicker than closing and reopening the tab.
I only have this issue with Sublime Text 3 on Mac OS X.
Source : https://www.sublimetext.com/forum/viewtopic.php?f=3&t=19310
P.S. : If you've just updated your color scheme file, you'll sometimes have to execute this command twice. Just type the up arrow in the console to write the last command again.
Windows 10 AppData-related Solution
Please make sure that you are in a similar situation as me before trying this solution (see below). Steps:
Note the language and package that the Error loading colour scheme reports (my case was: markdown and MarkdownEditing).
Go to your AppData directory (type %AppData% in file explorer address bar).
Open directory Sublime Text 3, or whatever your version is.
Open the .sublime-settings file that matches the language from step 1.
Remove any lines that refer to the package you noted from step 1.
Remember that this file should be a properly formatted JSON file when you remove lines manually. Save this file and restart Sublime Text.
Background
I've decided to post here in case some of the python script solutions didn't work for you and your situation is similar to mine. I'm using GitHub to sync my Sublime Text AppData (Windows 10), in order to keep my workflow settings the same on multiple machines. Recently, I noticed that when I uninstalled a certain package on one of my machines, I accidentally merged some configuration files for that non-existent package on my other machine. This resulted in a persistent Error loading colour scheme, in particular for me when changing syntax to markdown (the package was MarkdownEditing for reference).
In XCode 4.0.2 there is a good way to configure the program in Build Settings when you click in "Levels" format. Like this screen
The levels are in this way:
Target Settings
Project Settings
iOS Default Settings
So the XCode see if the Target have a config, if not see in project and if not use the iOS default.
The problem here is that when you set a config in a low level and than delete it, it's impossible use the config of a upper level.
Like in image. I set all targets to use Google in Current Project Version, but in this target I want it use stackOverflow and it work. But in the other Generated Versioning ... I first config with stackOverflow but change my mind and want to use the Project Settings. Now is impossible delete the Target Settings and I will have to enter it manually.
How can I delete the target setting to use the project setting?
In xcode 5 it worked right simple for me. I had the same situation as in the picture in the question. Some data in the project setting and an empty but green setting on target level.
You have to select the line e.g. with the mouse that is marked and afterwards press the delete button the green marking is gone from the target level. In my test it and it will never delete the setting on the highes level, so there is no risk.
Click the Combined button and change the build setting value. Now when you click the Levels button, you will see the target and project both have the new value for the build setting.
I just figured this out. It's a little sketchy, but it works, and does not feel dangerous to me (particularly if you're using version control).
In Xcode, delete the text from the target-level configuration. Make sure you still have it defined at the project level.
Look at a diff of the YourProjectName.xcodeproj/project.pbxproj so you can figure out the code-level name of the setting you just changed. For example, in Xcode, I deleted the text from my target-level configuration for "Other C Flags". My diff showed the OTHER_CFLAGS setting changing from OTHER_CFLAGS="mytargetlevelsetting" to OTHER_CFLAGS="". If you're using version control (which you should be), it'll be easy to get this diff.
Quit Xcode.
Open up YourProjectName.xcodeproj/project.pbxproj in a text editor. Find all the lines starting with the setting name you found in step 2. Delete all the ones where the value is an empty string, and keep all the rest. For example, I deleted all the lines that said OTHER_CFLAGS="", but kept all the lines that said OTHER_CFLAGS="settingiwanttokeep". If you don't see any where the value is an empty string, or all their values are empty strings, you probably didn't follow step 1.
When you reopen Xcode and look at your target's build settings again, the setting in question should be using the project-level configuration, not the target.
My desired setup is a main project, which depends on a subproject (which generates a static library). Adding the subproject to Xcode works fine, but as you'd expect you have to set the User Header Search path to include the subproject's folder, unless you want to add the subproject's files to the main project explicitly, which sort of defeats the purpose of the subproject.
From what I can tell, setting the User Header Search path will break code sense and "jump to definition" navigation in the main project, next time your open the project.
Here's a sample, super simple, stock project that illustrates the problem:
http://dl.dropbox.com/u/579169/MainProject.zip
If you go to the Application Delegate and try to jump to definition on a property reference, say self.window, Xcode simply gives you a list of all the "window" properties it knows about. Likewise, autocomplete fails to work.
If you delete the user header search path, close the project and reopen it, code sense works as expected.
I've filed a bug with Apple, but was wondering if anyone has run into this specific problem, or has a reasonable workaround. Deleting the project "derived" build folder to trigger a reindex doesn't work reliably.
A work around is to make the headers public in the static library. Then add the following to user header search paths
"${BUILT_PRODUCTS_DIR}/usr/local/include/"
I reported this to Apple, and they report that it was fixed 6/6/2011 in XCode 4.1 (which is Lion only). I have not confirmed the fix as I have not upgraded my development machine to Lion beta.
I'm really really tired of other users having project errors because XCode's default class reference type is "relative to XCode folder." I know you can change it to "Relative to Enclosing Group," which is what our project is, but anytime someone creates a new classfile and forgets to change the reference type afterwards (frequently) or adds and file and forgets to change the reference type (also frequently), users who update from SVN see red file errors, even though it exists in the correct folder - just because the xcodeproj file links to it stupidly.
Is there any way to change the default? I've been looking through the preferences and can't find anything. It seems there must be ways to make XCode work better for situations other than single-user projects. I am incredibly unimpressed with its source control management, and I'm hoping maybe that's because I haven't been able to find some options. Thanks for the help.
My approach to this is to map my groups to the source file hierarchy and make sure that everything is initially set up as "Relative to Enclosing Group". In this case Xcode seems to do the right thing when you add more files or folders to the hierarchy, i.e. it maintains the "Relative to Enclosing Group" setting wherever it can.
For more info try asking on the xcode-users mailing list.
I struggled with this some time as well, yet the answer is simple:
Don't store your projects in the developer folder. Inside the developer folder everything defaults to relative to XCode Folder, while outside it's to enclosing group.
Hope it helps