i just installed YouCompleteMe for Vim through vundle. It works, but it shows only the words contained in the current file. I want to use it to develop c++ programs, how can i configure it to show autocompletion from c++ headers file in /usr/include for example? Thanks a lot.
You need to navigate to ~/.vim/bundles/YouCompleteMe and run the installation script with --clang-completer, so do ./install.sh --clang-completer. After it finishes you should have support for C like languages.
You may also need to place let g:ycm_global_ycm_extra_conf = '~/.vim/bundle/YouCompleteMe/cpp/ycm/.ycm_extra_conf.py' in your ~/.vimrc.
I have installed with pathogen. I tried the above instructions with ./install.sh --clang-complete. After this, it did not work, and I indeed had to add the path. But it was different than in another reply here, namely
let g:ycm_global_ycm_extra_conf = '.vim/bundle/YouCompleteMe/third_party/ycmd/cpp/ycm/.ycm_extra_conf.py'
so there is an extra "third_party/ycmd" in the path.
While the suggestions here might work in the beginning, I am not sure it's the proper way to go. According to YCM developer, whenever you start a project, you need a new .ycm_extra_conf.py file
From https://valloric.github.io/YouCompleteMe/#ubuntu-linux-x64-super-quick-installation
YCM looks for a .ycm_extra_conf.py file in the directory of the opened file or in any directory above it in the hierarchy (recursively); when the file is found, it is loaded (only once!) as a Python module. YCM calls a FlagsForFile method in that module which should provide it with the information necessary to compile the current file. You can also provide a path to a global .ycm_extra_conf.py file, which will be used as a fallback. To prevent the execution of malicious code from a file you didn't write YCM will ask you once per .ycm_extra_conf.py if it is safe to load. This can be disabled and you can white-/blacklist files. See the Options section for more details.
While you might only need to modify the compile flags from the vanilla .ycm_extra_conf.py, I feel it is advisable to create a new file for every project you start.
Everything that the folks here have said is correct. I just want to add that as of 2017, the "install.sh" script is deprecated. Now, you have to use the install.py script instead by typing
./install.py --clang-completer
Also, in your .vimrc file, instead of ".vim/bundle/blahblahblah", you'll need to add a "~/" in front of the address by adding:
let g:ycm_global_ycm_extra_conf = "~/.vim/bundle/YouCompleteMe/third_party/ycmd/cpp/ycm/.ycm_extra_conf.py"
to your .vimrc file, to give it an absolute path from the Home directory so that Vim can find the ".ycm_extra_conf.py" file. Otherwise, you might experience some funny behavior.
I just wanted to add if you don't want to manually define a config file there is this neat little repository that will auto generate it. https://github.com/rdnetto/YCM-Generator
Related
I'm currently Studying Computer enginering and taking embeded systems class, My isuse is that we use a custom library then compile it in a old version of Codewarrior.
how I would go about creating an include path for my lsp with nvim
I was woundering how I would go about creating an include path for my lsp with nvim, when I am not compiling the code localy but later compiling it with an old IDE
any wisdom would be apreciated.
note: in class we are required to use an exterior editor and the older version of code warrior is verry bad it is used for compiling for our micro controler but is unusable for writting code.
things I have done
I have atempted using compile_commands.json by coppying my vscode config for path location
I have tryed using a .clangd file with -I ...
I have tried other method but had no sucess so far
over all I was hopping to find a solution and have poured over the getting started page and stack overflow for several hours trying diffrent method to no avail.
The easiest approach is probably to use a .clangd file. Based on the path in your comment, the .clangd file should look like this:
CompileFlags:
Add: -I/home/bjc1269/Documents/github/libraries/lib/hc12c/include
A few things that I'm seeing in the .clangd file in your comment that don't work are:
Variable substitutions like ${workspaceFolder}. This is a VSCode feature that works in some VSCode settings like "clangd.arguments", but is not supported in a .clangd file, which is editor-agnostic (for example, it works with editors that don't have a concept of a "workspace").
Referring to your home directory as ~. Expanding ~ to /home/<username> is a feature of your shell. Command-line arguments specified in .clangd are passed directly to the compiler without being processed by the shell, so ~ will not work.
Globs like **. To be honest, I'm not even sure what the intended semantics for this could be in the context of specifying include directories.
Square brackets inside the argument to -I. Square brackets may appear in a .clangd file as YAML syntax for specifying multiple values in a list, for example you might have:
CompileFlags:
Add: [-I/path/to/directory1, -I/path/to/directory2]
But if you write -I=[/path/to/directory], the brackets just get passed on verbatim to the compiler, which does not understand this syntax.
First of all: Welcome to stackoverflow! :D
I'd recommend to use bear for this. You just simply invoke it with your build-command and the clangd LSP will read the includes automatically.
Ok, n00b question. I have a cpp file. I can build and run it in the terminal. I can build and run it using clang++ in VSCode.
Then I add gtest to it. I can compile in the terminal with g++ -std=c++0x $FILENAME -lgtest -lgtest_main -pthread and then run, and the tests work.
I install the C++ TestMate extension in VSCode. Everything I see on the internet implies it should just work. But my test explorer is empty and I don't see any test indicators in the code window.
I've obviously missed something extremely basic. Please help!
Executables should be placed inside the out or build folder of your workspace. Or one can modify the testMate.cpp.test.executables config.
I'd say, never assume something will "just work".
You'll still have to read the manual and figure out what are the names of config properties. I won't provide exact examples, because even though I've only used this extension for a short time, its name, and therefore full properties path, has already changed, so any example might get obsolete quite fast.
The general idea is: this extension monitors some files/folders, when they change, it assumes those are executables created using either gtest or catch2. The extension tries to run them with standard (for those frameworks) flags to obtain a list of test suites and test cases. If it succeeds, it will parse the output and create a nice list in the side panel. Markers in the code are also dependent on the exactly same parsed output, so if you have one, you have the other as well.
From the above, you need 3 things to make this work:
Provide correct path (or a glob pattern) for finding all test executables (while ignoring all non-test executables) in the extension config. There are different ways to do this, depending on the complexity of your setup, they are all in the documentation though.
Do not modify the output of the test executable. For example, if you happen to print something to stdout/stderr before gtest implementation parses and processes its standard flags, extension will fail to parse the output of ./your_test_binary --gtest-list_tests.
If your test executable needs additional setup to run correctly (env vars, cwd), make sure, that you use the "advanced" configuration for the extension and you configure those properties accordingly.
To troubleshoot #2 and #3 you can turn on debug logging for the extension (again, in the VSCode's config json), this will cause an additional "Output" tab/category to be created, where you can see, which files were considered, which were run, what was the output, and what caused this exact file to be ignored.
This messed with me for a while, I did as Mate059 answered above and it didn't work.
Later on I found out that the reason it didn't work was because I was using a Linux terminal inside windows (enabled from the features section) and I previously had installed the G++ compiler using the linux terminal so the compiler was turning my code into a .out file, for some reason TestMate could not read .out files.
Once I compiled the C++ source file using the powershell terminal it created a .exe file which I then changed the path in the setting.json as Mate059 said and it showed up.
TL;DR
Mate059 gave a great answer, go into settings.json inside your .vscode folder and modify "testMate.cpp.test.executables": "filename.exe".
For me it also worked using the wildcard * instead of filename.exe but I do not suggest to do that as in that might mess up something with the .exe from the main cpp file and what not.
I have a script library stored in .../lib/ that I want to embed into my program. So far, that sounds simple: On Windows, I'd use Windows Resource Files - on MacOS, I'd put them into a Resource folder and use the proper API to access the current bundle and it's resources. On plain Linux, I am not too sure how to do it... But, I want to be cross-platform anyway.
Now, I know that there are tools like IncBin (https://github.com/graphitemaster/incbin) and alike, but they are best used for single files. What I have, however, might even require some kind of file system abstraction.
So here is the few guesses and estimates I did. I'd like to know if there is possibly a better solution - or others, in general.
Create a Zip file and use MiniZ in order to read it's contents off a char array. Basically, running the zip file through IncBin and passing it as a buffer to MiniZ to let me work on that.
Use an abstracted FS layer like PhysicsFS or TTVFS and add the possibility to work off a Zip file or any other kind of archive.
Are there other solutions? Thanks!
I had this same issue, and I solved it by locating the library relative to argv[0]. But that only works if you invoke the program by its absolute path -- i.e., not via $PATH in the shell. So I invoke my program by a one-line script in ~/bin, or any other directory that's in your search path:
exec /wherever/bin/program "$#"
When the program is run, argv[0] is set to "/wherever/bin/program", and it knows to look in "/wherever/lib" for the related scripts.
Of course if you're installing directly into standard locations, you can rely on the standard directory structure, such as /usr/local/bin/program for the executable and /etc/program for related scripts & config files. The technique above is just when you want to be able to install a whole bundle in an arbitrary place.
EDIT: If you don't want the one-line shell script, you can also say:
alias program=/wherever/bin/program
I'm editing a repository that doesn't use Prettier, but my editor (Emacs) loads prettier-js-mode based on file extension. So when saving a file I get a bunch of whitespace changes that I can't commit as it would polute the upstream repository.
My idea so far is to add a local .prettierrc file that disables Prettier, then add it to my .git/config/exclude file so upstream doesn't have to know about it.
But how do I craft such a file?
In my case I'd like to have a file in the project's root directory that would disable Prettier for the whole project, but I can also see how others might wish for a way to do the same thing for a subdirectory.
What about adding the .prettierignore with a * in it?
prettier-js-mode should have a config to only enable itself when it finds prettier config in the root or in package.json. The same as vscode and atom plugins do. If it doesn't have this feature it would be nice to open an issue or a PR.
The accepted answer is kinda hacky, but sure it will work too.
I'm new to deploying programs written in C/C++ on Linux and I'm wondering what you'd do in this situation.
I have a binary file (compiled with GNU Make) that needs to read a config file (such as myprogram.conf). But when I write a Makefile to deploy this file to /usr/bin/, where should the config file go? And how does the executable know where it is?
You have endless options, but the best way depends on a couple of things. First, is it a user-specific configuration file, or is it global to all users?
If it's user specific, you could, for example, keep it in ~/.myprogram/config.file and have the program check there. As a service to your users, it's up to you to decide what to do if it's not found -- perhaps copy a default config there from somewhere else, or generate a default, or use hard-coded default options, or display a configuration wizard, or just fail. That's entirely up to you.
If it's global, the traditional place to put it on Linux is in /etc, e.g. /etc/config.file or /etc/myprogram/config.file. See Linux File System Structure. You will generally always have a /etc on Linux. Handling a situation where the file does not exist is the same as above - there's no "right" way to handle that, it's based purely on how convenient you want to make it for a user.
What I usually do for global config files is put them in /etc/wherever on install, have the program default to loading the config file from /etc/wherever, but also give a command line option to override the configuration file (especially useful for testing or other situations).
What I usually do to handle missing config files depends entirely on the application. I'll generally either have hard-coded defaults (if that's appropriate) or simply fail and direct the user to some documentation describing a config file (which I find adequate in situations where my installer installs a config file).
Hope that helps.
It kind of depends on what the configuration parameters are, and whether they are "per system" or "per user" or "per group" or ...
System configurations typically live somewhere in /etc/.... In the same directory that the program lives is a very good place too.
User confgiurations, in the home directory of the user.
Group configurations are the trickiest, as you'll probably need to come up with a scheme where there is a configuration file per "group". /etc/myprog/groups/<groupname>/config or something similar would work.
On Linux, the usual location for configuration files is '/etc', so it is acceptable to deploy a configuration file like /etc/myprog.conf. That requires root privileges however. Other good options include putting a configuration file in the user's home directory, making it something like ~/.myprog.conf or ~/.myprog/.conf to use a folder where you can have several config files, a cache or something else that you want.
As for how the executable knows where the file is, one solution is to look for the file in several common locations. For example, if you decided to place your config in the user's home directory, look for it there first, if not found, look under /etc. And allow a special command line argument that would let a different config file to be loaded. So, say, an invocation of myprog can check for a config file in the home folder, but myprog -c /some/path/config will use /some/path/config as the file. It's also a good idea to have some default settings that you can fall back to if there is no valid config file anywhere.
The config file can go anywhere, but I'd try to put it in the same directory as any other files the program will read or write.
As for how the executable will find it, I'd pass the config file's path to the executable on the command line as an argument, with a default value of "." (which is the current directory, the one you're in when you launch the executable).