Thanks for your help, managed to find the culprit - it wasn’t one of the packages, but a custom (old) .tmLanguage for libcello, which was based on the C syntax. It was referencing undefined scopes (e.g. scope:source.c#pragma-mark etc.), which in turn caused the above issue.
For some reason it works if I use the old C++.sublime-syntax, even though the undefined scopes all come from the C one.
Thanks again!
Thanks for this release! Since you’ve been working on improving rendering performance, can you take a look at this issue with scrolling on linux which also happens with build 3110? https://github.com/SublimeTextIssues/Core/issues/803?
I verified that ST isn’t using GL (libGL isn’t loaded) at least on my machine. Does ST use GL textures for rendering on any linux configuration?
Wow, I love how in a JS file the vertical line changes ‘strength’ based upon indentation/scope level – is this new in this build or have I just not noticed it before?
I deleted ~/Application Support/Sublime Text 3
and after reinstalling all packages everything went fine.
Keep up the good work!
Long live Sublime !
Same horizontal line with a similar panel layout on Ubuntu 14.04 64bit. Drawn at the same horizontal row where the panels on right side transition. Disappears on resize and redraws as soon as you scroll the big pane.
You mean indentation guides, right? There has always been an option to specifically highlight the most-inner block scope, but it must be enabled in the preferences and the color scheme needs to support it.
in my limited testing, window.status_message is the same as sublime.status_message in that both only affect the relevant window. I guess the advantage of window.status_message is that you can update the status of the non-active window.
As before, if you want to set a temporary status message only for a specific view, you have to use view.set_status(key, value) and set a timeout to clear it like: sublime.set_timeout(lambda: view.erase_status(key), 5000)
sublime.status_message updates all windows while window.status_message only shows the message for one.
that’s what I expected too, but try it - it only updates the current window, at least on Windows
hmm interesting, I tested on 3103 on Linux and sublime.status_message works as you describe, but on 3111 on Windows, clean install, it only affects the current window. I will test 3111 on Linux when I get chance to upgrade.
Confirmed that 3111 on Linux behaves the same as Windows - sublime.status_message affects only the active window.
How are you testing this?
[w.status_message("test%d" % i) for i, w in enumerate(sublime.windows())]
does it just fine for me, as does only using one Window object to set the message individually.
I’m discussing sublime.status_message - not window.status_message - I have no problem with window.status_message. You said:
I’m saying it doesn’t any more - but it seems it used to in older builds.
sublime.status_message('test')
sublime.status_message('test')
is it a bug or a change in functionality? if it’s a desired change, there is no need for the new window.status_message API because sublime.status_message now does the same thing…
Sorry, my bad. I can confirm the behavior you are reporting with sublime.status_message only updating one window on 3111. It used to work differently previously, so I expect this to be a regression.
I can also confirm that 3110+ on Fedora Linux machine brings lagging in scrolling.
No, this is an intended change, since updating the status bar in every open window requires rendering every window.