https://img.skitch.com/20120118-bd5cttp9c9uh141ht37wssghf2.png
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.
https://img.skitch.com/20120118-bd5cttp9c9uh141ht37wssghf2.png
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",
"font_size": 11,
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 shows
using gamma: 1 (err: 0)
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)).
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
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/dRHl
The 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?
To Jps:
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 hello
yes. also .hello
doesenâ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.
[quote=âFed03â]To Jps:
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 hello
yes. also .hello
doesenât workâŚ
any advice?[/quote]
[quote=âC0D312â]
Thatâs not really a bug. $ is considered a whole word in Sublime. You can change this in your file settings.[/quote]
maybe itâs for this?