Sublime Forum

Dev Build 2101

#1

Dev Build 2101 is out now, with an improved status bar.

Apart from the status bar, the most noticeable change is that closing the current file via a key binding will select the previous file (in the mostly recently used stack), instead of the neighboring file. This was always the intended behavior, there was just a typo preventing it from triggering previously. One of the more debatable elements is that the behavior is different when closing via the mouse: here the neighboring file will be selected. I can’t remember the justification for this, as the code was added a long time ago, but it may well be changed in a future build.

The OS X key bindings for Add Next Line / Add Previous Line have been changed due to a clash with inbuilt Lion key bindings.

On the theming side of things, there’s now a status_button class available to customise the appearance of the clickable areas on the status bar.

0 Likes

#2

[quote=“jps”]closing the current file via a key binding will select the previous file (in the mostly recently used stack), instead of the neighboring file
This is excellent. :smile: I’m also a big fan of the indentation in the status bar. Thanks![/quote]

0 Likes

#3

Thank you for this quick release and fixing the indentation issue.

0 Likes

#4

Quick question, I’m trying to fix the c + w in vintage mode not clearing the entire word because it stops at _ is Packages/Default/delete_word.py the file that handles that?

0 Likes

#5

The w motion in Vintage is implemented with this command, in Vintage/Default.sublime-keymap:

	{ "keys": "w"], "command": "set_motion", "args": {
		"motion": "move",
		"motion_args": {"by": "stops", "sub_word_begin": true, "word_begin": true, "forward": true, "extend": true }},
		"context": {"key": "setting.command_mode"}]
	},

In Vintage, “w” moves over sub-words, and “W” moves over normal words (This isn’t exactly what happens in vi, but it is keeping in the spirit of w vs W). If you change the key binding to not stop at sub_word_begin, it’ll act like W, which is closer to what vi does.

0 Likes

#6

Thanks for fixing the close-file-defaults-to-unexpected-file bug, Jon. However, you’ve only done it when a keybinding is used. I think on middle-clicking the tab (or, presumably clicking on the cross on a tab (I have them turned off so dunno whether or not that does it)) should do it too. Every now and again I’ll use the mouse rather than ctrl+w.

That is to say, that I think any time a tab is closed it should go back to previous in stack, not just when a keybinding is used. How does everyone else feel about that?

0 Likes

#7

Agree 100%. Btw, Statusbar is far more usable now, thanks for that Jon. Would it be possible to add quick encoding menu there too?

0 Likes

#8

I agree 100% too, and i really would like a quick syntax changer (like in textmate) in the statusbar. Is it doable ?

Thanks a lot =)

0 Likes

#9

What about a menu that appears when you click the current syntax label in the statusbar? Perhaps you could customise it to show your favourite syntaxes. Since, I for one, only tend to use:

  1. PHP
  2. JavaScript
  3. CSS
  4. HTML
  5. Python

So I’d only need to ever see them!

0 Likes

#10

Thanks Jon for the update.

[quote=“dsarch”]I agree 100% too, and i really would like a quick syntax changer (like in textmate) in the statusbar. Is it doable ?

Thanks a lot =)[/quote]

What do you mean? Is already there!

0 Likes

#11

Whoa, thanks !

I did not thought it could be clicked as it does not change anything or have a visual sign or something like that.

I liked @jbrooksuk idea (when i click i have a really big menu, and i would like to have just 5 or 7 options, perhaps with a setting like statusbar_syntax=“python”, “css”, “html”, “php”, “ruby”]

Thanks @jon and all the people in this forum that makes Sublime the great tool it is.

0 Likes

#12

Completely untested but presumably using ignored_packages you can turn off syntax availability of the languages you don’t care about and they’ll disappear from the menu. Added bonus is that they aren’t loaded in at startup = precious startup time?

Obviously this does mean that if you ever want to actually use a language you’ve ‘ignored’ then you can to remove it from there, but no biggie, right?

And like I said, this is untested and for all I know ignored is just for plugins, not any kind of package…

0 Likes

#13

No, since you can just go the usual Syntax menu and change it there. It’s just that it would be nice to have the most used syntax files there.

0 Likes

#14

I’d really like an option to control the close behavior. A lot of the time when I’m closing files, I’m closing several that are right next to each other and very rarely are they all the most recent in the stack. Having to constantly navigate back or use the mouse would be rather annoying. Ctrl/shift + tab are customizable in this way so hopefully the close behavior can be as well.

Also speaking of the ctrl/shift + tab behavior, it would be nice if they stayed in the active area. For example when in any of the layouts other than single, the tab binds will hop between the different areas which is pretty annoying.

0 Likes

#15

What was the clash? I was very confused when I hit cmd+option+up to go to my header file and it didn’t work.

0 Likes

#16

Oops! I’ll change the bindings again for the next version. Ctrl+Shift+Up/Down is no longer available on Lion, as Ctrl+Arrow keys are now the default keys for mission control (and annoyingly, it also eats ctrl+shift+arrow keys, which do the same thing as the unshifted version, just slower).

Next dev build won’t be until next week though, as I’m off on a short holiday until the 18th.

0 Likes

#17

Hi,

Maybe a simple request for a next release:
Default behaviour for closing tabs (Windows): CTRL+W

When I’m closing a lot of tabs, I’ll keep pressing CTRL+W. But when all tabs are closed, the editor is next. Maybe it’s an idea to give an alert-message: “Are you sure you want to exit?” Or maybe remove the keybinding for closing the editor, and only use ALT+F4?

Thanks

0 Likes

#18

[quote=“hoest”]Hi,

Maybe a simple request for a next release:
Default behaviour for closing tabs (Windows): CTRL+W

When I’m closing a lot of tabs, I’ll keep pressing CTRL+W. But when all tabs are closed, the editor is next. Maybe it’s an idea to give an alert-message: “Are you sure you want to exit?” Or maybe remove the keybinding for closing the editor, and only use ALT+F4?

Thanks[/quote]

If you implement this behaviour, please make it an option, since I frequently use ctrl+w to close the editor to avoid having to change my hand position to alt+f4, as ctrl+w doesn’t require moving your hand from the home row.

0 Likes

#19

[quote=“jps”]The w motion in Vintage is implemented with this command, in Vintage/Default.sublime-keymap:

	{ "keys": "w"], "command": "set_motion", "args": {
		"motion": "move",
		"motion_args": {"by": "stops", "sub_word_begin": true, "word_begin": true, "forward": true, "extend": true }},
		"context": {"key": "setting.command_mode"}]
	},

In Vintage, “w” moves over sub-words, and “W” moves over normal words (This isn’t exactly what happens in vi, but it is keeping in the spirit of w vs W). If you change the key binding to not stop at sub_word_begin, it’ll act like W, which is closer to what vi does.[/quote]

Thank you, that’s what I’ve been doing. Love the new status bar. p.s. hope you have a good holiday :smile:

0 Likes

#20

Have fun Jon! You deserve it! :smiley:

0 Likes