When using stock VS Code Version: 1.71.2 on macOS 12.6:
A file that is chmod 444 does not show the 'lock' icon and does not block edit actions.
vscode only reports that it is 'read-only' when one tries to write the file.
Q: is that intentional or a bug? or something new to macOS-12.6?
Q: Does vscode to the right thing on Windows or Linux?
(that is: show the 'lock' and block edit acions)
I've been told this is known and possibly intentional:
https://github.com/microsoft/vscode/issues/134876#issuecomment-940851828
On the other hand, I found that it is trivial to fix, and was likely an oversight/bug.
This (line 93; plus constructor arg) will fix the problem
https://github.com/jackpunt/vscode/commit/7639971f3d0467ec6c923b89bf189bdc653b9969
You can clone that repo to get that fix, and also all read-only goodies from https://github.com/microsoft/vscode/issues/161715#issuecomment-1262947768
(still [Nov 2022] waiting for the vscode owners to pull that...)
Related: https://github.com/microsoft/vscode/issues/17670
Related
I am rebuilding my comment highlighter in to a new extension.
However I now run now in to an issue where I get the following warning:
(node:4904) [DEP0005] DeprecationWarning:
Buffer() is deprecated due to security and usability issues.
Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
So far I can find in my extension I never use the function Buffer()
I think that it comes from the vscode module.
When the warning occurs block comment highlighting stops working.
This issue is breaking for my extension in development mode.
However my old extension has the same issue in development mode and released version.
Only in the released version doesn't report of the warning.
I am sorry for not including a minimal, reproducible example.
UPDATE:
In the latest release of my comment highlighter I have fixed block comment highlighting. At least I have fixed what was broken on my end.
The (node:4904) [DEP0005] DeprecationWarning keeps breaking my extension on rare occasions, this happens in all my environments.
Restarting vscode or rebooting the operating system can sometimes fix it. I have noticed that other extensions break as well when my extension is broken.
Operating systems I run:
Windows 10
Ubuntu 20 LTS
On both OSes I run nvm to manage node and npm versions.
I currently have 2 computers both dual booted with the named OSes
The issue occurs on both computers.
Here are the steps I used to help diagnose what is causing that Buffer deprecation warning.
Uninstall your extension. You may have to reload vscode after this.
Terminal: export NODE_OPTIONS=--throw-deprecation
Terminal: code-insiders --install-extension arturodent.find-and-transform
(or code --install-extension arturodent.find-and-transform if not on Insiders)
(replace with your extension id found in the package.json)
That should re-install the extension with a stack trace about the deprecation warning.
Obviously, if your extension directly used new Buffer() you can fix it.
If you imported/required an extension that uses new Buffer() you have a couple of options: look for an alternative, fork it or file an issue with that repository.
In my case, neither of the above was the issue. You can see that fd-slicer is the problem. And that is a dependency of yauzl. yauzl is used by vscode itself, not by me or by my extension's dependencies.
There are issues filed on fd-slicer (maintainer has no interest in fixing this, PR to fix) and on yauzl urging to switch to a forked fd-slicer2 which hasn't been merged yet (PR to fix - consider upvoting). And on vscode: buffer warning, yauzl.
My node version: v15.9.0
For me, this Buffer warning is currently an irritant only, and does not affect the functionality of my extension fortunately.
I encountered a somewhat similar incident while trying to create my first extension. So launching the Command Palette - Ctrl + Shift + P and selecting >Developer: Reload Window helped.
I hope you have been able to successfully overcome this issue as I have not seen many answers in online forums relating to this type of warning. VS Code is having trouble referencing your node module as you may have either and outdated version of node or double installation causing broken symlinks. This is usually fixed by uninstalling and reinstalling node using brew a couple of times then unlinking and relinking node once the broken symlinks are gone. The following video helps to explain just how to do this.
https://www.youtube.com/watch?v=DAnf4XUUjkg
After that simply restart your IDE and try launching VS code again! Hope this helps.
I opened VSCode and was presented with a notification that there was a conflict between two versions of a file. I followed the prompts and got a side-by-side comparison of two versions. I clicked the button that accepts the newer version, believing that VSCode had correctly inferred which version was newer. It had not, and I lost a significant number of changes to the file. Is there a cached copy of the other version anywhere?
Thank you!
ps - I seem to have failed to actually commit the changes in git as well. Not sure how that happened.
After searching through the VSCode appdata, I concluded that it wasn't likely that there was a copy. I found a copy of the bytecode (.pyc file) and used uncompyle6 to get an approximate copy of the version of the .py file I needed to recover. Was able to manually merge from there.
I was flummoxed by this one too. The answer is that you can restore the old version by hitting undo until before the change was made.
Why do I have the same suggestions while typing expression?
Example:
I had exactly the same problem. After a week or so, it get really annoying.
basically, as the comments hint to, there are probably multiple linting or intelisense tools. In my case (for python) i had the pylance extension added.
When i disabled this, the problem went away, but features were missing. So i added it back...
For some reason (i dont know why), this fixed the problem !!!
I can only hypothesise that in some way the extension was corrupted. Nevertheless, it worked.
EDIT:
I can also confirm that unchecking this setting appears to work:
Jupyter: Pylance Handles Notebooks
My current system is Windows 11, with python 3.10.
Final edit (8 Dec 2022):
This is resolved here:
Please could you install VS Code 1.74 and the latest Jupyter, PyLance and Python extension and confirm this still exists.
Visual Studio Code provides an API so third-party extensions and built-in modules can contribute suggestions for auto-completion pop-ups. The system is currently designed so suggestions are merely appended—there's no duplicate detection or removal (perhaps because extensions can also take care of sorting suggestions and such algorithm would get on the way). That means that if you have more than one extension or module for a given language you can easily get duplicate entries.
Having several extensions for PHP is not necessarily a bad idea since they can address different needs (for instance, PHP DocBlocker just creates annotations, it doesn't provide auto-completion suggestions) but you have at least two extensions (PHP Intelephense and PHP Intellisense) that do exactly the same things. That's likely to hurt performance (all your workspace files will be scanned several times) and just adds noise.
I suggest you read the extension descriptions carefully to learn what they do exactly and then figure out which ones you need. Remember that extensions can be enabled/disabled in a per-workspace basis.
The following is just my own totally subjective opinion. Among the PHP extensions that provide code intelligence only two of them seem mature enough:
PHP Intelephense
PHP Intellisense
I've tried both. PHP Intelephense works best for me than PHP Intellisense so that's the one I've kept. I've also disabled php.suggest.basic following the installation instructions because basic suggestions didn't add any value to me (they were blind string matching):
Turn off the php.suggest.basic setting for best results.
... as well as taming builtin Emmet support, which was providing really dumb suggestions:
"emmet.showExpandedAbbreviation": "inMarkupAndStylesheetFilesOnly"
YMMV.
TLDR; Installing pre-release version of Jupyter solves (v2022.11...)
Ok, so after some more extensive experimentation I think I found what's causing this in my case. After looking at the processes I noticed that there were two Pylance processes running, and consistently this would only be a problem if I was working in a session with a jupyter notebook open or one that had been opened.
saun89 17740 37.3 0.3 1008004 199492 ? Sl 20:58 0:22 /home/saun89/.vscode-server-insiders/bin/fef85ea792f6627c83024d1df726ca729d8c9cb3/node /home/saun89/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2022.11.32/dist/server.bundle.js --cancellationReceive=file:9178e897a2b78b36bfd167f79b36c3bdad2931d71b --node-ipc --clientProcessId=17651
saun89 18743 257 0.7 1304584 382288 ? Sl 20:59 0:20 /home/saun89/.vscode-server-insiders/bin/fef85ea792f6627c83024d1df726ca729d8c9cb3/node /home/saun89/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2022.11.32/dist/server.bundle.js --cancellationReceive=file:8744a321767eed92821fd737be4dc7dcfb728284e5 --node-ipc --clientProcessId=17651
Pylance basically spins up a service for the workspace, and then spins up a separate service for the notebook.
Output from "Python Language Server" logs:
Disabling Jupyter removes the duplication, and after installing an earlier version of the extension (v2022.4) this appears to have fully resolved the issue. I'm going to go ahead and log the extension bug once I have something reproducible.
As of 11/30/22, Jupyter Extension Pre-Release version v2022.11.1003281132 is the latest version fixes this issue. Click the gear icon next to the extension and you should see "install another version..." Then you can select version v2022.11.1003281132.
I'm doing some web development and I did a commit & sync via GitHub's Mac GUI, then I installed some Mac updates that required a restart (I don't know what the updates were). When I opened my project in PHPStorm again, I found this error when I tried compiling my TypeScript:
/usr/local/bin/tsc
env: node: No such file or directory
I know the compilation was working before. My web application had no issues. This question deals specifically with me being able to do this yesterday, with no changes to the FileWatcher configuration.
I have my TypeScript Compiler in usr/local/bin/tsc (which I have checked as a valid path to a typescript compiler alias). When I click on the alias, It opens a terminal window and runs typescript, so I know it's there. PHPStorm also complains if I try to change the file path, saying I must pick a valid executable.
I modified my Environment Variables on the advice of Dan Clark's site but that hasn't changed anything. I don't have the reputation to upload a photo of my File Watchers Dialog.
Does anyone know why I am getting this error, and how it can be fixed? I mention GitHub because that's the last thing I did before things stopped working: a commit & sync, then a restart to install some Mac updates.
Both which node and which tsc point in the right direction. Just tsc also works.
My solution was to use the directory of the actual TypeScript compiler at /usr/local/lib/node_modules/typescript/bin/tsc
instead of
/usr/local/bin/tsc, which is the alias.
That lets me compile using the FileWatcher.
As for why this happened, it's still a mystery to me.
All of the emacs users on our development server are unable to do a bazaar commit to our development branch on launchpad. They receive this message:
bzr: ERROR: Cannot lock /.. /.bzr/checkout/dirstate: [Errno 13] Permission denied: u'/../.bzr/checkout/dirstate'
I've double-checked all of the permissions and everyone has their keys set up correctly. I'm using vim and have no problems.
Any other ideas?
Thanks, Jen
This error does not look like it has anything to do with Launchpad's server side.
The error means bzr is failing to acquire a filesystem lock for the "checkout" part of the tree. The "checkout" in bzr represents the checked-out source files and associated metadata. It's what makes it possible to run "bzr st", "bzr add" and similar commands.
Since you describe the problem as emacs-specific, it might be something wrong with the emacs mode you are using for driving bzr. Is that VC, or DVC?
Generally, VC does not do what you would expect, because it's designed for centralized version control systems such as RCS, SCCS, CVS and Subversion. Make sure to investigate the use DVC instead.
The way you phrase it, you suggest that all developers are working on the same branch on a shared development server. That's a pretty unusual way to use a distributed version control, you should check that the .bzr/checkout directory has the appropriate permissions. For you that would be something like rwxrwtr-x. Note the setgid bit on directory.
The best place to get such problems resolved is the #bazaar channel on irc.freenode.net. Diagnosing and solving such problems often requires a number of roundtrips, and IRC is a more appropriate medium than stackoverflow.
Look for a .lock file of some kind. Sometimes they don't get cleaned up after a crash and the resource stays locked. Maybe the Emacs plugin for bazaar created it and thats why vim doesn't care.
I'm with ddaa on this. It is almost certianly an issue with the emacs mode they are using to do their checkouts. Presumably they have no problem using the command-line interface to bzr, right?
The source code for the modes in usually found under the Emacs installation directory in either the lisp or site-lisp subdirectories. However, it is written in a special elisp language, so it is tough reading if you don't know elisp (or at least lisp in general). But if you post exactly what mode they are using, what version, and perhaps what version of emacs, there may be some folks reading who can enlighten you about known problems and whatnot.