I read this and thought why make the text smaller? Why not just collapse the right most nests? And keep collapsing until you can see what you're looking for then uncollapse? Just a different idea. I probably wouldn't use it, but it might be cool.

We should be able to define an end based on the subset of a begin rule. This would help for a better indentation languages definition (custom YAML based DSL) Class handling in python etc.

Example (indentation guides shown for illustration purposes):

1: foo() {
2: |    if (bar) {
3: |    |    for (condition) {
4: |    |    |    baz();
5: |    |    }
6: |    }
7: }

If the cursor is on line 2, the second indentation guide should be highlighted, because line 2 starts at that indentation level. This will result in very easy visual identification of the matching closing brace, regardless of the cursor position within the actual line.

When running the "subl" command on the same path it always opens a new windows containing the file rather than using the existing project already pointing to that path. It works correctly for files. For example

running "subl ." and then "subl views/somefile.html" will use the same window that "subl ." opened up.

However running "subl ." a second time will open a new window even though that project is already open. Probably a small thing, but I have run into it a few times while just evaluating sublime. I am switching from bbedit which does do this correctly.

Currently, quoted literals are treated somewhat incorrectly in regard to auto-completion. E.g. in php:

mysql_query('SELECT id FROM test WHERE id IN()');

Typing `'` within the `IN()` brackets behaves as expected. The literal string is also highlighted. However, if one has the exact same literal, spanning across several lines, things stop working:

        mysql_query('

            SELECT id 

            FROM test 

            WHERE id IN()

        ');

Highlighting no longer works. Typing `'` withing `IN()` brackets does not insert matching `'`. If one types in the second `'` manually, it is auto-completed this time around, resulting in `IN(' '')`.

Basically, this results in editing larger strings extremely inconvenient. The example query is short, but imagine it having 5 joins -- it would get extremely large, and editing it as a one-liner would be a pain.

Same goes for C multiline literals.

A better way to handle the key conflicts is to popup a list of all commands mapped to the same shortcut and let the user choose which command they want to execute (instead of ST executing one by default and ignoring the rest). Often times new packages introduce key conflicts and it's rather inconvenient for the user to have to re-map the conflicting shortkeys. It's likely that multiple operations sharing a shortkey are all useful thus necessary to be kept by resolving the key conflicts, which requires a careful remapping of these operations in order to avoid introducing further conflicts with yet other operations. IMO the key conflict resolution task should be handled by ST instead of being left up to the user.

I would like to be able to define in settings when to filter out browser files which match a source / compiled file pattern: for example, I don't want to hide all .js files from my project, but if in same directory there is a foo.coffee file, I would like to hide foo.js because it can be expected to be compiled from the other file.

Of course I can define per project 'hide .js files in folder x', but it would be easier to be able to configure 'whenever I have .coffee hide matching .js'.

If I have date.js in a directory without matching 'js source' files in same directory, the date.js should be shown: this is why current file_exclude_patterns does not work in this case.

Example how this might be configured in user settings (globally, not per project):

compiled_file_extension_exclude_patters = {

'.js': [ '.coffee' ],

'css': [ '.less', '.coffee' ]

This is very comfortable for ordering tabs.