Dev Build 2163 is out now - with a bit of luck, this will be the last build before the next beta.
Dev Build 2163
This issue still present: http://www.sublimetext.com/forum/viewtopic.php?f=2&t=4502&start=0#p20330
It’s a side effect of tab_completion, where it cycles through the completions even when there’s only one completion. I’m not planning on addressing this for the beta.
Fine, it’s not a big deal.
Auto complete: Enter is again the default key binding to commit the completion. The auto_complete_commit_on_tab setting can be used to configure this.
May I ask you why you (partially) changed your mind on this ?
Maybe I’m wrong but it look it was fairly well accepted by users, so why Enter is the default again ?
It was maybe 50/50 among forum users, but responses I got from people outside of the forum were more negative.
Commit-on-tab is better, but it’s not what people expect, and it forces users to learn a new way of doing things to be able to use the program. It would give too many people an initial negative reaction - better to have it work how everyone expects out of the box. For the people who are willing to put in the time to get used to commit-on-tab, having to enable it first isn’t a barrier.
[quote=“jps”]
Make sense, thanks for your reply and for your hard (and sometimes not very rewarding) works.
C’mon man, add an option like: tab_cycle_completion:
[code]{ “keys”: “tab”], “command”: “replace_completion_with_next_completion”, “context”:
{ "key": "last_command", "operator": "equal", "operand": "insert_best_completion" },
{ "key": "setting.tab_cycle_completion", "operator": "equal", "operand": true }
]
}[/code]
Really annoying to remove this snippet from default keymap file on every update…
gabriev82: Yep, and thanks for the detailed report btw. The issue is also in 2139 though, so I’m not going to block the next beta for it - will get it sorted later.
it’s ok, I understand
Please take into consideration to fix it for the next next beta.
Thanks
I keep changing my Default.sublime-theme setting:
{
"class": "tab_label",
"fg": [0, 0, 0, 255],
"shadow_color": [255, 255, 255, 80],
"shadow_offset": [0, 1]
},
to:
{
"class": "tab_label",
"fg": [0, 0, 0, 255],
"shadow_color": [200, 200, 200, 80],
"shadow_offset": [0, 1]
},
What does the last parameter in shadow_color stand for? Is it opacity/alpha? If so, it doesn’t work. Until it does the default shadow color should be 200, 200, 200. 100% white makes the tab labels difficult to read. Compare (it’s best seen when you set the zoom level to 100% in your browser):
http://www.testomaniak.pl/tabs1.png
http://www.testomaniak.pl/tabs2.png
I’m still having the (quite serious!) issue that pressing tab is inserting the “best completion” rather than moving to the next field after a snippet is inserted.
spadgos: I haven’t been able to replicate that. Does sublimetext.com/docs/2/revert.html fix it for you?
Put that changed setting in your User/Default.sublime-theme and you won’t have to keep changing it.
It’s number of pixels to offset the shadow by in x and y.
Edit: oops, thought you meant shadow_offset
It’s alpha, however it only takes effect on OS X and Linux, as on Windows GDI isn’t able to draw text with alpha.
[quote=“jps”]
It was maybe 50/50 among forum users, but responses I got from people outside of the forum were more negative.
Commit-on-tab is better, but it’s not what people expect, and it forces users to learn a new way of doing things to be able to use the program. It would give too many people an initial negative reaction - better to have it work how everyone expects out of the box. For the people who are willing to put in the time to get used to commit-on-tab, having to enable it first isn’t a barrier.[/quote]
I didn’t complain about it because I could remap it back to Enter (more or less). Otherwise, it would’ve been a big negative since I don’t have a left hand