Pete Corey Writing Work Contact

Hide Menu: My First Sublime Text Plugin

Written by Pete Corey on Dec 24, 2014.

My new bspwm setup currently doesn’t have a pretty GTK theme installed, so the menu in Sublime Text looks fairly unattractive. With my workflow, whenever I open Sublime Text (subl .), the menu is always shown, regardless of if I hid it during my last session. So what’s the solution to hiding the menu at startup? Find a plugin, of course! Oh, there are no plugins that do this? Write a plugin, of course!

My current bspwm setup

Building the Plugin

Unfortunately, I’ve never written a Sublime Text plugin. Thankfully there are many resources to help out a person in my situation. This post explained how to create a new Sublime Text plugin. This one showed how to run code when Sublime Text is started. And finally, this guy gave me the command I needed to execute to toggle the menu visibility. After testing everything out, I researched how to submit the plugin to package control, and made my pull request. The final result is available via package control, on github, and the incredibly simple code is below:

import sublime
import sublime_plugin

def plugin_loaded():
    window = sublime.active_window()


Unfortunately, the plugin has its issues. As mentioned here, with some workflows, Sublime Text will remember the state of the menu’s visibility and the toggle_menu command issued by my plugin will show the menu instead of hiding it. As far as I know, there is no way to either detect if the menu is visible before issuing the toggle, or sending some kind of “set visibility” command rather than a toggle. I’ve opened an issue about this on the project’s github. If you have a solution or any feedback about it, please leave a pull request/comment.

BYO Meteor Package

Written by Pete Corey on Dec 22, 2014.

This morning I started working on a quick project called Suffixer, which is a tool to help you find interesting domain names. For this project I needed a searchable english dictionary accessible from within a Meteor app. After some sleuthing, I decided that adambom’s dictionary JSON would be my best bet. The next step was importing that JSON data into Meteor in the most “Meteor way”.

Creating a Package

Since this is a fairly reusable component, I decided to throw it into a Meteor package. Doing this is as simple and running a “create package” command inside your Meteor project:

meteor create --package pcorey:dictionary

This will create a package called pcorey:dictionary in the packages directory within your project. There you’ll find package.js and other files to get you started. Next, throw some code into the file referenced in the onUse section of package.js. Finally, add the package to your project:

meteor add pcorey:dictionary

You’ll notice that Meteor will immediately pick up this change and build your package into the project. For local packages, this is all you need to get started.

However, I wanted to keep this package in its own github repo and eventually publish it to Meteor’s package repository. With that in mind, I pulled it out of my packages folder within my project and into its own directory.

Package Assets

If you take a look at my package’s github repository, you’ll notice that I’m including dictionary.json in the package.js file:

Package.onUse(function(api) {
    api.addFiles('dictionary.json', 'server', {isAsset: true});

I’m passing an additional two arguments to this call of addFiles. The 'server' argument is straight forward; it’s telling meteor to only make this file available to the server. The {isAsset: true} argument is used to incidcate that this file should be loadable as an asset. This is a fairly undocumented feature that I only discovered after some frantic googling. Adding the file to the package in this way lets you load it as an asset in the package:

var dictionary = JSON.parse(Assets.getText('dictionary.json'));


My package defines a collection called Dictionary that I intended to be used on the client side by projects importing this package. However, without explicitly exporting Dictionary, it will remain hidden within the package’s scope.

You can specify your package’s exports in your package.js file. Here’s I’m exporting the Dictionary collection defined in dictionary.js and making it accessible to both the client and the server:

api.export('Dictionary', ['client', 'server']);

Publishing Your Package

Once you have your package completed, the next step is to publish it to Meteor’s package repository:

meteor publish --create

When making changes to you package, be sure to increment your version in package.js and then re-publish the package:

meteor publish

You can now add your package to any Meteor project using the standard meteor add command. That’s it!

Throw Back Thursday: Julia Sets with Sass

Written by Pete Corey on Dec 18, 2014.

The other day I was looking through my old GitHub repositories, and I found JuliaSass. This was my fisrt time experimenting with Sass and Haml. I had been using Less at the time, but I learned about Sass’ support of @functions and I was inspired. I decided to build a Sass script that would generate a Julia Set fractal. Haml would be used to generate a huge number of divs, and Sass would be used to calculate and set each div’s color based on the fractal’s coloring algorithm.

The resulting CSS file was over 50000 lines long and took over 1 minute to generate on my machine. Needless to say, this is a horrible idea, but I thought it was a cool expiriment.

Check it out!