Sublime Forum

Dev Build 3157

#10

Is go to symbol within the current file completely broken in this build for anyone else?

0 Likes
#11

if you’re talking about JS, then yes, otherwise no

3 Likes
#12

there still seems to be a sporadic bug in the syntax highlighter, whereby editing a line can cause subsequent lines to end up in the wrong context. No idea how to reproduce it, I’m afraid, but just now I was editing a small C# file, and added /* to the start of a line which had public interface Blah // line comment here on it, and the { on the next line still had the meta.interface scope with no comment.block scope to be seen. Reloading the file fixed the problem.

0 Likes
#13

Thanks for the report. I’ll see if I can do some digging and figure out what might be going on here.

0 Likes
#14

Since upgrading to 3157 (macOS 10.13.3), double-clicks on results in the Find Results tabs jump to the corresponding file, but a different tab gets the focus. I wasn’t able to reproduce this with only a few tabs open. This only seems to happen when the file wasn’t open before, since a second double-click on the same result focuses the correct tab.

Edit: I’ll have to investigate this further, the problem could be caused by the Zen Tabs package.

0 Likes
#15

I’ve noticed that Sublime closes when unplugging my external monitor. I’m sure it happens at other times too but i’ve not been able to reliably reproduce those instances.

I wonder if anyone else had noticed something similar?

0 Likes
#16

Can you create an issue at https://github.com/SublimeTextIssues/Core/issues with details?

0 Likes
#17

My hunch would be some sort of package issue, or an issue that existed before. I don’t believe we’ve touched anything related to that in a bit.

0 Likes
#18

Have anyone ever noticed that on mac when a dark colored titlebar meets bright text, the text looks bold in a way that feels unnatural?

Screen Shot 2018-02-18 at 7.19.10 PM.png874×560 42.4 KB

And then If you try black titlebar with black text, you’ll see a white “outline”, which is actually antialiasing which assumes bright background. This answers why the bright text on black colored titlebar looks bold and unnatural.

Screen Shot 2018-02-18 at 7.17.44 PM.png874×560 42.4 KB

0 Likes
#19

I’ve had Zen Tabs disabled throughout last week without the problem recurring again. Will submit an issue for the package.

1 Like
#20

Yes. Unfortunately this is something that Apple does automatically, and I don’t believe we have any way to 100% influence it. Apple only allows limited control over the title bar, and we have to do a bunch of hacks to try and create a fully custom color for the background and foreground. If I recall correctly from my testing, we ask for text to be in a certain color, and Apple is sending it back aliased against a background. It probably has something to do with the fact that the text is in a transparent view that overlays a full-window content view (which allows us to control the background color).

Until Apple releases APIs that allow for custom title bars with traditional window title and icon, we’ll have to fake it as best we can.

1 Like
#21

I’ve pinned this down and we’ll have a fix in the next build.

4 Likes
#22 
"ensure_new_line_at_eof_on_save": true,

Has stopped working.

0 Likes
#23

Still working here:

2 Likes
#24

Thank you for letting me know it was still working.

Just removed it from the top of my preferences to the bottom and it suddenly started working again… weird.

0 Likes
#25

Jon hit the nail on the head in Discord when he asked if I had any active phantoms in the text buffer at the time. I’ll answer here as well for the sake of people not following Discord discussions, plus my reply there was a bit messy :stuck_out_tongue:

reproduction steps:

using abc;

namespace Test
{
    public interface FooBar // comment
    {
        void TestMe();
    }
}
  • move the caret to before public
  • type /*

if it’s a problem with my code that creates phantoms, I’d be happy to hear it :slight_smile:

curious to know why phantoms can affect it in this way though - https://github.com/SublimeTextIssues/Core/issues/1497 is also related

2 Likes
#26

I also noticed while working on a new syntax definition in 3157 that sometimes the syntax test build system seems to cache the definition or something, because if I make changes to the definition, save, and build a syntax test file I have open, what it reports as failures are very out of sync with the scopes I see. This is definitely not related to phantoms :wink: restarting ST fixes it, until I make another change and test again.

My test file just references the definition’s filename, not a full path, I will try that when I get chance.

Mainly the changes I see this happen with are changes to where a context is pushed etc.
In general 3157 seems a lot faster than older builds though, so great job there :slight_smile:

0 Likes
#27

Is this new with build 3157, or can you reproduce it with older builds?

0 Likes
#28

I can confirm this issue happening with older builds, too. I ran into such a situation several times in the past, too, but never found a way to reproduce it for sure. After a lot of changes - maybe too quick ones it was suddenly there. Waiting a bit or saving the syntax-file again often fixed it. If I recall correctly I often found some kind of temporary files within the Cache\syntax-name folder then, but don’t know whether it is related.

0 Likes
#29

what @deathaxe is describing sounds like https://github.com/SublimeTextIssues/Core/issues/890 to me

I really thought my issue was new to 3157, which is why I posted it here, but I’ve just tried in 3156 and 3154 and it’s also present there

EDIT: crazily, this is also happening in 3126… I’m going to try make a MCVE when I get chance

image.png656×538 57.7 KB

0 Likes