Im currently running:
✗ nvim -v
NVIM v0.3.0
I use plug.vim to load plugins, and I like to keep plugin configs in separate files instead of having everything in init.vim:
✗ pwd
/Users/mwaldner/.vim/plugin
✗ ls
ale.vim fzf_config.vim strip_whitespace.vim
commentary_config.vim reload_files.vim vim-go.vim
I've moved to a new laptop, and installed the latest version of neovim. It seems like the plugins folder is no longer autoloaded like they are in regular vim. I've had to manually source all my configs file which isn't a big deal, but just curious why that changed.
What folders get autoloaded in neovim?
Thanks!
See this related thread, most importantly :help runtimepath.
Summary: Vim provides a transparent directory schema that is defined by when you want things to load. For example, autoload/ contains scripts you source before anything else and whose functions you can use in your .vimrc, and ftplugin/ is dedicated for filetype-specific configurations.
Related
Question:
Is there a way to install a downloaded NBM (Netbeans Module) into an already installed Netbeans IDE via CLI?
Current setup
Netbeans 12.3 with Windows 10
Netbeans 12.3 with Linux Mint 20.1
Relevant scenario
If the question comes to your mind 'why aren't you just using the GUI?' or anything like that. Think of the following scenario. When working on an air gapped network with 50 computers you're the one having to install Netbeans plugins on all of that PCs. You're able to put files on those PCs and execute a command via console and you don't want to run around all the buildings and clicking through the process.
Thank you very much in advance.
I think I found a solution. I'll post it here to reflect my research because I've never found a answer on stackoverflow.
When Netbeans is already installed you can use the --help parameter like:
C:\Program Files\NetBeans\netbeans\bin\netbeans64.exe --help
This lists lot of available parameters (which I haven't found a list of on the web) like (shortened):
General options:
--help show this help
--jdkhome <path> path to JDK
--console new open new console for output
Module reload options:
--reload /path/to/module.jar install or reinstall a module JAR file
Additional module options:
--modules
--refresh Refresh all catalogs
--list Prints the list of all modules, their versions and enablement status
--install <arg1>...<argN> Installs provided JAR files as modules
--disable <arg1>...<argN> Disable modules for specified codebase names
--enable <arg1>...<argN> Enable modules for specified codebase names
--update <arg1>...<argN> Updates all or specified modules
--update-all Updates all modules
Core options:
--fontsize <size> set the base font size of the user interface, in points
--userdir <path> use specified directory to store user settings
--nosplash do not show the splash screen
In my case the solution was to use the --install parameter pointing to the jar file to install.Be aware that the NBM files are just containers containing the jar file and some more meta data files like config xml files. You're able to open it via 7zip for example. And you'll have to take care of all the dependencies yourself.
I've cloned it but I didn't find any .exe file, Nor do i see it in programs list in Control Panel of windows. I'am a bit confused as to what cloning means. I know that there is direct download .exe file on vim.org website. Its for sure that I'am beginner for all these. Please help. Thanks for the help in advance.
reading the "installation" section found in the README.md of the vim repo, you can see the filenames containing the instructions that will help you with the installation, depending on your OS.
README_ami.txt Amiga
README_unix.txt Unix
README_dos.txt MS-DOS and MS-Windows
README_mac.txt Macintosh
README_haiku.txt Haiku
README_vms.txt VMS
So, for the full information I suggest you go to those files, or go to the vim website where there is also good information about the installation.
Anyway, I will briefly explain below the information that those files and the vim website say for most common operating systems
If you're on Unix:
git clone https://github.com/vim/vim.git
cd vim/src
make
If you're on Mac
The Macintosh binaries are not on the Vim ftp site. They are produced by a few Macintosh lovers. Often they lag behind a few versions.
MacVim has more a Mac look and feel, is developed actively and most people prefer this version. Most of MacVim was made by Björn Winckler.
MacVim can be downloaded here: link
Or if you prefer, here is the MacVim homepage.
If you're on Windows:
The next instructions were copied from here.
Option A: Using the self-installing .exe
Go to vim.org/download.php and click on self-installing executable (or just click here) and follow the prompts.
Watch out for:
When an existing installation is detected, you are offered to first remove
this. The uninstall program is then started while the install program waits
for it to complete. Sometimes the windows overlap each other, which can be
confusing. Be sure the complete the uninstalling before continuing the
installation. Watch the taskbar for uninstall windows.
When selecting a directory to install Vim, use the same place where other
versions are located. This makes it easier to find your _vimrc file. For
example "C:\Program Files\vim" or "D:\vim". A name ending in "vim" is
preferred.
After selecting the directory where to install Vim, clicking on "Next" will
start the installation.
Option B: Using .zip files
Go to the directory where you want to put the Vim files. Examples:
cd C:\
cd D:\editors
If you already have a "vim" directory, go to the directory in which it is
located. Check the $VIM setting to see where it points to:
set VIM
For example, if you have
C:\vim\vim82
do
cd C:\
Binary and runtime Vim archives are normally unpacked in the same location,
on top of each other.
Unpack the zip archives. This will create a new directory "vim\vim82",
in which all the distributed Vim files are placed. Since the directory
name includes the version number, it is unlikely that you overwrite
existing files.
Examples:
pkunzip -d gvim82.zip
unzip vim82w32.zip
You need to unpack the runtime archive and at least one of the binary
archives. When using more than one binary version, be careful not to
overwrite one version with the other, the names of the executables
"vim.exe" and "gvim.exe" are the same.
After you unpacked the files, you can still move the whole directory tree
to another location. That is where they will stay, the install program
won't move or copy the runtime files.
Change to the new directory:
cd vim\vim82
Run the "install.exe" program. It will ask you a number of questions about
how you would like to have your Vim setup. Among these are:
You can tell it to write a "_vimrc" file with your preferences in the
parent directory.
It can also install an "Edit with Vim" entry in the Windows Explorer
popup menu.
You can have it create batch files, so that you can run Vim from the
console or in a shell. You can select one of the directories in your
$PATH. If you skip this, you can add Vim to the search path manually:
The simplest is to add a line to your autoexec.bat. Examples:
set path=%path%;C:\vim\vim82
set path=%path%;D:\editors\vim\vim82
Create entries for Vim on the desktop and in the Start menu.
That's it!
Vim is open source software, and its source code, i.e. all the technical files that make up Vim is (nowadays) hosted at GitHub.
Cloning that repository means you'll download all of those files to your computer (and with Git as the underlying revision control system, you'll even get the full history of all changes ever done). As Vim supports a very big set of very diverse platforms (Windows, Linux, Mac, ...), the repository itself does not (and should not) contain pre-built binaries, nor a full installer that most users expect to run. So, unless you have the intention to actively contribute to Vim by submitting bug fixes or enhancements, you don't need to clone or do anything with GitHub. If you do want to get technical, src/INSTALLpc.txt contains the instructions for building Vim on Windows. This includes choosing a compiler, installing it and the required dependencies, configuring the build, building, and then finally copying the files to a permanent location on your PC, either manually or by building and then running an installer.
For plain passive consumption of Vim (which is rewarding in itself, but may even lead you to eventually also programming it), the Downloading Vim page on vim.org has all the information that you need, with links to the most popular installers right at the top.
a word on versions
For a casual user, using the latest stable version is recommended; this is 8.2 right now; gvim82.exe is a corresponding installer for Windows. This offers the best compromise between stability and latest features. In the case of Vim, expect a new release roughly every year.
You'll also find development builds (something like 8.2.0740); these usually function as well and have the very latest features under development, but often are less stable. I would use these only if you really need a leading-edge feature, or want to report a bug. You should then probably update very frequently, and from there it's only a small step to actually cloning the repository and building everything on your own!
I've recently started using the Eclipse IDE for web development.
In the past when I've used Scout to complie my Sass.
Is there a way in Eclispe to automatically compile my Sass.
Is this the best option - http://www.only10types.com/2012/02/get-eclipse-to-automatically-compile.html
I've tried this but I get a BUILD FAILED becuase of
<apply dest="css" executable="/var/lib/gems/1.9.1/bin/sass">
I realise that executable needs to point to sass on my system but how do I find where sass is on my system?
I posted about this recently here: http://mikekelly.myblog.arts.ac.uk/2015/02/09/sass-with-eclipse-in-os-x/
My post refers to OS X but it should be easy enough to adapt the process to other setups.
Here's the text from my post:
Preparation
1. Make sure Ruby is installed. You’re going to need this as SASS is a ruby app. OS X should have Ruby installed by default. To check, open a terminal window and enter:
ruby -v
This should display the version information, something like:
ruby 2.0.0p481 (2014-05-08 revision 45883) [universal.x86_64-darwin14]
If you don’t have Ruby, install it now. Come back once you’ve figured it out.
If you develop using Ruby at times, you are likely to be using RVM to manage different Ruby versions. If you’re using RVM we need to take some precautions. Don’t worry – we don’t need to get rid of RVM. We just need to make sure we install SASS to the system version of Ruby.
Let’s check to see if we have RVM installed:
rvm -v
If we get version information back, then we have RVM. (If we don’t we can just move on to step 2 below.) Let’s see which versions of Ruby we have installed:
rvm list
This should show you a list of Ruby versions, along with info. about which one is the default and which is the current version. We want to install SASS to the OS X default version of Ruby, not the RVM-installed versions, so enter this:
rvm use system
And now check again on our current Ruby version:
ruby -v
OK, if we’re happy that we have Ruby and that we’re using the OS X default Ruby, let’s proceed.
2. Install SASS
Do we have SASS?
sass -v
If that doesn’t return version information, you will need to install SASS:
gem install sass
If you get permission errors, use sudo:
sudo gem install sass
Once you have installed SASS, let’s check on its location:
which sass
That should return:
/usr/bin/sass
If a different path was returned, look again at the information above about RVM.
OK, now that we have SASS installed in the OS X default version of Ruby, we can now switch back to a different version of Ruby via RVM, if required.
Set up a Builder in your Eclipse project
In Eclipse, we’re going to use a Builder to set up SASS auto-compilation.
Ctrl-click on the title of your project in the Explorer view (I’m working on a PHP project in this case, so I’m using the PHP Explorer view.)
Select Properties.
Click on Builders, then on New… to make a new Builder.
Select the Program option and click OK.
Now we can give our Builder a name, e.g. sass.compiler
In the Main tab we need to put in the path to the installed sass application:
/usr/bin/sass
N.B. If you were using SASS with an RVM-installed Ruby, at this point you might have tried putting in something like:
/Users/myusername/.rvm/gems/ruby-2.1.5/bin/sass
However that gives problems as SASS then tries to find required resources but they're not in the path, and so the operation fails with the error:
sass env: ruby_executable_hooks: No such file or director
Hence the need to install SASS into the OS X default version of Ruby.
Now we need to pass the appropriate arguments to SASS, so that it knows what to do and what files to do it with. If we were running SASS from the command line, we would probably do something like this at the start of our development session:
sass --watch sourcefolder:destinationfolder
In a real project that might look something like this:
sass --watch app/sass:public/stylesheets
This is a one-off command which forces compilation of any scss files in app/sass, into css files in public/stylesheets, whenever changes are made to the scss files. However, we want our Builder to trigger the compile process each time we save our scss files, so --watch is inappropriate.
If we enter:
sass --help
we discover that the option we want is --update. Luckily this works just like --watch in that it checks the designated folder recursively – so if we have many folders with scss files, we just specify a common parent folder.
You may have some scss files which you want to include into other scss files, and should not be compiled into their own css files. If that is the case, rename those files with an underscore at the beginning, e.g. rename mixins.scss to _mixins.scss Sass will still recognise those files for inclusion, but won’t compile css equivalents.
In my Arguments field I have this:
--update ${workspace_loc:/project1/htdocs/theme}:${workspace_loc:/project1/htdocs/theme} --sourcemap=none --style compressed
In my case, the scss files are in the same folder as the compiled css files, so my source folder and destination folder are the same. I used the Browse Workspace button in one of the form fields to generate the ${workspace_loc} placeholder values for my source folders and destination folders.
I also added a few more SASS options – one to turn off the generation of .map files, the other to output css in a compressed style.
Under the Build Options tab I have Allocate Console and During auto builds ticked, but nothing else.
Click on OK to finish.
Now, when I edit one of the scss files in my project1/htdocs/theme folder, in the Eclipse console view I see that SASS is doing its work, compiling the scss into css. Success!
Alternative method
Use Webstorm ; )
An easy solution would be to use Eclipse Wild Web Developer:
https://github.com/eclipse/wildwebdeveloper#-get-it-now
The editor will simplify developing with web technologies. Besides automatically compiling SCSS files to CSS files it provides many more features. Check them out, I think you will like them.
I often come across the following popular emacs builds:
graphene
prelude
emacs-live
Currently I'm running a custom configuration, but I'd like to experiment with these builds without clobbering my current ~/.emacs.d.
Here's some background on my current installation:
I installed Emacs via Homebrew, so it's located here: /usr/local/Cellar/emacs/HEAD/Emacs.app
My current version of emacs is:
GNU Emacs 24.3.50.1 (i386-apple-darwin13.0.0, NS apple-appkit-1265.00)
Basically, here's what I'd like to know:
What's the easiest way to switch between these builds as well as my current custom configuration?
Given my current setup, is it possible to start multiple emacs sessions, each with their respective configuration/buffers?
(Edit: I've wrapped this approach up into a shell script which I've added to the EmacsWiki.)
I'd be inclined to use the $HOME environment variable:
Firstly copy the 'distribution' (for want of a better term) into a sub-directory .emacs.d of a directory which will serve as the replacement $HOME for that distribution. i.e. /path/to/(distribution)/.emacs.d:
$ git clone https://github.com/bbatsov/prelude.git ~/emacs/prelude/.emacs.d
$ git clone https://github.com/overtone/emacs-live.git ~/emacs/emacs-live/.emacs.d
Then you can start emacs using env to set the HOME environment variable locally for that command:
$ env HOME=$HOME/emacs/prelude emacs
$ env HOME=$HOME/emacs/emacs-live emacs
They shouldn't interact with each other, so you can run them together and have multiple side-by-side emacs instances, each using a different configuration.
I see that graphene is actually an ELPA package, so it has no init.el file and needs to be installed via the package manager; but you can still use the same technique to install it in a separate clean configuration: Simply make a similar directory structure to the others, then create an init.el file (e.g. ~/emacs/graphene/.emacs.d/init.el) containing the code from the graphene installation instructions, then run emacs (e.g. env HOME=$HOME/emacs/graphene emacs), and finish the remainder of the installation instructions.
The down-side to this technique is that Emacs won't see all your other dot files (because it will be looking in $HOME), and so running other processes from within Emacs won't necessarily work as normal; but that's not likely to be a huge issue if you're just experimenting, and you can always symlink or copy the bits you need.
You may even prefer it that way -- the benefit is that if anything in the distribution you're trialing writes files to the home directory, it's not going to clobber your real files.
This may also be a useful approach when upgrading Emacs to a new release (if you can run both the old and the new versions side by side) as you could set up a copy of your existing config to use with the new Emacs until you're convinced everything is working, and you can edit the new config without the risk of breaking your existing one. Or flip that around, and instead keep the original config in the new/alternate location, in case you need it as a back-up.
You can symlink ~/.emacs.d, this is what I do
1) Try to keep my emacs configuration ~/.emacs.d oriented i.e. all the config files should live in that folder. For example I use workgroups2, by default it stores workgroup configuration in ~/.emacs_workgroups but I have configured it to store configuration in ~/.emacs.d/workgroups, so my entire emacs configuration is in just one folder.
2) Then I have an ~/emacs_configs folder where all config folders (basically a folder with a init.el and rest of the configuration) live, so my personal config folder will be ~/emacs_configs/iqbal, a prelude distribution will be in ~/emacs_configs/prelude
3) Then finally I symlink ~/.emacs.d to the configuration I actually want to use, eg. to use my configuration I will do ln -s ~/emacs_configs/iqbal .emacs.d. If you want to tryout some configuration just copy the configuration folder to ~/emacs_configs/whatever_name and change the symlink
Hope this helps
I create ~/.emacs.1.d/init.el file , and give it content:
(setq user-emacs-directory "~/.emacs.1.d/")
then , start emacs like this emacs -q -l ~/.emacs.1.d/init.el , now emacs used new configration.
success!!
-q is means skip the default configration ~/.emacs.d/init.el
-l is means load new configration
You can do this with chemacs2. This is the primary (only?) usecase of chemacs2.
I often come across the following popular emacs builds:
graphene
prelude
emacs-live
Currently I'm running a custom configuration, but I'd like to experiment with these builds without clobbering my current ~/.emacs.d.
Here's some background on my current installation:
I installed Emacs via Homebrew, so it's located here: /usr/local/Cellar/emacs/HEAD/Emacs.app
My current version of emacs is:
GNU Emacs 24.3.50.1 (i386-apple-darwin13.0.0, NS apple-appkit-1265.00)
Basically, here's what I'd like to know:
What's the easiest way to switch between these builds as well as my current custom configuration?
Given my current setup, is it possible to start multiple emacs sessions, each with their respective configuration/buffers?
(Edit: I've wrapped this approach up into a shell script which I've added to the EmacsWiki.)
I'd be inclined to use the $HOME environment variable:
Firstly copy the 'distribution' (for want of a better term) into a sub-directory .emacs.d of a directory which will serve as the replacement $HOME for that distribution. i.e. /path/to/(distribution)/.emacs.d:
$ git clone https://github.com/bbatsov/prelude.git ~/emacs/prelude/.emacs.d
$ git clone https://github.com/overtone/emacs-live.git ~/emacs/emacs-live/.emacs.d
Then you can start emacs using env to set the HOME environment variable locally for that command:
$ env HOME=$HOME/emacs/prelude emacs
$ env HOME=$HOME/emacs/emacs-live emacs
They shouldn't interact with each other, so you can run them together and have multiple side-by-side emacs instances, each using a different configuration.
I see that graphene is actually an ELPA package, so it has no init.el file and needs to be installed via the package manager; but you can still use the same technique to install it in a separate clean configuration: Simply make a similar directory structure to the others, then create an init.el file (e.g. ~/emacs/graphene/.emacs.d/init.el) containing the code from the graphene installation instructions, then run emacs (e.g. env HOME=$HOME/emacs/graphene emacs), and finish the remainder of the installation instructions.
The down-side to this technique is that Emacs won't see all your other dot files (because it will be looking in $HOME), and so running other processes from within Emacs won't necessarily work as normal; but that's not likely to be a huge issue if you're just experimenting, and you can always symlink or copy the bits you need.
You may even prefer it that way -- the benefit is that if anything in the distribution you're trialing writes files to the home directory, it's not going to clobber your real files.
This may also be a useful approach when upgrading Emacs to a new release (if you can run both the old and the new versions side by side) as you could set up a copy of your existing config to use with the new Emacs until you're convinced everything is working, and you can edit the new config without the risk of breaking your existing one. Or flip that around, and instead keep the original config in the new/alternate location, in case you need it as a back-up.
You can symlink ~/.emacs.d, this is what I do
1) Try to keep my emacs configuration ~/.emacs.d oriented i.e. all the config files should live in that folder. For example I use workgroups2, by default it stores workgroup configuration in ~/.emacs_workgroups but I have configured it to store configuration in ~/.emacs.d/workgroups, so my entire emacs configuration is in just one folder.
2) Then I have an ~/emacs_configs folder where all config folders (basically a folder with a init.el and rest of the configuration) live, so my personal config folder will be ~/emacs_configs/iqbal, a prelude distribution will be in ~/emacs_configs/prelude
3) Then finally I symlink ~/.emacs.d to the configuration I actually want to use, eg. to use my configuration I will do ln -s ~/emacs_configs/iqbal .emacs.d. If you want to tryout some configuration just copy the configuration folder to ~/emacs_configs/whatever_name and change the symlink
Hope this helps
I create ~/.emacs.1.d/init.el file , and give it content:
(setq user-emacs-directory "~/.emacs.1.d/")
then , start emacs like this emacs -q -l ~/.emacs.1.d/init.el , now emacs used new configration.
success!!
-q is means skip the default configration ~/.emacs.d/init.el
-l is means load new configration
You can do this with chemacs2. This is the primary (only?) usecase of chemacs2.