Dev Build 3073

[jps]

Dev Build 3073 is out now, fixing an issue with Goto Definition in 3072.

I’ve also changed build system selection a little: the previous logic in 3072 would:

1. Determine the list of relevant build systems.
2. Check to see if the last used one is in the above list: if so, use it, otherwise prompt.

The new logic is:

1. Determine the list of relevant build systems.
2. Check to see if the last used one is in the above list: if so, use it.
3. See if the user has been prompted with this exact list of build systems before: if use, reuse that choice, otherwise prompt.

This will resolve the issue that Bizoo reported, where you are switching between two different file types, and there are multiple, but different, relevant build systems for each: under the old behavior this would result in constant prompting, but not with the new behavior.

[demon386]

When “save_on_focus_lost” setting is enabled, a modified file will be saved even when I use “Find”. This is annoying, because the behavior of “save” will force the editor’s focus to leave “find panel”. Should this be fixed?

[rp2906]

Could you look at the file permission problem again? Sublime Text 3073 under Linux still creates files with unsafe permissions: My umask is set to 0077, but files end up group-writable and world-readable.

Previously reported here:
https://forum.sublimetext.com/t/st3-linux-new-files-are-created-world-writable/10534/1 (build 3047)
https://github.com/SublimeTextIssues/Core/issues/239 (build 3059)

[berkus]

Problem with HTML changelog: I cannot copy paste it anymore.

Old non-html changelog was much more convenient.

[berkus]

For project based build systems such as Ninja or Make editor should switch working directory to “build_dir”, otherwise it tries to run ninja in source directory and silently fails.

[FichteFoll]

Changes to build systems sound good.

Regarding the save_on_focus_lost issue: Here are more cases where this is a problem github.com/SublimeTextIssues/Core/issues/574

[FichteFoll]

For project based build systems such as Ninja or Make editor should switch working directory to “build_dir”, otherwise it tries to run ninja in source directory and silently fails.

It should do that already. Makefile/Make.sublime-build has the following key:

"working_dir": "${project_path:${folder:${file_path}}}",

which will change the working dir to either the path of your .sublime-project file, the first folder in your current project or the folder of the file you were editing – depending on which is available and going from left to right.

[jps]

Could you look at the file permission problem again?

Will be fixed (properly!) next build.

FWIW, the current permissions issue stems from the file writing code looking like this:

f = fopen(...)
if (is_new_file)
    chmod(f, 0664);

I don’t know what I was thinking when I wrote that, the chmod call should not be there at all

There have been other issues with permissions in the past that stem from the byzantine complexity of trying to get atomic save to work in as many scenarios as possible, but the current issue is just the above error.

[bizoo]

Jon, could you please take a look at the TODO in symbol.py in a future release:

def select_entry(window, locations, idx, orig_view, orig_sel): if idx >= 0: open_location(window, locations[idx]) else: # TODO: restore sel if orig_view: window.focus_view(orig_view)
I’ve added these lines and I think it works fine:

def select_entry(window, locations, idx, orig_view, orig_sel): if idx >= 0: open_location(window, locations[idx]) else: # TODO: restore sel if orig_view: orig_view.sel().clear() orig_view.sel().add_all(orig_sel) window.focus_view(orig_view) orig_view.show(orig_sel[0])

[facelessuser]

Jon, I’ve noticed some inconsistencies in the tooltip rendering:

On all platforms (as far as I know) spaces right after images collapse to zero (not really sure why). Because of this, right after images, I place a   if I want a space afterwards.

On windows,   and normal spaces collapse to zero between images. So on windows, I then have to use a   followed by a normal space.

There are other oddities I’ve noticed as well. I will list one more. On OSX if I will notice that certain rows of images get slightly distorted. For instance, I had six rows of images I generated on the fly. They were png color boxes that were 32x32px with a 1px border. But on the sixth row, they looked like the top and bottom border were stretched to 2px or more. I imagine maybe the whole image got elongated on that row. But I don’t see these issues on windows. Not sure what would cause all of this.

[sunnyps]

I downloaded the 32 bit ubuntu deb by mistake but I noticed an issue with the 32 bit build (running on ubuntu 14.04 x64): The menus (both the menu bar and right click) are not stylized correctly i.e. they do not use the system theme.

[jps]

@facelessuser thanks for the report, those three issues will be fixed in 3074

[jps]

Jon, could you please take a look at the TODO in symbol.py in a future release:

Looks good to me too, will do

[facelessuser]

@facelessuser thanks for the report, those three issues will be fixed in 3074

Looks good.