Sublime Forum

Key Binding for Comment Defaults to Unbuffered Type for Pug Language

#1

I’m using the Pug plugin with Sublime Text 3, and I’ve noticed that the default “comment” key binding leads to the insertion of an unbuffered comment //- (that is, one that does not show up in the output).

How can I make it so that for the default “comment” key binding, the buffered type of comment // is inserted instead?

I want the default “comment” key binding to lead to this type of comment insertion.

So,

// I am a comment that will be parsed to output
body
  h1 This is a title
  p This is a paragraph

… instead of this type of comment insertion

//- I am a comment that will *not* be parsed to output
body
  h1 This is a title
  p This is a paragraph
0 Likes
#2

What package are you using to provide the Pug syntax?

0 Likes
#3

This one, from David Rios.

I did look into the package on GitHub, and found this preferences plist file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>name</key>
	<string>Comments</string>
	<key>scope</key>
	<string>text.pug,source.pypug</string>
	<key>settings</key>
	<dict>
		<key>shellVariables</key>
		<array>
			<dict>
				<key>name</key>
				<string>TM_COMMENT_START</string>
				<key>value</key>
				<string>//- </string>
			</dict>
		</array>
	</dict>
	<key>uuid</key>
	<string>D2ABB2E0-EB25-11E0-9572-0800200C9A66</string>
</dict>
</plist>

I can see that <string>//- </string> line, which is the structure of the unbuffered type of comment (the kind I don’t want).

I feel like what’s happening is that the default for Pug is maybe the buffered one, and that’s mapped to the default “comment” keybinding in Sublime…

0 Likes
#4

I think by default Sublime assumes that comments are either line comments or block comments, but doesn’t otherwise directly support the idea of different line comments for different purposes.

The file that you referenced contains the meta data that the internal command uses to know what characters to use for comments, so the easiest solution would be to override it with a version that uses the other style of comment instead so that the default command will use the comment style that you want.

Failing that (or some simple macros) I think you’re looking at some custom plugin code if you want to use two different kinds of comments. The code for the standard toggle command is in Packages/Default/comment.py, where the add_comment method always uses the first defined block or line comment. A custom version of the command could take an argument that would help it select which item to use.

0 Likes
#5

So how would I create another version of this file for Sublime Text to reference? (I don’t want to mess with the one that’s in the Pug package, because if that package is updated, that version would get overridden, no?) Maybe some kind of “user” version of the same file?

0 Likes
#6

Yes, if you edit the package directly your changes will get clobbered away when the package updates, so that’s generally not a good idea.

What you can do however is create an override of that particular file. If you create a folder in the Packages folder that matches the name of a package, the contents of that folder also become part of the package. If there is a file in the folder that matches the name of a file in the sublime-package file (including relative path), Sublime will ignore the version in the installed package and use that file instead.

The easiest way to do that is to use the PackageResourceViewer package; using that if you use PackageResourceViewer: Open Resource and select the appropriate file, if you save the file the package will create the override for you.

Doing this you sort of have the above problem in reverse; with an override in place it’s always used no matter what, so even if the package author updates the package, if you’re overriding a file it will be used and you might miss changes.

My OverrideAudit package may be of help there; among other things it watches for situations where a package is updated and you have an override and will warn you so that you can take appropriate action.

0 Likes
#7

I see. But for my situation specifically, if all I’m overriding is the type of comment (buffered or unbuffered) that the default “comment” key binding uses, I’m not really overriding that much, no?

That could work. I’ll look into it.

(I think what I should also do is maybe create an Issue with the Pug package author, because I noticed that when I try to use the buffered comment, Sublime Text doesn’t “dim” it like unbuffered comments are “dimmed.” This tells me that the author may not have planned for people to use such a feature :sweat_smile:)

0 Likes
#8

Indeed in this particular case it’s not that big of a deal, but I thought I’d mention it anyway. It could conceivably be a problem if for example you made the change and then the package author added block comments to his file as well, for example (assuming such a thing exists).

I would agree that it sounds like the package in general could be improved for everyone if you make an issue, especially if these comments aren’t being scoped properly. :smiley:

1 Like