Open a file in sublime text 2 and then rename the same file in finder. If you store the renamed file, a file with the same name is created.

Implement the "Type Control/Command + r to reveal a popup that allows for this very thing (notice the @ symbol)! Even better, the search is fuzzy as well, which is particularly helpful for huge classes." to search across files.

I do this in eclipse+pydev all of the time, I can start typing the name of a function or class and it will open the file and take me directly there, it is also fuzzy and learns which items I go to the most often.

I'd like to see perl symbols included in the default lib. I've posted my example symbols library in the forum: http://www.sublimetext.com/forum/viewtopic.php?f=4&t=1663

I have a plugin which consists of some keybindings which can be conditionally toggled on or off, all of which have a 'context' requirement and an accompanying EventListener which checks the global flag to tell whether they should be enabled or not.

I'm editing Python code, and my Python settings have "tab_size": 4. Sublime Text doesn't always listen to this, and I think it has to do with the size of the first indentation in the file.

For example, if I have an import list wrapped onto multiple lines, with 20 spaces at the start of the next line to line up with "from module import (", it seems that Sublime Text takes this as an indication that I didn't really want 4-space indents, and it uses 8-space indents instead. Even though the rest of the file uses 4-space indents and now I can't get to half of the tab stops.

At least it doesn't use 20-space indents, but inappropriate 8-space indents are still frustrating.

See http://eerolanguage.org/, eero is essentially a much better wrapper for Objective-C. It would be really nice if Sublime would support editing in it's syntax. :)

By default, the minimap takes up a fair bit of space. In a typical file, most lines will not take up the full width, and the minimap won't fill up the full window height. So the minimap could be moved over the text area producing only a small amount of overlap between actual content. In this situation, it would be interesting to see how things work if the minimap is behind the text, rather than in front. Then, the text would still be readable, and the minimap would still be useable, and no screen real estate would be wasted. I don't know if this is would work well in practice, but might be worth investigating.

Bug report: