@deathaxe: Yep, I see that. The same is true for mine–if I use HTML syntax there is no issue. But if I’m using PHP syntax, the issue occurs.
Works fine on ST3131
What is 3131? Is that the build number? If so, how are you using that? My build number is 3126. I just checked for updates and the program said there were none.
Yes it’s the latest DEV built. I don’t know whether it is published via automatic update, if you run a version from stable branch.
I just double checked with ST3 built 3126 and it works fine, too. I can comment/uncomment your line.
The comment/uncomment feature uses certain rules defined in *.tmPreferences files which work only for a predefined set of syntax.
If you use a custom HTML syntax package it might define different scopes which are not handled by default rules and may not come with its own set of rules
In the default HTML package you’ll find a Comments.tmPreferences
<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
<key>name</key>
<string>Comments</string>
<key>scope</key>
<string>text.html</string> <!-- this is the scope the rules apply to -->
<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>
</dict>
</plist>
OK thanks for all this. But what exactly does it mean for my situation? I see that the commenting works as expected when I’m in HTML syntax. But I want to continue to work in the PHP syntax. Aside from the custom plugin suggested by @kingkeith, is there anything I can do? Could I create a macro that switches to HTML syntax, comments the line, then quickly switches back to PHP syntax?
With PHP syntax a commented out line looks like this?
The php block keeps rendered uncommented as it is a dedicated scope which is injected into HTML and thus can’t see the commented surroundings.
I didn’t work with PHP for years, so please help me: Is the PHP block still parsed and run? Or is it just a visual issue. I this case we might need to update syntax files.
As @kingkeith pointed out in my previous thread, the PHP in this case is still evaluated by the server. In my case, I would like for both the HTML and PHP to be commented out and not evaluated.
It sounds like @kingkeith gave me instructions for a suitable workaround earlier in this thread. I just need to apply the keybind properly so I can test it.
With information from your link, I agree with @kingkeith. You need an plugin to handle it as ST’s built-in commenting feature can’t handle multiple scopes at once. It can’t know whether the embedded PHP block needs separate commenting or not.
OK thanks for that. But I was trying to implement @kingkeith’s solution and ran into an issue. He suggested I create a new plugin with the code he provided, then create a keybind for it. But how exactly do I replace the existing comment keybind with this new plugin? I know that I can open Preferences–>Key Bindings, and the syntax of the existing keybind is:
{ "keys": ["ctrl+/"], "command": "toggle_comment", "args": { "block": false } },
But how do I modify that to point to my new plugin? Thanks!
OK thanks for that. I’ve made that change, but the keybind is still unresponsive. To revisit your previous instructions, where exactly should I save toggle_comment_cag8f.py? I have it saved in C:\Program Files\Sublime Text 3\Packages\User (I’m on Win 10). Unfortunately the folder suggested by Sublime text was D:\temp for some reason.
Thanks.
Go to the Preferences menu in ST -> Browse Packages, and then it should open the Sublime Text 3\Packages folder under your roaming user profile - put the file in the User subfolder there.
OK gotcha. The .py folder is indeed in that location. In ST–>Preferences–>Key Bindings I have:
{ "keys": ["ctrl+/"], "command": "toggle_comment_source_text", "args": { "block": false } }
Yet when I enter the code:
<span class="item"><?php get_the_title(); ?></span>
and switch to PHP syntax, the key bind is unresponsive. If I remove my entry in Preferences–>Key Bindings, the keybind reverts back to its default functionality. Thoughts?
Nothing that seems out of the ordinary. The console has many entries for ‘reloading plugin,’ e.g.
reloading plugin Default.side_bar
One is my custom plugin:
reloading plugin User.toggle_comment_cag8f
Thoughts? Is that an indicator of the issue?
that just indicates the plugin was reloaded without any errors. Maybe add some print('on line 5') style debug logging to the custom command, to help track down what’s happening - all I can say is that it works for me.
OK thanks very much for the help so far. It’s not terribly urgent, but I’d like to resolve this if possible.
Maybe add some print(‘on line 5’) style debug logging to the custom command, to help track down what’s
How/where exactly would I add this debugging code?
@kingkeith, care to revive this old issue we were discussing? If you recall, I was trying to add a custom plugin that you wrote, but was having issues. I finally had a chance to revisit this. I tracked down the issue. When I execute the keyboard shortcut assigned to the plugin, the console output is:
Traceback (most recent call last):
File "C:\Program Files\Sublime Text 3\sublime_plugin.py", line 812, in run_
return self.run(edit, **args)
TypeError: run() got an unexpected keyword argument 'block'
Thoughts on that? Seems to be an issue in sublime_plugin.py?
it’s telling you that the command you are trying to run doesn’t accept an argument called block, probably you will want to edit def run(self, edit): to def run(self, edit, block=True): to get it working.
And self.view.run_command('toggle_comment', { 'block': True }) to self.view.run_command('toggle_comment', { 'block': block }) to make use of the arg value
OK thanks for that. With those edits, there are now no console errors when I execute the keybind. But now, when I execute the keybind on sample code:
<span class="item"><?php echo "test"; ?></span>
the PHP portion of of the line remains uncommented (screenshots). At least, the color of the text remains as uncommented. Furthermore, the on-screen rendering of this code changes from test to // test Thoughts on that? Which of this, if any, is expected?
this plugin snippet still makes use of the built in toggle comment functionality, which doesn’t know that the line comment for PHP shouldn’t begin at the start of the line, but inside the start of the PHP block, so all of it is expected - its only really supported to use block comments here. Maybe it would be possible to improve the plugin I posted to handle this, anybody feel free to tinker and try