I would love to see support for multiple projects in a single window.

Personally I find the one-project-per-window approach difficult to use. Especially when I am working on two related projects, having access to multiple projects' files in one consolidated list would be very helpful.

How I imagine this working is splitting the sidebar up into collapsible top-level project groups:

Foo Project 1
    OPEN FILES
        (Foo Project 1's open files list)
    FOLDERS
        (Foo Project 1's folders)

Foo Project 2
    OPEN FILES
        (Foo Project 2's open files list)
    FOLDERS
        (Foo Project 2's folders)
etc.

Clicking on an open file or folder would switch the tabs shown in the current window to the corresponding project's open tabs.

With drag and drop support in the sidebar it would be easy to move open tabs and files between projects. 

This method could also help with ST2's problem of adding random unrelated/one-off files to the project that happens to be open/focused. By optionally having a 'Loose Files' project in the sidebar, opened files that are outside of any open project's folder scope could be automatically (or manually) put there without opening another ST2 window.

Allowing both multiple windows and multiple projects per window (and remembering these between sessions) could work well for certain styles of workflow as well. Some 'search in all this window's projects' function akin to (or replacing) Ctrl+P would also be dandy.

Comment-only lines should be ignored when guessing the indentation of a buffer.

The problem applies to JSDoc comments; with a buffer looking like this:

/**
  * @class
  * Class description.
  * Next line
  * Next line
  * Next line
  * @constructor
  */
var SomeClass = function() {
    this.foo = 1;
    this.bar = 2;
}
/**
  * @class
  * Class description.
  * Next line
  * Next line
  * Next line
  * @constructor
  */
var SomeClass2 = function() {
    this.foo = 1;
    this.bar = 2;
}
 

... Sublime Text 2 guesses an indentation width of 2. However, the code actually has an indentation width of 4, but ST2 is taking the apparent indentation of the comment blocks into account.

Let us embed simple Python expressions in the ST2 search-and-replace "replace with" box that would let us perform transformations on captured text groups when using regular expression matching. 

A syntax looking something like this might work well:

Search regex: (\w+)

Replace with: ${$1.upper()}

In this example ST2 would recognize a special pattern of 

${PYTHON_FUNCTION}

and implicitly give $n the string value of the corresponding capture group within the function.

This approach could open up some very interesting possibilities for doing regex substitution ...

${ int($1) + 1 }

${ max($1, $2) }

${ import re; re.sub('foo', 'bar', $1) if 'foo' in $1 else 'cheezburger' }

... ad inf.

It would be useful in authoring and maintaining color scheme files to be able to reference the color choices of another entity in the same color scheme. This would simplify changing a given color or conceptual "color group".

Something like this:

<dict>

    <key>name</key>

    <string>Class name</string>

    <key>scope</key>

    <string>entity.name.class</string>

    <key>settings</key>

    <dict>

        <key>foreground</key>

        <string>#A6E22E</string>

    </dict>

</dict>

<dict>

    <key>name</key>

    <string>Inherited class</string>

    <key>scope</key>

    <string>entity.other.inherited-class</string>

    <key>settings</key>

    <dict>

        <key>foreground</key>

        <string>entity.name.class</string>

    </dict>

</dict>

In this example, entity.other.inherited-class would use the referenced foreground color defined by entity.name.class.

Since ST2 color scheme files can contain named scopes which don't actually exist in any document, it would be possible to create scopes which are just used internally in the color scheme file to define a shared color, e.g. "colors.brightBlue".

A few settings to globally adjust the brightness and saturation of the current color scheme (any scheme) would be useful. 

This would allow users to "tune" any color scheme to their tastes without tediously editing RGB color values in the scheme files. Many color themes may have a very pleasing palette, but just be too bright or too washed-out for one's tastes.

I'm thinking something like:

"background_brightness_multiplier": 1.0,"background_saturation_multiplier": 1.0,"foreground_brightness_multiplier": 1.0,"foreground_saturation_multiplier": 1.0

Currently auto completes can be committed by pressing Enter and/or Tab, depending on the "auto_complete_commit_on_tab" setting. Expand this by adding a "auto_complete_commit_trigger_characters" setting which allows the user to specify which characters act as auto complete commit triggers. 

For instance if working with Python I might like to set it as:

"auto_complete_commit_trigger_characters": [".", " ", "Tab"]

.. and use Esc when I want to cancel auto complete. 

A similar option is found in Eclipse, where it gives the user a nice, fine-grained control over how "aggressive" the auto complete behavior is. In particular, allowing non-alphanumeric characters such as ".", ">", and " " to trigger auto complete commit can noticeably increase coding efficiency in some circumstances.

Hot exit is one of my favorite new features in Sublime Text 2. I'd like to see an option to make hot-exit the default behavior for Sublime when Sublime is exited, either via the titlebar "X" or Alt+F4.

The latter can already be done by editing one's .sublime-keymap file, but there doesn't seem to be a way to change to hot-exit behavior for regular application closing.

Allow the user to persistently change the font size independently for each pane in the UI. For example, the user should be able to use a smaller font size for the console pane than their main text buffer.

Long menus such as View->Syntax are a pain to use in Windows. They are not scroll-wheel aware, leaving repeatedly clicking of the "down" arrow as the only way to scroll the list.

Two ideas:

* Hook the mouse scroll wheel when over these menus.

* Break long menus into a series of menu panes stacked horizontally next to each other. This can be seen in some other Windows applications, e.g. XP's Start->Programs menu.

Support nested syntax highlighting.

Sublime Text 2 understands syntax in a manner that should make nested syntax highlighting possible.

Within a certain syntax scope, e.g. string.quoted.double.java, support the creation of rules by the user which will cause a syntax-mode switch for the contents of that text's scope.

For example, we might create a rule: when in string.quoted.double.java, if the contained text matches /^SELECT/, apply .SQL syntax highlighting to that text instead.

A set of reasonable default rules could be assembled, e.g. for detecting stringified HTML and SQL in many languages, for Javascript within HTML <script> tags, etc. Allow toggling of these rules with a new View menu item "Nested syntax highlighting".

This could also be used to support per-file syntax highlighting in the find-in-all-files result buffer.

Some additional rule/configuration may be required to handle comprehension of string concatenation which varies by language, e.g. "some" + "thing" and multiline concatenations. Sublime would need to apply a nexted syntax-mode to all the parts of such a string whenever the (whole) string matches a rule.

The rules' criteria should support arbitrary python for cases which don't match a regex well; that code should be able to examine the parent scopes' text to make its assessment (e.g. examining a string variable's declared name in one's code to determine the string's syntax).
 
In a given file the user should be able to arbitrarily change the syntax-mode of any individual syntax-scope in any buffer, through the right click context menu or other method.