Sublime Forum

**wbond** · February 28, 2018, 2:12am

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

**devcarlos** · February 28, 2018, 4:05pm

"ensure_new_line_at_eof_on_save": true,

Has stopped working.

**addons_zz** · February 28, 2018, 5:06pm

Still working here:

**devcarlos** · February 28, 2018, 5:34pm

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.

**kingkeith** · March 1, 2018, 3:06pm

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

reproduction steps:

stock ST3157 Windows x64
create this plugin that will create phantoms: https://github.com/SublimeTextIssues/Core/issues/1822#issuecomment-316679383
new view/file
set syntax C#
paste the following

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

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

**kingkeith** · March 1, 2018, 6:48pm

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 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

**wbond** · March 2, 2018, 3:15pm

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

**deathaxe** · March 2, 2018, 6:43pm

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.

**kingkeith** · March 4, 2018, 1:20pm

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

**kingkeith** · March 4, 2018, 2:01pm

after experimenting on Linux, to see if it happens there, I found the answer. My syntax test file references PowerShell.sublime-syntax, but the actual file in my filesystem is lowercase powershell.sublime-syntax. It seems this causes the syntax test runner API some confusion. Correcting the case fixes the problems it seems.

**bumfod** · March 11, 2018, 2:01am

Thanks for detailed explanation! It seems that many apps with custom titlebar simply removes traditional window title and icon, and some of them draw it itself.

Since most apps does so, may Sublime Text add an option to remove traditional window title and icon in future release? I think a beautiful look is more important than traditional window title bar and icon at least for someone, like me ;).

**wbond** · March 11, 2018, 3:58am

During the development of the Adaptive theme I played with fully-custom title on Mac, but in fact it would have required a bunch more work. The stoplight buttons need to remain, and the sidebar can be hidden, so to drop the title and proxy icon (which many Mac users use), we have to do a bunch of work to get tabs that adapt around the stop lights and also make the sidebar adapt around the the stop lights. We’d lose the functionality of the proxy icon and the name of the project would no longer be displayed in the interface. We’d also have to try to find a new way to display notices about unregistered copies.

In the end it was almost completely downsides, with the only pro a “simpler” looking title area. It didn’t seem like a good trade off, especially considering how much more development time would have to go into it.

**gechr** · March 18, 2018, 1:21pm

This build seems to have changed (broken?) how the --wait CLI flag interacts with Sublime on close vs. quit on macOS (10.11.6):

# build 3156
$ echo foobar | subl --wait --new-window
# editor opens; hack hack hack; save – ⌘W
# returns to terminal; ends the process

$ echo foobar | subl --wait --new-window
# editor opens; hack hack hack; save – ⌘Q
# returns to terminal; correctly ends the process

# build 3157
$ echo foobar | subl --wait --new-window
# editor opens; hack hack hack; save – ⌘W
# returns to terminal; ends the process

$ echo foobar | subl --wait --new-window
# editor opens; hack hack hack; save – ⌘Q
# returns to terminal; hangs (should end the process - broken between builds?)

**FichteFoll** · March 18, 2018, 1:35pm

Did you have a sublime process running already? If no, did opening St with the - - wait argument open more than one window?

**gechr** · March 18, 2018, 3:40pm

Did you have a sublime process running already?

No. Just tested and the (mis)behaviour persists whether I have Sublime already running or not.

did opening St with the - - wait argument open more than one window?

No. It only opened one window.

Dev Build 3157