It looks like when I installed a PHP Twig syntax package it altered the default HTML comment output from <!-- … --> to {# … #}
So, I removed the package, but it still outputs the comment as Twig when I press the keyboard shortcut.
BTW, the key mapping is correct (super+alt+forward_slash), but it's returning a Twig formatted comment instead of an HTML comment.
How do I get back to <!-- … -->
???
It seems as if there is something a little hinky with either your installation of the package or it's removal, so some investigation will be needed in order to resolve the problem.
For background, the settings information for what character or characters to use for comments (either single line or block) is provided by a file of type tmPreferences (not tmLanguage as is erroneously described in the tutorial that you linked to in the comments on your question).
The name of the file and the package that it is contained in don't matter (except in that they control the order the files are loaded in), only the content of said file.
The package that you installed (PHP-Twig) includes the file Preferences/Comments.tmPreferences to set the comments to use in twig files. As seen in this commit, the file contains this subset of information that controls comments:
<key>scope</key>
<string>text.html.twig</string>
<key>settings</key>
<dict>
<key>shellVariables</key>
<array>
<dict>
<key>name</key>
<string>TM_COMMENT_START</string>
<key>value</key>
<string>{# </string>
</dict>
<dict>
<key>name</key>
<string>TM_COMMENT_END</string>
<key>value</key>
<string> #}</string>
</dict>
</array>
</dict>
This says that for the syntax scope text.html.twig, the shellVariables settings TM_COMMENT_START and TM_COMMENT_STOP are {# and #} respectively. With this in place, any time the scope at the cursor location matches text.html.twig and you trigger the comment command, these are used to wrap the commented section.
With that said, these comment characters should only apply when the scope matches text.html.twig. The scope used in regular HTML files is text.html.basic (assuming you're using the HTML package that ships with Sublime), and so it should not match and the comments should not be used there.
You can check the scope of any particular location by using Tools > Developer > Show Scope Name... from the menu or the key binding visible for it from the menu in order to verify.
If you were seeing these comments appear in regular HTML files as well, you may have set Sublime to use the twig syntax for HTML files either intentionally or accidentally, which you can check by checking the right side of the status bar which tells you the syntax that's in use.
On the other hand the problem should also have resolved itself when you removed the package, since that would have removed the tmPreferences file that's providing the comment settings.
I would perform the following checks to see if they have any effect:
Open up an HTML file and verify that the status bar says that it's a file of type HTML and not HTML (Twig) or something else. If it's something else, use View > Syntax > Open all with current syntax as from the menu to set it back to HTML and see if that fixes the problem for HTML files.
Add "PHP-Twig" to the ignored_packages setting in your preferences and see if that helps.
If the file type is wrong or adding PHP-Twig to the list of ignored packages solves the problem, then the package is still installed. If you used Package Control to install it, try removing it again and see if that has any effect (check the Sublime console for errors as well in case the removal is failing for some reason).
You could also select Preferences > Browse Packages from the menu to open the location where Sublime stores all of your unpacked packages. PHP-Twig should not install unpacked, so if you see a folder by that name delete it or move it away from that folder so Sublime can't see it.
From that Packages folder, go up one level in the file hierarchy and then go into the Installed packages folder; this is where user packages that are installed as sublime-package files (most packages fall into this category) are stored and verify that there is not a PHP-Twig.sublime-package file. As above, if you see a file by that name, move it away from that folder so Sublime can't see it and see if that helps.
Failing that the only obvious things that come to mind would be stray tmPreferences files somewhere. The most likely location for such a thing would be one of the folders in the Packages folder (the first one we checked above).
Related
I want to add a couple of items to the Edit menu in Sublime 3. In fact, I just want to copy the Find and the Replace menu items from the Find menu. Call me lazy, but I just want to use the same Alt-E menu shortcuts I've grown accustomed to across so many other programs. I don't like making the mental switch from Alt-E to Alt-I when I switch from Sublime to anything else.
Anyway, from the sublime documentation I read that I can create a file Main.sublime-menu in the Packages/Default (or Packages/User) directory. The JSON format is easy enough to follow. But the problem is that there is no such file by default. If I add one (and I did) then sumblime replaces the entire main menu, which is not the result I want.
I don't want to replace the entire menu, I just want to add two entries to the Edit menu. Ideally, I would like to copy & paste the Find and Replace entries from the Find menu. That would save me the time of figuring out the command names.
Resource files that ship with Sublime are stored in sublime-package files that exist in a special folder stored in the installation folder of Sublime (where the executable is), which keeps them safe from modification because Sublime will replace them wholesale when it updates.
You can view the content of any resource file currently known to Sublime by using the View Package File command from the command palette. It will show you a list of every resource, and you can filter the list the same as the command palette entries to drill down to find what you need:
Choosing an item from this list will open the file for you to look at. If it's coming from a sublime-package file, it will be a read-only buffer that you can't modify to remind you that you can't edit the file. Resources that come from your Packages folder directly will be editable, however (such as your User package).
The Default package is where things like the default settings, key bindings and menus are defined. So although what you see in the list depends on the packages you have installed, the item you want here is Default/Main.sublime-menu.
Note that if your intention is to just add some items, you want to put your modifications into your User package. Any items you add here will augment the existing menu; that is, you can only add items, you can't modify or remove them.
If you put the file into the Default package folder (which you may or may not have to create), the file you create will override the one that's provided inside of the sublime-package file. You would do this if you want to remove entries, change what command they execute, etc.
If you go that route, note that Sublime will use this file forever even if a future update modifies the file. In that case I would recommend the OverrideAudit package (disclaimer: I am the author of said package) as it will warn you when that happens.
If this is your intention, OverrideAudit's Create Override command will allow you to seamlessly open the file and save it to create the override, saving you the trouble of finding the right place to put the file.
I can't comment out multi line in sublime 3. Looked at this Keyboard shortcut to comment lines in Sublime Text 3 already but it is not fixing it
Sublime version is 3.2.1 build 3207 . on windows 10.
Please help me out if have any tips.
The keyboard binding for commenting is indeed Ctrl+/ (Cmd+/ on MacOS) so in the general case what you're trying should work just fine.
That said, the keys in question are bound to the toggle_comment command and that command requires language specific metadata to know what comments are supposed to look like. For example comments look and work differently in HTML than they do in C or JavaScript. Some file types (such as plain text files) aren't code and thus don't have a concept of comments at all.
If the metadata file for a file type is missing, then the toggle_comment command won't do anything because comments are assumed to not be valid, which seems to be what's happening to here.
The first thing to check would be to examine the bottom right of the window to see if Sublime agrees with you about what the file type is supposed to be. For example, newly created tabs are Plain Text files until you save the file for the first time, and comments are not allowed in Plain Text files.
If the file type doesn't say what you think it should, you can click it to open a menu and select the appropriate type for that file.
If the type of the file looks to be correct and the command still doesn't work, then the metadata file needed is not being provided in the package that is adding support for that language. In that case you should raise an issue with whoever is responsible for the package in question and get them to add the appropriate file.
Based on the comments on your question, you think you're editing JavaScript files but Sublime thinks you're editing an ActionScript file instead. The JavaScript package includes the appropriate file, but the ActionScript package does not.
So in your particular case, your best bet is to switch the file type to JavaScript and your problem should go away. If you actually want to be editing ActionScript instead, then you need to create an issue on the Default package tracker and ask for this to be added.
I installed ColorPicker and it overwrote my key-binding (ctrl+shift+c). I'd like to change the ColorPicker binding to something else, however I'm unable to locate the definition.
If looked in Preferences > Package Settings > ColorPicker, but it only has Settings-Default and Settings-User neither of which contain the key-binding. I've also checked the Default & User key-bindings, to no avail.
How can I change the key-binding for ColorPicker?
Edit: Adding image of files for #OdatNurd
The definition for key bindings in a Sublime package come from the file Default (Platform).sublime-keymap, where Platform is one of Windows, Linux or OSX. Not all packages provide a menu entry for editing key bindings, though.
You can use PackageResourceViewer to open the file and see what the key binding is set to. You can modify the key directly in that file or copy it to your custom key bindings in your User package.
The latter is generally the better way to go because overriding a package file can cause problems when the package updates in the future; if it modifies a file that you have overridden, your override masks the package file which can potentially cause problems.
Sublime takes care to ensure that the User package is loaded last, so this is good place to put settings that you want to make sure don't get hoisted out from under you by packages.
I've posted this exact same question in the ST forum plugin dev threads
https://forum.sublimetext.com/t/add-custom-markers-that-will-be-shown-in-the-goto-symbol-cmd-r-window/23772
I've been using ST for a couple of years,
I'd like some guidance in first knowing if want I want to accomplish is possible through a plugin development, and if the answer is positive, maybe some reference as to where to start looking to develop this feature.
I would like to include some kind of marker that when placed in code, it includes a new entry in the list that is displayed in the Goto Symbol (Cmd+R) window. The closest example I have now is from Xcode, where in the source code you can include a comment with the "MARK:" keyword and it will render a new section in the top header bar of the editor (which is the equivalent of the goto symbol in ST).
When working with large files this feature would be of tremendous help because it allows to organize the blocks of code based on custom criteria regarding the logical relationships around it and not just the sequence of functions that exist in the file.
The contents of the symbol list is controlled by a preferences file that tells sublime what scopes should appear in the symbol list for any given language and, optionally, what transformations should be done for display purposes (e.g. to indent the methods in a class).
Such configuration files are tmPreferences files (XML files in Plist format) within a package and which are generally named with names that start with Symbol List. For example, Packages/C++/Symbol List.tmPreferences is one of such files for use in the C++ package (which covers, C, C++ and both flavors of Objective-C). Since the files are Plist files the actual names don't matter, but this is a convention that makes such files easier to find.
There is some documentation on symbols you can read for more information.
Trivially, if you save the following XML into Packages/C++/Symbol List Pragma.tmPreferences it will add all of the #pragma MARK lines in your source files to the symbol list (current file only), replacing #pragma MARK with " ---- ":
<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
<key>name</key>
<string>Symbol List</string>
<key>scope</key>
<string>(source.c | source.c++ | source.objc | source.objc++) & (meta.preprocessor.c)</string>
<key>settings</key>
<dict>
<key>showInSymbolList</key>
<integer>1</integer>
<key>showInIndexedSymbolList</key>
<integer>0</integer>
<key>symbolTransformation</key>
<string>
s/#pragma MARK/ ---- /g;
</string>
</dict>
</dict>
</plist>
This doesn't get you all the way there; for one thing, #ifdef and #endif directives are caught with this rule. Additionally it doesn't visually indent everything that follows which IIRC XCode does. However, it's a good starting point for seeing what is going on.
If you wanted to actually do this with special single line comments and not a #pragma I believe you would need to enhance the syntax highlighting for the language(s) you're targetting to match such comments and give them a scope that you can uniquely target.
If I see on a magento page (using the Template Path Hints) that some template is using some block (which is not the default block for that template).
Is there a way to find which layout file is responsible for this layout change?
(assuming that the change IS coming from a file and not by direct manipulation of the layout by code).
Do a global search for the block type that is being used. So, if you expected the block to be catalog/product_view and it was instead whoabob/wheres_theblock, you could just search for whoabob/wheres_theblock to find which module is changing things.
Keep in mind, it may be happening in a layout XML file OR as a rewrite in a module config.xml
In your IDE search the phtml file in layout directory. may you find more, but it allows you to identify and then tries to remove the layout to see if the page still shows whether or not then it's good if it is not the right