I'm trying to switch over my current setup for Neovim (using Vim Plug) to Packer and I'm having trouble.
My Neovim is loaded from ~/.config/nvim/init.lua which sources all of my plugin and other settings. They live mostly inside of a ~/lua folder (the "main Imports") section of my configuration, including my actual plug-plugins.lua file that references all of my plugins.
-- Main Imports
require("settings")
require("colors")
require("mappings")
require("functions")
require("autocommands")
require("plug-plugins")
...
Later in the same init.lua file, I'm sourcing plugin specific settings for all of these plugins. In order to get my directory working currently, I'm installing everything with :PlugInstall and it works fine.
...
-- Plugin-specific settings
require("plugin-settings/fzf")
require("plugin-settings/fugitive")
require("plugin-settings/ultisnips")
require("plugin-settings/coc")
require("plugin-settings/treesitter")
require("plugin-settings/miscellaneous")
require("plugin-settings/toggle-terminal")
Installing Packer
The installation steps for Packer are pretty sparse, and merely state that you should clone the repository to somewhere in your "packpath" but I'm not really clear what that means. When I'm inside Neovim, and I press :set packpath? I get the following paths:
packpath=~/.config/nvim,/etc/xdg/nvim,~/.local/share/nvim/site,/usr/local/share/nvim/site,/usr/share/nvim/site,/usr/local/Cellar/neovim/HEAD-b74916c_1/share/nvim/runtime,/usr/local/Cel
lar/neovim/HEAD-b74916c_1/lib/nvim,/usr/share/nvim/site/after,/usr/local/share/nvim/site/after,~/.local/share/nvim/site/after,/etc/xdg/nvim/after,~/.config/nvim/after
This makes me think that I'm able to just clone the respository to ~/.config/nvim which is the first path listed. I'm not really sure what to do next though, or if this is even right.
Can anyone help? What are the basic steps to getting Packer installed (I'm on MacOS 11.6).
i did recently moved from vim-plug to packer, as per docs when you do git clone of the repo the path provided in readme for installation is ~/.local/share/nvim/site/pack/packer.After successful clone you can start using packer in your plugins.lua as below.
return require('packer').startup(function()
use 'wbthomason/packer.nvim'
end)
you can check the installation by running :PackerSync this will fetch (git clone) the plugin in to the packerpath which is ~/.local/share/nvim/site/pack/packer
Hope this is what you looking for?
I had the exact same situation and it turned out to just be a naming conflict. I had named my local nvim config file lua/packer.lua and changing that fixed the issue.
Related
We want to have the same VSCode settings for the whole crew of developers. Also it would be fine to have a oneline command to tear VSCode down and restart it from scratch with predefined settings and plugins so that you do not have to worry about trying out plugins and getting beck to the known state. Kind of Config-as-Code for VSCode.
I already found:
https://code.visualstudio.com/docs/editor/extension-gallery#_command-line-extension-management
https://github.com/microsoft/vscode-dev-containers
https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync&ssr=false#qna
https://github.com/gantsign/ansible-role-visual-studio-code-extensions
https://code.visualstudio.com/docs/remote/containers
https://github.com/gantsign/ansible-role-visual-studio-code
But non of these provides a good solution to me
We are using Mac and Windows machines and develop most of the time locally (not remotely in the cloud or the like).
I imagine like having a script like
.... projectname up
or
.... projectname reset
(or
.... projectname down)
to receive/reset the configured settings and newest plugins that have been configured for the project.
Have any ideas or use a similar solution already?
After doing a lot of research, playing with Docker, Ansible and so on... it seems that although I excluded it at first the plugin Settings Sync Plugin from Shan Khan is the way to go. It has round about 1 million installs!
Only dependency - you need a GitHub account to host your configs. That is what held me back at first - but it should be not that much of a problem to get one for everyone in the team and connect it to like a company-github-account.
Copy the files settings.json and keybindings.json to your target machine(s) to copy the settings. You can find those files here:
Win: ~\AppData\Roaming\Code\User
Mac: ~/Library/Application Support/Code/User/
Linux: ~/.config/Code/User
You can copy extentions from ~/.vscode/extensions or C:\Users\username\.vscode\extensions from linux/mac or windows respectively.
FalcoGer's answer should explain how to copy the files in a way VS Code will pick them up. If you only need to copy the config files once, this solution would be fine.
If you need to "sync" these config files on a regular basis, I would advise to create a Git repository where all config files will be stored.
When cloning the repo to local machines, you can symlink the files to the config destinations (see FalcoGer's anwser). Then when you need to "sync", you only have to run git pull and restart VS Code to apply the changes.
For your other script-related question, you could create a CLI for this. Python would be the most friendly way to do this. You can find an example here.
I'm interested in ORB-SLAM2, So I searched and found this site
https://github.com/Phylliida/orbslam-windows <<
so I read the README file and copied it, but I found these errors.
enter image description here
I already installed OPENCV on windows and I set up the environment variables well.
How can I fix errors?
Try setting OpenCV_DIR in CMakeLists.txt
SET("OpenCV_DIR" "C:/opencv")
If you want an automated installation, build setup for ORB-SALM2, we have it in this repo, scripts\windows\bootstrap.batbuilds opencv and dependencies using vcpkg and build.bat compiles ORB-SLAM2. Bootstrap usually takes time for first time!!
1.Adding the variable to the system path like this.
2.Setting the variable by the cmake-gui.Then reconfigure.
3.Setting the include and lib path about opencv in the CMakeLists.txt manually.
My question is, how should my Erlang app reliably find a binary in the priv directory, not just in production; when installed properly, but during common test?
I realised today when I added a travis-ci configuration to an old Erlang app and pushed it to git-hub, that the process by which it works locally for me, is a little more fragile than I thought. The travis-ci build failed because it, not unreasonably, checked out my repo into a directory named after the repo, which is of the form erlang-APP. Locally my app is in a directory called APP-VSN though.
The result of this is that a call to code:lib_dir(APP) returns a correct result during the common test run locally, but if I rename my current directory to erlang-APP instead of APP-VSN (or just APP works too) my local build fails, just like it does for travis-ci, because code:lib_dir(APP) returns {error,bad_name}. The behaviour as though .. is added to the library path for rebar ct.
Renaming my github repo from erlang-APP to APP resolves the travis-ci build failure... but knowing the build tests only pass depending on the name of the directory the repo is checked out into doesn't sit right with me.
One way could be to use a soft link (either in the repo under version control, or created when initializing the tests), and make your Erlang code path go via the link. E.g., "./APP" -> ".", or "./lib/APP" -> "..".
I have cloned my office colleague's zend2 project from our server. He used zfcuser, zfcbase, and zfcadmin. But when I tried to run the project in my local machine its giving
<b>Fatal error</b>: Uncaught exception 'Zend\ModuleManager\Exception\RuntimeException'
with message 'Module (ZfcBase) could not be initialized.' in C:\xampp\htdocs\coolshop
\vendor\ZF2\library\Zend\ModuleManager\ModuleManager.php:140
Everything is fine to me as the same project 100% working in my colleague's machine. I tried the composer as well. But no luck
This is a result of loading the ZfcBase module as a git submodule. If you fix this module you'll receive the same error for other modules or dependencies you're using in that manner. I've encountered this problem when someone tries to clone the project on a new machine or you delete the project locally and try to re-clone it.
The simple answer here is to use composer as your dependency manager, you'll have a better day. Head over to ZfcBase on Packagist and copy the require statement into your composer.json file (You'll need to run the composer script after saving your .json file). Most modules should have instructions on using composer to grab them in the README.
I should note that if you're using other modules that depend on ZfcBase, you'll likely just need to have a require statement for those, and not their dependencies (like ZfcBase).
Someone had a similar question regarding the ZfcUser module. Using composer solved his issue.
I have a problem with many vim commands that come from plugins. They don't within an empty buffer.
For example :Gstatus from fugitive plugin doesn't work when in a new tab/buffer.
The strangest thing though is that initially, just after running vim, it works. i.e. if I just run vim and type :Gstatus it will work. but if before that I do :newtab or :enew it will not work.
The difference that I see that the first open buffer seems to be in a [Rails] mode, and the new ones are not.
These commands work on files and/or directories. When doing :tabnew you don't open a file or a directory. Since fugitive is only a (nice) wrapper around git, doing :Gstatus is like doing $ git status in your "Pictures" folder: it's not a git repository so git does nothing.
You could try to :cd to an actual git repository and do :Gstatus there.