[quote=“squ1b3r”]Something wrong with new version. It’s crashed about 20 times already
P.S. MacOSX[/quote]
No problems on my end. Been using it since this morning. Mac OS Snow Leopard here.
[quote=“squ1b3r”]Something wrong with new version. It’s crashed about 20 times already
P.S. MacOSX[/quote]
No problems on my end. Been using it since this morning. Mac OS Snow Leopard here.
I’ve seen a lot of crashes as well since upgrading to this version, on Arch Linux 64bit. I’m not sure how to generate a crash report…
[quote=“jps”]
Can you email me the crash report? What version of OS X?[/quote]
It happens on Snow Leopard and still happens on Lion too.
About crash report. What email I can use for it?
Yeah, for me too.
Thanks! I believe the issue is caused by the blinking cursor, if the caret_style setting is changed to disable blinking, it should go away. Hopefully the next build won’t be too long away.
Unless I’ve just happened to miss this setting for the past few versions (which I hope I haven’t, as I started writing a plugin to do it for me on save, but failed miserably when I didn’t know the ST2 API and the docs are for ST1) we also have another new setting which I’ve been longing for: trim_trailing_white_space_on_save (default false, I’ve overridden to true)
In addition to that, I don’t know how long this bug has been in (as I don’t use overwrite mode) but (and this may be dependent on caret style, I’m on the default of smooth) in overwrite mode, at the end of a line, the overwrite caret is just one pixel wide (trying to be as wide as the character under it which is a newline character and thus hidden. And at the beginning of a tabbed-in line, it assumes a tabwidth of 8 characters (I have 2) so it goes a bit funny.
Screenshots:
http://www.clevercherry.com/media/image/blogs/alex/overwrite-bol.png
http://www.clevercherry.com/media/image/blogs/alex/overwrite-eol.png
Obviously it doesn’t matter to me, as I pretty much don’t use overwrite ever. Just happened to notice it.
@alexrussell, In case you couldn’t solve the problem with your plugin, there’s some documentation here:
There seems to be a regression bug from 2083: “Tab close buttons will show on hover if hidden via show_tab_close_buttons” no longer works.
2085 is out now, with a fix for the crash introduced in 2084.
There are a few under the hood changes on the OS X side of things, too - this is the first build compiled on 10.7, although it’ll work on 10.6 and 10.7.
There seems to be a regression bug from 2083: “Tab close buttons will show on hover if hidden via show_tab_close_buttons” no longer works.
This is touched on in the 2084 change log: it received only negative feedback, so I took it out.
This is touched on in the 2084 change log: it received only negative feedback, so I took it out.
Too bad, I actually liked it. I guess people didn’t like the way the tab text moved on the hover. Oh well, keep up the great work!
Output panel heights are deserialized from the session
Is the height of the build panel saved ?
It half work:
Open ST2 -> Build -> change height of the build panel -> close the panel -> Quit ST2
Open ST2 -> Build -> (OK: The panel has the previous height) -> close the panel -> Quit ST2
Open ST2 -> Build -> (OK: The panel has the previous height) -> close the panel -> Quit ST2
Open ST2 -> Quit ST2
Open ST2 -> Build -> (KO: The panel height is reinitialized)
startup, version: 2085 windows x64 channel: dev
I experienced a massive bug the other day…
Sublime crashed whilst I was editing a file, when I went to open it again, all of the content had gone. Nothing left, just the file. This was Dev Build 2083.
Anyone use lunixbochs’ sublimelint plugin? I think this last build may have effected it. Usually it will catch unused imports, and now it doesn’t.
Edit: nevermind, not sure what was going on. Works fine now.