Actually, I find myself doing this quite frequently - maybe not always in the same directory, but I’m often connected to a server through SSH in a terminal Window and SSHFS for Sublime, and I don’t have rsub/rmate installed, so if I need to make a super-quick change to a file (especially if it’s root-owned) I’ll use vim, but if I’m doing big edits or other work I’ll track down the file through Finder and edit it with Sublime.
Just saying, this may not be just a corner case.
It might be more common than I thought in the real world, but in my work environment most people will use one or the other, but not both. In your case I can understand with the limitations due to permissions and file ownership. Just curious do you view the file in sublime and then switch to VI to make a quick change?
The error is only thrown when you have the file (or a file in the directory) open in sublime and then you make changes through VI to the file or a file in the same directory. Other than that I don’t see the error being thrown.
Either way I hope we (as a community) can figure out a solution either as part of sublime or some short of plugin to notify us that the error has been thrown so we can restart sublime.
Well I thought everything was working fine until I compiled my code. The compiler resides on the linux server and that throws the ReadDirectoryChangesW error as well.
@jps last year, right after the new syntax thing, a bug appeared and even if i reported at that moment, wasn’t fixed. Can you please take a look at that, is killing me!
Thanks!
It will be nice, if the panels display always as a tabs (like in other editors)
The “php” snippet is defined in the file Packages/PHP/Snippets/php.sublime-snippet.
Overriding works fine for me if I create this file in Data/....
Hmmm… In data… where?
Here is how I tested (with portable version; installed version have the very same issue):
Desktop\sublime3
php.sublime-snippet from the Desktop\sublime3\Packages\PHP.sublime-package archive into Desktop\sublime3\Data\Packages\PHP;content;The desired behavior would be to override the default snippet, and use only that instead of showing a popup…
Thx for the release.
If you are using a theme that does not support the new Panel Switcher it is pretty easy to patch in support for it. Just see my commit here I created for support in the awesome Gravity Theme:
There is no php.sublime-snippet file in PHP.sublime-package, is what I’m trying to tell. Maybe your portable build is outdated or something and you need to run it once before extracting the file again, I’m on 3101 and there is no such file in either installed or portable ST3.
The file is actually named Snippets/php.sublime-snippet, which is why you can’t override it if you save it as Desktop\sublime3\Data\Packages\PHP\php.sublime-snippet. It has to be Desktop\sublime3\Data\Packages\PHP\Snippets\php.sublime-snippet.
Related commit on github:
Apparently this error is ERROR_BAD_NET_RESP “The specified server cannot perform the requested operation”
Generally speaking, any file notification API I’ve used doesn’t work across network shares and the like (eg. a mapped SharePoint drive). In this situation Sublime Text should probably be falling back to polling instead of using ReadDirectoryChangesW.
I think this is what Jon tried to do with this latest release but once the error occurs polling fails and the notification system stops working as well. This could be something at the OS level such as Windows serving up a cached version of the file once the error occurs. I have not tested, just speculating.
Ahh. I see. Looks like I misread the release notes.
Also speculating here, as I’m not actually Windows user. But having helped maintain a cross-platform file system notification library, I can certainly appreciate how difficult it is to get this stuff right.
@jps Thanks for another stellar dev build.
One minor annoyance is that every update seems to rewrite the User Preferences.sublime-settings.
To work around this, I’ve decided to put my config in .git so I can easily revert. So it’s not a huge problem for me anymore, but certainly not great in terms of usability.
Btw, I’m really looking forward to what plugin developers build with the new panel APIs. Cheers.
Sublime Build 3101, OS X 10.11.3
I certainly agree. I’m forced to implement changes for multiple clients on a daily basis. Often times they contradict each other and I must find the common ground that will make both clients happy but still provide a consistent and fluid user experience for all users.
Software development is no easy task. I can only imagine making so many developers happy with new functionality and bug fixes is a huge undertaking for Jon. My hat goes off to you @jps. I can only imagine what your daily workload is like. I am only dealing with 15 or 20 clients all making requests and I am pulling my hair out. I cannot imagine handling the load you get with Sublime. I think I speak for the masses when I say that your efforts are certainly appreciated.
That’s right - polling won’t happen for any directory that we’ve successfully received change notifications for. I’ll change it to be more pessimistic about the probability of continuing to see change notifications.
Updates don’t rewrite User Preferences, but any automatic changes, either from the UI (e.g., adding a word to the dictionary) or from the API (e.g., a plugin calling Settings.set() on the User Preferences) will cause them to be rewritten.
One work around here is to place your hand edited Preferences.sublime-settings file in a separate package (ZUser perhaps). This way the file will never be programmatically modified.
This may or may not be triggert by an update specificaly, but most certainly it will be triggered by every plugin changing your user preferences with the sublime.save_settings API since that will dump the settings in lexicographical order (object keys and list items) and also remove comments, since they are not stored when parsed.
This is part of a bigger problem, also tracked here: https://github.com/SublimeTextIssues/Core/issues/426
Oh dear! Yes, you’re right. I missed this part!
Now it works, thanks!
(the package wasn’t outdated, but I simply ignored that folder… don’t ask why!)