Dev Build 3119
Should color schemes and syntax definitions avoid constant.character? It is not present in the current list (though constant.character.escape is), but it is kinda stupid not to style char constants.
For those experiencing crashes on Mac, I found that if I removed this line from my Session.sublime_session that sublime would start up just fine:
“last_version”: 3118,
In my case, it was found near the top of the file.
I’ve found the command already, thanks. I’m more worried about the conditional check against 3116+ for the menu. I’ve so far only come up with nasty workarounds in my head.
I solved this by clearing history in IE: (see here for more details).
pressed Tools | Internet Options (General tab) | Delete,
in order to delete temporary files(using the default settings).
After that, the update completed successfully.
Could you give an example of how it is commonly used? I may have just missed it in my digging and rewriting. All of that documentation is more or less a brain dump of having rewritten a whole bunch of the syntaxes and having looked at some of the statistics dumps done in A convention for scope naming.
Is there a way I can reproduce this output? Also, what platform are you on? Are you using HiDPI/Retina?
There seems to be a number of factors. It can occur in popups and in phantoms. See issue here:
In the case of the issue above, I couldn’t reproduce it, maybe it was a combination of font size, line height, and/or image size.
In the picture I posted earlier, this occurred in a popup, I increased the image size and I saw some image distortion, and when I increased the size a little more, I saw the second image in the popup get cropped. This was not an issue in
3118.
I replicated the popup issue on my Mac low dpi. The phantom issue covered in the github issue was on a Windows machine, but I do not know the resolution of his screen.
Lastly, I have noticed yet another issue in 3119. I have a couple of color schemes that define popupCss, but in 3119, it appears it doesn’t always recognize them. Sometimes it does, and sometimes it doesn’t, but it leans heavily towards not recognizing them. If I remove the popupCss, then of course it uses the internal generated style. It seems to only really want to use the generated one, and if you define your own, it gives you a white popup with black text. It is fine if I feed my own CSS in through show_popup or add_phantom.
If you could link to one’s you’ve seen it on, that would be helpful in me trying to debug. We generate some CSS that is always prepended to the stylesheet, for setting things like the background-color, font and font-size. With 3119 we now also prepend color variables to popupCss and phantomCss. There may be a bug somewhere in there.
@wbond Here’s one: https://github.com/facelessuser/Aprosopo/blob/master/Tomorrow-Night-Eighties-Stormy.tmTheme.
I just tried to replicate, but was unable to. Perhaps create an issue at https://github.com/SublimeTextIssues/Core/issues with your setup and what plugin, settings, etc? If you’ve already done that, just point me in that direction.
@wbond, I figured out the issue, 3119 is not stripping out \r from popupCss. If I switch to unix line endings in the scheme, the problem goes away.
@wbond as requested:
This was tested in portable ST3 3119 with no plugins installed.
I will have to see if I can create a scenario to replicate this image distortion issue better. Once I have that, I will create the issue.
Perfect. I copy-pasted the color scheme to a file on my machine, and I default to unix line endings. Thanks for figuring it out!
With regards to image distortion, we’re not currently snapping anything to pixel coordinates within minihtml, so if margin, padding or line height introduce fractional values, then the image can be drawn at a non-pixel aligned location, which may account for some artefacts, but the cropped border above doesn’t really look like this
I should note that while this was happening for me on my main ST install, on a 3118 portable build that I let update to 3119 (and it didn’t happen on 3118), and on a portable 3119 version, after I had rebooted my computer the next day, it was gone. It hasn’t recurred since.
@wbond On a similar note, the same thing happens when using plist files like I’m doing it here:
If you have *.tmPreferences files with windows line endings in that setup, it completely messes things up.
As @FichteFoll says there:
If there was better tmPreferences integration for variables such as these, things like SublimeText/AsciiDoc@c8ea594 could also become feasable.
Especially the support for piped lists would be nice.