Same issue here in 2166 on a Mac using Solarized (Light) color scheme and DejaVu Sans Mono font face.
But it seems to happen with all fonts and themes.
Just thought that I'd throw in the fact that on Windows 7 64bit, no problems
I have a rendering issue when selecting a text block and run 'Split into Lines' (ctrl+shift+L) after:
"font_face": "DejaVu Sans Mono",
startup, version: 2167 windows x64 channel: dev
For those OS X users experiencing issues, can you give this build a go (it has to be downloaded manually, and isn't yet available via auto update), and let me know if it's fixed. It'd also be helpful if you could check the console for the "using gamma" line and report the two numbers listed there.
Working fine for me now. Thanks for the super quick response.
the console showsusing gamma: 1 (err: 0)
The new build has fixed the issue. Thanks
I didn't check the previous build and didn't see the problems, but with this special build everything looks fine (using gamma: 1 (err: 0)).
everything looks fine
using gamma: 2 (err: 6.9282)
here are two screenshots of same file with the same config. I will try to give you information about system in another post. This happen whatever the theme, font family, font weight I choose. Current is default theme with lazy color scheme.
Thanks for the report. This bug will have to stay for a little bit though, until I'm able to get some other planning changes done
sorry, the thread went to fast, i didnt see the second page and the build. This build solve the font problem I have on OSX. Thx
The new build solved my text rendering issue too.
using gamma: 1 (err: 0)
I'm not sure if this is new since the text rendering changes, but thought I'd point it out in case it is:
http://puu.sh/dRHlThe highlighting behind the "&" characters doesn't cover the whole character, it would seem.
Under WindowsXP, there is strange issue: when selecting multiple instances of the same text, e.g. using "find all", the first instance becomes bold for some reason, and the following ones gradually become normal, as they should be
Also, key shortcut for "find all" (alt+enter for windows) does not work anymore in find dialog, if the text within the dialog box is selected (default for find_selected_text:true). If the cursor is at the end of the text, and nothing is selected, it works.
I'm still having issues with certain characters getting cut off when my cursor is on a line. (see the "e" on the first line where the cursor is)cl.ly/160A040i351r3u3b2M0J
It goes away when the cursor is moved off that line. Right now I'm using setting "font_options" to "subpixel_antialias". The options "bold", "italic", "no_antialias", "gray_antialias" all do the same thing except for no_antialias but that looks terrible. Is there any way to prevent this from happening?
hi,i don't think that's realted to your last build(at least this is present also in 2165)but have you changed something in snippets?
for example tabtrigger like $hello doesen't work but helloyes. also .hellodoesen't work...any advice?
Not sure if this is a recent bug or not, but thought it'd be best to throw it here. Getting weird line/word wrapping in this case ('$' is left on the previous line): puu.sh/e7y5
That's not really a bug. $ is considered a whole word in Sublime. You can change this in your file settings.
maybe it's for this?