Sublime Forum

Sorry, but 3.2 is the worst version ever (unless git integration is disabled)

#1

I’ve been a very happy (licensed) user for a few years, but now 3.2 came and it is so painful.

My scenario: i’m on MacOS (High Sierra), running Linux VM in VirtualBox where all project live. Projects are large, few thousand files. Directories are mounted over SMB. When mac goes to sleep network share often disconnects.

All previous versions of the editor were surviving this happily. If there was an open file it would start showing “dirty” flag, but once network mount reconnect it resyncs file state and that’s it.

3.2 problems:

  • when network mount disconnects, the editor crashes here and there. E.g. even if the mount has reconnected, if I navigate to a file known to the editor (e.g. Cmd-P) it will crash silently trying to open it (again, volume is remounted at this point).
  • initial load of the project when you start the editor is now take quite long time. But not always, this is inconsistent. Sometimes it would start and sync the state in few seconds, sometimes it will be “loading” directories for few minutes.
  • git integration just does not work in this case. Name of the active branch has nothing to do with reality, status of individual files as well.
3 Likes
#2

Do things improve if you turn off the git integration?

1 Like
#3

I don’t agree with the tone of the above post, but I’m having the same issue regarding network mounts and Sublime crashes (mine are over OSXFuse + sshfs, so it isn’t exclusively an SMB thing). I had to revert to the previous version of Sublime because of this.

I’ll try disabling git integration in 3200 to see if it helps my case. Network mounts may seem like a niche use case, but it affects any dev who primarily edits files that are hosted on a virtual machine (this is most FANG devs, at minimum). I’d really like to be able to use the git integration too - it’s a cool improvement.

1 Like
#4

(Seems to be fixed with "show_git_status": false and forcing drive disconnect weirdness, but the crashes were pretty sporadic beforehand so hard to say)

3 Likes
#5

Disabling git integration have fixed the problem for me. Will keep it disabled for now. Will report if there are any new issues not related to the git.

Happy Sublime user again?

0 Likes
#6

Have either of you tried build 3203? We fixed some git issues in that.

0 Likes
#7

Ok, gave 3203 a quick try.

  1. loading is still taking long time (have not experienced minutes yet, but tens of seconds). During the load I can not unfold directories.
  2. Git status dot on each file is wrong (forgot to report this issue initially). It shows majority files as modified. Most but not all, there is no any pattern here.

I will let you know after more observations if it crashes like 3200 or not.

0 Likes
#8

3203 with git enabled crashes as described for 3200. (Cmd-P when network volume ceased to be available).

0 Likes
#9

Right click -> “Delete file” does not work.

0 Likes
#10

This new ST is eating all my MEM if i focus back to sublime. I have large py project with venv inside. Is there way to rever this version?

0 Likes
#11

I found problem. I had some large db file opened and if i focused to sublime then it was reloading this file.

0 Likes
#12

Can you check your Console to see if an error is listed?

0 Likes
split this topic #13

2 posts were split to a new topic: Memory Leak on Switching Themes

0 Likes
#14 
  Traceback (most recent call last):
  File "/Applications/Sublime Text.app/Contents/MacOS/sublime_plugin.py", line 1050, in run_
    return self.run(**args)
  File "/Applications/Sublime Text.app/Contents/MacOS/Packages/Default.sublime-package/side_bar.py", line 28, in run
  File "/Applications/Sublime Text.app/Contents/MacOS/Packages/Default.sublime-package/send2trash/plat_osx.py", line 44, in send2trash
  File "/Applications/Sublime Text.app/Contents/MacOS/Packages/Default.sublime-package/send2trash/plat_osx.py", line 33, in check_op_result
OSError: Directory not found
0 Likes
#15

Which (Directory not found) is not true of course, I can browser the directory in ST and open files there. Just to clarify again, this all happens when working on network volume which sometimes gets disconnected and reconnected. However previous ST version hasn’t have this problem.

0 Likes
#16

We haven’t updated the send2trash module in a long time, nor modified the delete implementation in side_bar.py. Sounds like the issue has probably been around for a while.

0 Likes
#17

I can try with older build, how can I try it. May be the issue is old, but I have never noticed that before (not that I often delete files from ST GUI)

0 Likes
#18

The error that you’re seeing is not telling you that the folder that you’re trying to delete from doesn’t exist, it’s telling you that when it tries to put the folder in the Trash, the Trash folder doesn’t exist.

I’ve seen that happen on Linux occasionally (where for whatever reason my user literally had no Trash folder). In this case since it’s a network volume, I would imagine that the problem is that the OS is trying to put the file into the trash folder on the network share and failing.

2 Likes
#19

I don’t remember deleting files from the sidebar ever working for stuff on a network drive. I think I remember from 4~5 years ago that it didn’t work, and it definitely doesn’t work now (in between I worked some other place where I could work on stuff locally).

See also: https://github.com/hsoft/send2trash/issues/10, I guess it’s not fixed in the library either. I guess I could roll my own rm -rf ${path} command to work around it.

Edit, this works:

class ForceDelete(sublime_plugin.WindowCommand):
    # Delete file without sending it to thrash

    def description(self):
        return 'Immediately Delete File'

    def run(self, paths):
        for f in paths:
            if os.path.isdir(f):
                for v in self.window.views():
                    if v.file_name().startswith(f):
                        v.close()
                shutil.rmtree(f)

            else:
                v = self.window.find_open_file(f)
                if v:
                    v.close()
                os.remove(f)
3 Likes
#20

ok, good point.
Still would be good to have ST to mimic native Finder behavior.

0 Likes