Sublime Forum

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

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

D’oh, I never noticed that the files are moved to trash instead of a hard delete :sweat_smile:

0 Likes
#23

Mmm, strange, my last comment was deleted :open_mouth: … not sure if it was me who didn’t press the save button or the comment was banned from moderators lol,
anyway, I’ll assume it was just me being clumsy so lets try again :slight_smile:

Thing is, I’ve been a happy user using the awesome 3176 release for months and after reading a lot of comments for the last days
talking how bad version >=3200 was I don’t see myself playing with the new version anytime soon.

It seems a lot of problems from that version come from the fact of having this new git integration.
I guess the end goal of that feature will be promoting users SublimeMerge. If this feature is optional
and you can disable the git integration completely (this is, not being forced to have any git background
tasks eating your CPU time and keeping ST lightweight) then everything fine as we’d be talking about
an optional feature (which is intended to use an external 3rd party tool). On the other hand,
if as a user you’ve been forced to live with something you may don’t need I think that’s
not cool at all.

For instance, I’ve got my own custom code/plugins that allow me to use git without having to run any
background tasks so I can keep ST as light&fast as ever, I’m fine with it and I wouldn’t
like to be impossed any new git integration nor using any additional software (even if SublimeMerge is
great, let’s assume it is).

Having an indexer running behind the curtains? Sure, that’s great&necessary as a lot of core plugins
will benefit from it, nothing wrong with it… But being force to have a git integration you didn’t ask
for? Then sorry but I think that’s not cool.

Of course, if this "show_git_status": false grants there will be no extra background tasks
spawned and the git integration is fully gone, then cool, nothing wrong with it of course
but otherwise forcing users with features they may or may not want… well, I think that’s
the same wrong approach than companies like Google do when forcing updates such
as gmail. Do you rememeber when they forced users to use a newer much worst version
than the previous one? That made a lot of people get angrier and considering not
using gmail anymore :confused:

Summing up, adding new features is of course awesome and I’m sure a lot of users
will love it but pleeeeeease, try to not force the minority of people and give them
the chance to choose between using or not the new fancy stuff. I’m sure I’m not the
only one who gets pissed off when wasting a lot of time because newest versions
disrupt their workflow with “subtle” but disturbing changes :wink:

Peace!

Ps. Sorry, I’m one those users who’re reliant to changes that may lead to waste of time :wink:

0 Likes
#24

"show_git_status": false and "mini_diff": false should pretty much disable all of the new git integration.

To be clear, there are no git background processes here. It’s done within Sublime in a fashion which is more lightweight than what git itself does, and also much more lightweight than what a lot of the alternative plugins do (e.g. GitGutter is much slower and does have background processes that it juggles). I’ve been using the git integration on the dev branch for quite a long time. I don’t feel pushed to Sublime Merge at all, and I’m manic about my editor remaining lightweight, fast, and energy-light. The new features have been an improvement in this respect (particularly since I’ve been able to drop GitGutter), and in no way a step back.

Obviously, a lot of this stuff is very subjective, but I think it was a really good set of features to add and generally very well executed. And if you don’t agree, you can just turn it off as I described.

2 Likes
#25

Thanks, If I ever upgrade I’ll have those 2 settings into consideration :wink:

In any case my only point from my previous comment was that if new features can be enabled/disabled you’ll keep all your users happy (no exceptions), that’s pretty much all I wanted to say.

To be clear, there are no git background processes here.

Jon talked about that very briefly here, If I’m not mistaken it seems there are 3 backgroun threads and the 3rd one can be disabled through user settings (if I’ve understood correctly)

and I’m manic about my editor remaining lightweight, fast, and energy-light.

Same here, I’m a total geek about control and if I can’t control fully the main tool I use to code that will bother me… And don’t get me wrong, I’m not saying that particular git feature or even SM are bad, probably they’re great (assuming cos I trust the team)… but some users like me are reticent to changes and we like to upgrade at out own slow pace. Even more, I tend to upgrade my software very very rarely cos I know 99% of times will take me time in one or another way.

Obviously, a lot of this stuff is very subjective, but I think it was a really good set of features to add and generally very well executed. And if you don’t agree, you can just turn it off as I described.

Good to hear, I was getting a little bit biased towards all those negative comments in the opened thread these days. it’s good to read positive feedback/reviews to have into consideration… Plus, the title of this thread has also been quite “dramatic”, so sorry if it’s scared the hell out of me :smiley:

0 Likes
#26

Jon talked about that very briefly here , If I’m not mistaken it seems there are 3 backgroun threads and the 3rd one can be disabled through user settings (if I’ve understood correctly)

Threads, yes, not processes. Sublime Text doesn’t fork out to git, and its own internal implementation of Git’s status system is much more efficient than Git’s. So in other words, it’s not doing the naive thing that you might expect with git-diff and git-status (this is actually what GitGutter does); it’s considerably more efficient than that.

But yes, it can be disabled.

Good to hear, I was getting a little bit biased towards all those negative comments in the opened thread these days.

I think there are some legitimate issues with 3.2, particularly relating to network drives and/or people who do bizarre things, like throw their entire home directory into Git, but by and large I honestly believe it’s the best Sublime release yet. The improvements are excellent, but understated, as they should be.

2 Likes
#27

I’m sorry for that. This is only my personal experience, but 95% of my ST work is happening via network volumes (BTW if sublime had native remote directory access ove SSH as Far manager used to have in the past that would be totally awesome and would remove a need for this buggy samba/apple client mounting experience). And with such pattern 3.2 release happened to be disastrous for me (till I switched git off).

0 Likes
#28

This may help: https://wbond.net/sublime_packages/sftp

0 Likes
#29

Until the dust settles on V3.2 I’m happy to stick with V3.1, which is working trouble free. Is there some way I can get ST to stop asking me to upgrade?

0 Likes
#30

You can add this to your user preferences:

	"update_check": false

That disables the update check; note however that the setting only works in a licensed copy; for trial users, the impetus is to always be using the most recent trial.

0 Likes
#31

Also, note that v3.2.1 is out with fixes and mitigations to most of the issue we saw reported after 3.2 was released.

2 Likes
#32

If you work with git over SMB mounts the file status will never be correct as git tracks file rights and they get mangled in SMB. you can migitate a bit by having “filemode = false”. It still will track symlinks as changed as SMB can’t deal with symlinks

0 Likes
#33

Hi, not sure I understand what’s exactly the problem with file rights? in git and smb… But if you state it is not feasible to get git state reliably over SMB then it is responsibility of ST to detect such situation and handle in one way or another (disable git integration, warn user etc). It is unreasonable to expect that users will go and fix this broken case

0 Likes
#34

I am not sure this is something Sublime Text can or want to do. It is easy to get workaround for most issues with “filemode = false”.

If you use the commandline git you have the same issues if you work on a SMB mounted share. This is how it is. It sucks, I know, I try to find a work around for this since SMB exists. But there is none, because that is not how SMB works. NFS mounts might work.

0 Likes
#35

Sorry but … I have my dad old pc,fast but 32bit architecture (there is installed linux, an updated Slackware-current), with ST 3176 everything works great wile since 3180 if I esecute sublime, as root it needs about 40 seconds to open and as user I just receive a “Segmentation Fault” error message. Moved back to 3176 … everything works great as root and user and it takes not more than 3seconds to be opened. My personal pc instead is a 64bit and have linux (slackware64-current) with same packages installed and here 3207 works great without segfaults errors and it’s fast. There’s a problem with linux 32bit version??

0 Likes
#36

I use NFS for working on VMs and have yet to see any slowdowns. I even work on a server on the LAN over WIFI and it’s still very fast on a project with thousands of files.

0 Likes
#37

In my case, on an updated MacBook, performances are not a problem, but the behaviour with NFS is unpredictable and less stable than ever before.

Almost always I will get an error when ejecting a mounted network volume because

SublimeText is using it

while I almost never had that problem with versions < 3.2.

Also, looks like indexing is triggered a lot more than before or that it takes more effort. In the last weeks I have really annoying issues with CPU use, after upgrading to ST 3.2.
Almost all my projects are on Vagrant and the filesystem accessed via NFS, but ST has more difficulties with them. Lately I also get a lot more drive activity on the virtual machine, sucking the CPU, that (I suppose) are caused by Sublime doing something more than before.

A couple of times it crashed just when clicking on a file in the sidebar, just trying to open it (a regular text/code small file; nothing crazy). That never happened before and I had really few crashes by ST in the last years.

EDIT (5min later): it just happened again… The NFS volume was not mounted and Sublime crashed completely just trying to open a normal text file (hint: it might be that it was already among the opened tabs).

EDIT (10min later): restarting Sublime triggers the use of 140% of CPU over the Vagrant machine where the project files are.
There is no indexing happening (or at least, Sublime doesn’t mention it) but the machine is unusable, everything is terribly slowed down.
If I close Sublime everything comes back to normal 3-5% use from the virtual machine.

EDIT (15min later): I disabled the git integration (show_git_status: false). Now (after a while from start) it shows an indexing happening (with previous run I could see some indexing happening because of folders not expanding and still refreshing, but no indicator was shown in the status bar); it was reindexing from 95%.
After finishing the CPU came back to normal. Unfortunately this whole behaviour is happening many time, regardless the fact that I’ve completed the indexing many times in the last days (and changed almost nothing in the project, so I don’t understand this continuous need to reindex…).
I am trying to see what is the problem, but the console doesn’t even open. Clicks on the bottom left icon doesn’t react at all…

I am sorry, but am seriously thinking to downgrade, give up the comfort of the SublimeMerge integration, and just wait when the 3.2 will be more mature and tested.

Please, let us know if the issues are being tackled or if we shouldn’t wait for fixes anytime too soon.

EDIT (1h later): the sluggish & intense CPU use might be an issue related to GitGutter extension.
It might be that it conflicts with the new/duplicated features from ST 3.2.
Still investigating bug give it a try and disable it, if you are having similar issues as me.

EDIT (3h later): GigGutter is not the responsible. The whole behaviour happens also when that plugin is disabled.

By the way, another thing I noticed is that in idle, SublimeText and WindowServer processes won’t consume CPU at all (1-5% each). But just focusing the ST window will raise the CPU usage for both of them, raising to something like 27% for WindowServer and 16% for Sublime.
Doing nothing, just because of the focus on the window.

EDIT: setting gpu_window_buffer to false seems to improve the CPU consumption in idle. Disabled, restarted Sublime, and now either SublimeText and WindowServer use 1/3 of the amount reported above :+1:t2:
Suggestion was for macOS 10.14.4, but it did good also on 10.14.3.

0 Likes
#38

NFS is sure great, but setting this up some work environments is often very hard.

0 Likes
#39

Yes; but I have the same environment and am working flawlessly with NFS since 4/5 years.

Sublime never had a problem with it before.
The new version changed something, because now it holds on mounted NFS (preventing to unmount the volume, if there is some file open) and tends to crash every time that the NFS folder loaded in the project is not available/mounted/reachable.

While before March 2019 (when I updated) non of these was a problem and Sublime was just keeping the open files as non saved buffers.

It’s not an issue from NFS.

0 Likes