I have unsuccessfully been trying to install some plugins for VIM for sometime. I have mostly been following the information in this reference. I've basically just been dropping the plugin files in various directories hoping something works, nothing has yet. I have a .vim directory at the following path:
/Users/{my_user_name}/.vim
I have tried adding my files to the directory above as well as a directory inside it called plugins. Can anyone suggest what I might be doing wrong?
When I enter
:help 'rtp'
I get
Unix: "$HOME/.vim,
$VIM/vimfiles,
$VIMRUNTIME,
$VIM/vimfiles/after,
$HOME/.vim/after"
Amiga: "home:vimfiles,
$VIM/vimfiles,
$VIMRUNTIME,
$VIM/vimfiles/after,
home:vimfiles/after"
PC, OS/2: "$HOME/vimfiles,
$VIM/vimfiles,
$VIMRUNTIME,
$VIM/vimfiles/after,
$HOME/vimfiles/after"
Macintosh: "$VIM:vimfiles,
$VIMRUNTIME,
$VIM:vimfiles:after"
The correct location is in a plugin subdirectory (not the plural plugins):
/Users/{my_user_name}/.vim/plugin/*.vim
You can check your actually used path with
:set rtp?
The trailing ? means query value, don't set. (:help rtp is just the general documentation, not what's actually used.)
The useful :scriptnames command will tell you what actually got sourced.
Note that all these instructions are valid for plain *.vim plugin scripts; some plugins are also distributed as (*.zip, or *.tar.gz) archives, or the Vim-specific Vimball (*.vba, *.vmb), which typically contain the subdirectory structure already.
For an hypothetical single-file plugin:
~/.vim/plugin/plugin.vim
For an hypothetical multi-file plugin:
~/.vim/autoload/plugin.vim
~/.vim/plugin/plugin.vim
~/.vim/doc/plugin.txt
If that hypothetical multi-file plugin comes with documentation, run the following command to add it to the :help index:
:helptags ~/.vim/doc
The :scriptnames shows you a list of sourced scripts.
Also, most plugins have some kind of README that details recommended installation procedures: read it.
Related
So, I followed the instuctions in their website, there's a .vim/pack/themes/start path with the dracula folder there with everything and I add the three lines to the _vimrc (had to open as admin to be able to save changes) file in my FilesProgram/Vim folder
after that, two other files appeared, a ._vimrc.un~ and _vimrc~ and now when I try to open vim it gives the following error
Error detected while processing C:\Program Files (x86)\Vim\_vimrc:
line 41:
E919: Directory not found in 'packpath': "pack/*/opt/dracula"
line 43:
E185: Cannot find color scheme 'dracula'
Can anybody tell me where Is the mistake and how to fix it?
We have a cascade of mistakes, here.
The first one was made by the Dracula maintainers, who forgot not everyone uses the same system as them and therefore only provided instructions for "Unix"-like systems and not for Windows (and even those are incorrect anyway).
The second one was made by you, who blindly followed "Unix" instructions on Windows despite the many incompatibilities between those systems.
The third one was also made by you, who edited the system-wide C:\Program Files (x86)\Vim\_vimrc instead of your C:\Users\Edrods\_vimrc.
Follow these steps to fix your setup:
Create C:\Users\Edrods\vimfiles\.
This directory is where all your configuration is supposed to happen. Don't do anything Vim-related anywhere else.
Whenever you see ~/.vim/ mentioned in a tutorial or README.md, replace it mentally with C:\Users\Edrods\vimfiles\.
Create C:\Users\Edrods\vimfiles\vimrc.
This is your main configuration file.
Whenever you see vimrc, .vimrc, or _vimrc mentioned in a tutorial or README.md, replace it mentally with C:\Users\Edrods\vimfiles\vimrc.
Revert any change you may have performed in C:\Program Files (x86)\Vim\.
Whatever line you have added to C:\Program Files (x86)\Vim\_vimrc must be moved to C:\Users\Edrods\vimfiles\vimrc.
Whatever file or directory you may have added to C:\Program Files (x86)\Vim\ must be moved to C:\Users\Edrods\vimfiles\.
The goal is to return C:\Program Files (x86)\Vim\ to its pristine state and forget that directory even exists. It is off-limits.
Put the dracula directory where it belongs:
C:\Users\Edrods\vimfiles\pack\themes\start\dracula
Add these lines to your vimrc (remember what I said earlier about mentally replacing it with the correct path?) if they are not there already:
syntax enable
colorscheme dracula
(Optional) Tell the maintainers of that colorscheme to fix their installation instructions.
I am a beginner with Vim and I am trying to install Vundle for plugin management. However I keep getting the same error when I open gVim:
Error detected while processing C:\Users\jacob\Vim\_vimrc:
line 5:
E117: Unknown function: vundle#begin
line 7:
E492: Not an editor command: Plugin 'VundleVim/Vundle.vim'
line 9:
E117: Unknown function: vundle#end
I am working on windows 10 and this is how my _vimrc file looks like:
set nocompatible
filetype off
set rtp+=$HOME/.vim/bundle/Vundle.vim/
call vundle#begin('$HOME/.vim/bundle/')
Plugin 'VundleVim/Vundle.vim'
call vundle#end() " required
filetype plugin indent on " required
Perhaps a bit on the late side, but I also received the same error.
After diagnosing what has happened I came to the following problem and solution:
The problem is that using GIT to clone the files, this downloades the Vundle directory to the filepath: ~/vimfiles/bundle/Vundle.vim to the Windows home directory. the final filepath on Windows would then look like: C:\Users\User1~\vimfiles\bundle\Vundle.vim . However the _vimrc files is located under the directory C:\Users\User1\
The sollution is to copy the folder "vimfiles" to the user1 directory (exchange user1 for your own username). The final filepath for the Vundle files should then be C:\Users\User1\vimfiles\bundle\Vundle.vim .
Looks like you missed some steps of the installation, that would clone the Vundle git repository under the $HOME/.vim/bundle directory, creating a Vundle.vim subdirectory there which would have an autoload/vundle.vim which is where functions such as vundle#begin would be searched.
See the Quick Start guide for further instructions. In particular for your case, there's also a link to a quite detailed Windows setup document with many details on how to get the components you need to install Vundle.
You might also want to consider vim-plug as an alternative to Vundle. It's newer and actively maintained, while at the same time using a similar model to Vundle, supporting a similar set of commands and using similar configuration directives. It's also much easier to install, also on Windows. (It only needs a single file to be downloaded.)
I am trying to write a script that automates opatch, but before I get into the actual scripting I want to test the commands directly through the command prompt. My oracle home is C:\oracle\Middleware, and my patch 23094292 folder is located in the Middleware folder. Here are the commands I am using to apply the patch:
cd C:\oracle\Middleware\23094292
C:\oracle\Middleware\OPatch\opatch apply
When I run the latter command I get this:
ZOP-51: The patch location is not valid for apply, because it doesn't have correct metadata, or it points to a patch directory.
Argument(s) Error... Patch location is not valid for apply
Please check the arguments and try again.
OPatch failed with error code = 135
Shouldn't oracle home be the valid patch location? I am not too familiar with Oracle's product's, so I'm not certain. Please let me know if I can provide any further information. Any help explaining what I am doing wrong would be greatly appreciated.
You're missing a directory in the 23094292 directory. There should be two directories in there, "files" and "etc". And then there should be a "README.txt" file there as well.
Edit: I'd just suggest removing the 23094292 directory and unzipping the zip file again, or re-download it if that doesn't work.
After wasting some time to figure out what goes wrong, I finally have to ask for help. I want to use appledocs from Gentle Bytes. I followed every step of the quick install guide, but I´m not able to compile the project.
Here is what I´ve done:
1. cloned it from git://github.com/tomaz/appledoc.git
2. installed the templates to ~/Library/Application Support/appledoc
3. tried to compile the project
Everytime I try to compile, I get following error:
ERROR: AppledocException: At least one directory or file name path is required, use 'appledoc --help'
What do I have to do now?
Sounds like you've compiled it just fine and are now running the program. If it's a command-line program try command-option-R in Xcode to provide some arguments (i.e. names of files that you want to process).
The error means you didn't give it source paths: after all switches, you must give it at least one path to your source files. Can be either file or directory. In later case it will recursively scan the dir. Here's example
appledoc <options> ~/MyProject
Above example will use ~/MyProject directory as a source. You can also add multiple source paths. Note that you need to give the tool few options, see this page for minimum command line and other usage examples.
You either have to copy appledoc executable to one of directories in your path, as suggested by Caleb, or use full path to it when invoking (for example: /path/to/appledoc)
Can phpDocumentor be used to generate HTML docs for some legacy code that does not necessarily conform to its standard?
I'd like to generate some preliminary documentation for an old code tree and later on start improving my comments and add the appropriate # tags as I get fluent with phpDocumentor. I've never used this piece of software before and the examples I've found focus on how to write new code that conforms to its syntax and generate HTML file by file with the -f parameter.
I've installed latest phpDocumentor through the PEAR command line installer and tried this little *.bat file on Windows XP:
#echo off
phpdoc ^
--directory "\\server\project\trunk" ^
--target "C:\tests\project-doc"
... but this is all I get:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
directory: '' not found
I've also tried mapping the UNC path to a drive letter:
#echo off
phpdoc ^
--directory "I:\" ^
--target "C:\tests\project-doc"
... but:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
a target directory must be specified
try phpdoc -h
This error message is the same if I create "C:\tests\project-doc" before.
What's exactly wrong in my syntax?
phpDocumentor can indeed run against "undocumented" code. It builds its docs based on the code itself, and uses the docblocks as additional info (and additional organization, in the case of #package and #subpackage tags).
I'd suggest starting with phpDocumentor against your existing code, and work towards clearing out the warnings you see in the errors.html file that results -- this file is generated in the top level of your output docs, but there isn't any link to it from the output docs.
Once you have those cleared, you can start running phpDocumentor with the -ue argument (--undocumentedelements), which will add new warnings to errors.html, highlighting (in much greater detail) things that still need to be documented in docblocks.
Now, as for the issue you're having trying to run the program against code on a shared drive, I'm not sure what's wrong there. The script is clearly able to execute PHP and find the phpDocumentor code itself. You might try putting the arguments in the same line, rather than using the ^ as a line-feed escape character, and perhaps remove the quotes around the paths (since no spaces exist in the paths).
I think I've found what the issue is. The parameter parser is very picky and it doesn't like neither UNC paths nor bare root directories. If I replace this:
--directory "I:\"
... with this:
--directory "I:\."
... it finally starts running.
I suppose it's a bug. Their bug tracker doesn't seem to be public so I don't know if it's a known issue.