HTML with templating langauge does weird things

[g33kidd]

I'm working the Meteor's Blaze syntax, which is pretty similar to Handlebars. I reproduced this by starting to type '{' in the line above an HTML element and one tab behind it. This creates some kind of weird curly bracket creation after the element. I wish it wouldn't do this, mainly because it gets kind of annoying.

Is anyone else able to reproduce this issue? I am currently running Build 3083.

Here's a small Gif of what actually happens: http://d.pr/i/1knjE

[qgates]

This has to do with Sublime's auto bracket matching, which is fairly language/syntax agnostic but can be overridden to taste.

Easiest workaround is to either set auto_match_enabled to false in your user prefs which disables all bracket and quote matching. Or, for just braces, create a user keymap entry to override the default { behaviour. Check out the default behaviour in the default keymap file - search for "Auto-pair curly brackets".

If you like Sublime's behaviour of adding } when you type {, but don't want the block wrapping (where the } appears after the tag - which makes no sense in HTML), you could just override the "wrap_block" section to do nothing - that's the culprit for your issue. Make these overrides in your user keymap, by just copying from the default and modifying to taste.

Also, you could also make the brace behaviour match your needs better. Eg. adding spaces in between {{ | }}, where | is the cursor after typing {{, or making the trigger for all this a double {{.

Finally you can make these overrides syntax specific as well. These posts should get you started:
https://www.sublimetext.com/forum/viewtopic.php?f=6&t=6867
http://stackoverflow.com/questions/17002359/sublime-text-2-key-binding-for-specific-language

[FichteFoll]

Good answer, @qgates.

I remember talking about improving auto-match behavior in a different issue (since the current implementation is pretty naive in some situations) but can't find it right now.

@g33kidd if you manage to improve the regular expression for the context requirements, please consider opening a new issue at https://github.com/SublimeTextIssues/DefaultPackages, which is where this issue would belong to since it's part of the "Default" package.

[qgates]

This aspect of Sublime has always felt a little "clunky" to me, since such behaviours are very specific to different languages and editing contexts, yet Sublime has global behaviours for bracket matching, positioning, indenting etc.. Another example is word break at line-wrap behaviour, which is poor for those who use Sublime for writing prose (see how a trailing bracket is left hanging at the end of the line in plain text editing, where really it should wrap with the following text).

Personally I'd like to see this sort of thing should definable and tunable per-language context, neatly contained in a set of behaviour settings.

nb. @FichteFoll I'm up for helping out a bit with maintaining the issue tracker if you'd like some extra help with this.

[FichteFoll]

@qgates, imo ST does a good "guess" in that it enables auto-match behavior for all syntaxes by default and allows you to tweak things for your syntax manually if you need or want to. Due to how key bindings work any package author could override the defaults and still respect the auto_match setting, or he could define a syntax-specific settings file where he disables said setting because it makes no sense in the language.

Edit: There could of course be a more detailed way of doing this. However, this would certainly be achievable with a plugin as well so we can experiment there first before thinking of proposing a change to the default feature set, if at all.

I added you to the org. We ususally have #614 for that, but it's kinda hard to see since issues are normally sorted by last updated or created. Since you've been lurking and commenting for a while I assume you know how the labels work.

[qgates]

Sure thing. I didn't spot #614 for exactly the reasons you said :)

[FichteFoll]

Added a short sentence regarding #614 in the two readmes. Not sure if it will be seen by anyone, but hopefully by those who are interested in it and willing to dig deep enough.