There is a big project with many parent/children directories on a Linux machine. The Exuberant CTags are installed and the tags are created using ctags. Now, I am using Visual Studio Code on Windows to load that entire directory. I have installed the relevant ctags extenions, but I cannot go to definition of some of the functions in VScode (on the Linux machine the ctags work fine in vim).
My specific questions:
What is the best (easiest, most efficient) way to do this (navigate through some codes that are based in Linux from Windows)?
How can I use the ctags, that are generated on the Linux machine, on windows?
P.S.: I think I should add some directories to my windows path or include path ...
Related
In tutorial requirement is install vscode in windows and install Remote Development extension pack. Why not just install in wsl?
I've install vscode to wsl. When I run code in wsl I get message:
To use Visual Studio Code with the Windows Subsystem for Linux, please install Visual Studio Code in Windows and uninstall the Linux version in WSL. You can then use the `code` command in a WSL terminal just as you would in a normal command prompt.
Do you want to continue anyway? [y/N]
To no longer see this prompt, start Visual Studio Code with the environment variable DONT_PROMPT_WSL_INSTALL defined.
Which cons of run vscode in wsl as opposed to run it in Windows?
The WSL extension splits VS Code into a “client-server” architecture, with the client (the user interface) running on your Windows machine and the server (your code, Git, plugins, etc) running "remotely" in your WSL distribution.
When VS Code is started in WSL, no shell startup scripts are run.
The extension runs commands and other extensions directly in WSL so you can edit files located in WSL or the mounted Windows filesystem (for example /mnt/c) without worrying about pathing issues, binary compatibility, or other cross-OS challenges.
(source: MSFT DOCUMENTATION)
This is the architectural choice of Windows and - personally speaking - I feel like it's a choice to avoid conflicts and redundancies.
When running the WSL extension, selecting the 'Extensions' tab will display a list of extensions split between your local machine and your WSL distribution.
Installing a local extension, like a theme, only needs to be installed once.
Some extensions, like the Python extension or anything that handles things like linting or debugging, must be installed separately on each WSL distribution. VS Code will display a warning icon ⚠, along with a green "Install in WSL" button, if you have an extension locally installed that is not installed on your WSL distribution.
I currently use MINGW64 (Git Bash) as my terminal on my Windows 10 machine. It works great, I like it, but it only has Vim installed as an editor and I prefer Emacs. I'm unfortunately having a really awful time getting it to work in my terminal.
What's weirder still is that I have Emacs working in Cygwin64; but I don't like using that as my terminal. The most logical fix is simply that it Emacs to my Path ENV, however that doesn't seem to help (perhaps I'm doing that wrong?). I just get bash: emacs: command not found. I found a command to install it, using Pacman, however the Pacman command cannot be found either (which is weird because I thought that was installed by default with MINGW64.
Would love any and all help on this.
A couple of options:
Use Cygwin and the Cygwin emacs. Consider your Cygwin environment completely separate from Windows, so set your PATH from within the .bashrc, not within Windows. Launch emacs from the bash command-line.
Use the Emacs Windows binary distribution, but point to the utilities within Cygwin (there's an emacs package to help with this). Again, launch from the bash command line to inherit the bash environment within emacs.
Use the Windows Subsystem for Linux, with a Linux installation, and stick with emacs from there. You get the best of the Linux world, and access to the Windows directories and files as well.
My goto choice for MANY years was the Emacs Windows binary in conjunction with Cygwin. Once I started using the WSL, however, it just worked a lot better, in a clean Linux environment, and I could get terminal and GUI emacs (and other apps) running using the VcXsrv X Server. WSL has a version that directly supports X Windows, but I don't care for the windowing environment it uses, so I stick with VcXsrv.
I'm using wsl and it runs codes in vscode pretty fine and I have different libraries which I installed through pip and conda in wsl but when I run that code using vscode itself it doesn't recognize the libraries or even pip itself.
I don't have any other environment.
I should add that I installed the packages globally using conda install ... or pip install ... in base environment and I only have base environment and I run my code through code . and I also have python and remote wsl extensions installed in my vscode.
what can be the problem?
I don't have much personal experience with this, but I found some useful information in this Stack Overflow question (even though it doesn't utilize conda), along with https://code.visualstudio.com/docs/remote/wsl-tutorial#_python-development.
I also found this blog post useful, even if it doesn't cover WSL.
In short, make sure you:
Have installed the Python extension (by Microsoft) in VSCode. This is critical for being able to detect and select the Python interpreter. You don't mention having this in place, so I believe this is your likely problem.
You have done this already, but including it for others who might read this later -- Install the Remote - WSL extension (or the Remote Development extension pack) in VSCode.
You are also doing this already -- Start VSCode from inside your WSL distribution. Alternatively, you can start VSCode from Windows and then select the Remote WSL - Reopen Folder in WSL from the Command Palette (also accessible from the "Remote" Status Bar).
In VSCode, open the Command Palette with Shift+Ctrl+P, search for the Python: Select Interpreter command, and you should find your Conda environment in the list.
After selecting this, you should find that your project is using the interpreter and modules that you have installed via conda.
One thing I did to overcome this issue is go to Extensions -> Local (You should have two tabs there, Local and WSL:DISTRO) DISTRO refers to whatever DISTRO you're using, you will see that some of the local extensions are disabled in the current workspace (WSL) and there is a little cloud icon in the WSL:DISTRO tab that says install Local Extensions in WSL:DISTRO once you click that it will let you choose which extensions to install and you should be good to go!
If you have multiple developers w/ multiple developer workstations and they each have VS Code, how can I track what extensions that have from a central location? I don't want to have to sign on to each workstation one at a time and pull up VS Code for a list of installed extensions and versions. FOr example, there is a vulnerability in VS Code's TS-Lint extension. How can I tell what computers in my group have that installed?
Method 1: Query the File System
The Common Questions section of the page Managing Extensions in Visual Studio Code shows where extensions are installed:
Where are extensions installed?
Extensions are installed in a per user extensions folder. Depending on your platform, the location is in the following folder:
Windows: %USERPROFILE%\.vscode\extensions
macOS: ~/.vscode/extensions
Linux: ~/.vscode/extensions
The extensions directory contains one subdirectory for each installed extension, named like (extension)-(version). Listing its contents for each user and machine should provide a comprehensive list of installed extensions.
Method 2: Query VSCode Itself
Another approach is to use the VSCode command line as explained in the Command Line Extension Management of that same page. In particular, you can run:
$ ./bin/code --list-extensions --show-versions
from the VSCode install directory when logged in as a particular user to get a list of (extension)#(version) strings.
But note: you have to use the code program in the bin subdirectory of VSCode, which is a shell script (requiring Cygwin on Windows). On Windows at least, there is also Code.exe in the top-level VSCode directory, but that one does not respect those command line flags.
I use VS Code as my main code editor for my C++ development. I am using the remote SSH extension by Microsoft to access my office workstation from home. For the C++ autocompletion and linting I use the clangd extension by LLVM. Company policy prevents users from having sudo access to workstations and libraries are often not at the latest version.
When I try to launch clangd I get the following error message:
/lib64/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /my/path/to/clangd)
Which obviously means that the version of libstdc++ is too old for the version of clangd that I am using. This is easily fixable by adding to LD_LIBRARY_PATH the location of most recent gcc libraries (part of our compiler toolchain) and then launching VS Code.
However, now that I am working remotely I cannot do that because VS Code is installed onto my laptop and I am using the SSH extension to access the code on my office workstation. Looking on the man page for clangd I cannot see a way to specify the path to the libstdc++ that I want to use. Is there a way, other than adding the libraries to the LD_LIBRARY_PATH upon startup/login, to bypass this issue?
I found a way, albeit a little bit hacky.
Export the new LD_LIBRARY_PATH on .zprofile (or equivalent for your shell. I am using zsh). Make sure that there are no VSCode servers running in the host. If there are, make sure to remove them.
In the settings.json file add the following line, to tell VSCode that you want the shell to be a login, interactive shell:
"terminal.integrated.shellArgs.linux": ["-l", "-i"]
Job done. Clangd now finds the correct libraries.
Another way to do this is to use env in your settings.json as follows:
"clangd.path": "env",
"clangd.arguments": [
"LD_LIBRARY_PATH=<your_custom_path>",
"/path/to/my/clangd"
],