viktor/dot_files
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Adding new stuff

Browse source
This commit is contained in:
Viktor Barzin 2017-10-08 12:00:02 +01:00
parent 39ee792ad4
commit a410da0e04
722 changed files with 331 additions and 189 deletions
Download patch file Download diff file Expand all files Collapse all files

24
vim-plugins/bundle/eclim/doc/vim/c/complete.txt Normal file
View file

@ -0,0 +1,24 @@
*vim-c-complete.html*
C/C++ Code Completion
*********************
C/C++ code completion uses the standard Vim code completion mechanism
(vim-code_completion) like so:
>
#include <st<C-X><C-U>
#include <stio.h>
int main(void) {
pu<C-X><C-U>
puts(
puts("Hello World");
return EX<C-X><C-U>
return EXIT_SUCCESS;
}
<
vim:ft=eclimhelp

30
vim-plugins/bundle/eclim/doc/vim/c/index.txt Normal file
View file

@ -0,0 +1,30 @@
*vim-c-index.html*
C/C++
*****
Features
========
- C/C++ Project Configuration (vim-c-project)
- C/C++ Code Completion (vim-c-complete)
- C/C++ Validation (vim-c-validate)
- C/C++ Search (vim-c-search)
- C/C++ Code Inspection (vim-c-inspection)
Suggested Mappings
==================
Here are some mappings for the c/c++ funtionality provided by eclim.
To make use of these mappings, simply create a ftplugin file for c/cpp
and place your mappings there (:help ftplugin-name).
- The following mapping allows you to simply hit <enter> on an
element to perform a search to find it.
>
nnoremap <silent> <buffer> <cr> :CSearchContext<cr>
<
vim:ft=eclimhelp

59
vim-plugins/bundle/eclim/doc/vim/c/inspection.txt Normal file
View file

@ -0,0 +1,59 @@
*vim-c-inspection.html*
*:CCallHierarchy*
C/C++ Code Inspection
*********************
Call Hierarchy
==============
When viewing a c or c++ source file you can view the call hierarchy of
a function or method by issuing the command :CCallHierarchy. This
will open a temporary buffer with an inversed tree view of the
hierarchy of callers of the requested function or method.
>
fun2(int)
fun1(int)
main()
fun3(int)
fun3(int)
<
While you are in the hierarchy tree buffer, you can jump to the call
under the cursor using one of the following key bindings:
- <cr> - open the type using the (default action).
- E - open the type via :edit
- S - open the type via :split
- T - open the type via :tabnew
- ? - view help buffer
:CCallHierarchy can also be used to view the callees for a function or
method by invoking the command with a !:
>
:CCallHierarchy!
<
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimCCallHierarchyDefaultAction*
- g:EclimCCallHierarchyDefaultAction (defaults to 'split') -
Determines the command used to open the file when hitting <enter> on
an entry in the hierarchy buffer.
vim:ft=eclimhelp

62
vim-plugins/bundle/eclim/doc/vim/c/project.txt Normal file
View file

@ -0,0 +1,62 @@
*vim-c-project.html*
*:CProjectConfigs*
C/C++ Project Configuration
***************************
The eclipse cdt provides a large set of configuration support for your
c/c++ projects. Eclim exposes a subset of these to you using the
:CProjectConfigs command:
>
:CProjectConfigs
" or if you are outside of the project
:CProjectConfigs my_c_project
<
This command will open a temporary buffer displaying some of the cdt
configuration values available to you. In this buffer you can add or
remove source directory references, include path references, and
symbols.
Here is a small example of what the contents may look like:
>
Config: Linux GCC
Sources: |add|
dir: src
Tool: GCC C Compiler
Includes: |add|
path: "${workspace_loc:/my_c_project/includes}"
Symbols: |add|
Tool: GCC Assembler
Includes: |add|
<
To add a source directory, include path, or symbol, simply move the
cursor over the relevant "|add|" link and hit <enter>. You will then
be prompted to enter an appropriate value. For your convenience, tab
completion is provided where possible.
Note: Despite the odd looking value in the includes path section
above, to add the entry you simply need to supply the project
relative path, "includes/" in this case, when prompted by the add
command.
If at any point you would like to remove a value, you can move the
cursor over the line of the value you would like to remove and hit D
(shift-d) to delete the entry.
vim:ft=eclimhelp

131
vim-plugins/bundle/eclim/doc/vim/c/search.txt Normal file
View file

@ -0,0 +1,131 @@
*vim-c-search.html*
C/C++ Search
************
*:CSearch*
Pattern Search
==============
Pattern searching provides a means to widen a search beyond a single
element. A pattern search can be executed using the command
:CSearch -p <pattern> [-t <type> -s <scope> -x <context> -i -a
<action>]
When there is more than 1 result, those results will be placed into
vim's quickfix list (:help quickfix) so that you can easily navigate
them using vim's quickfix commands.
Vim command completion is supported through out the command with the
exception of the pattern to search for.
>
:CSearch <Tab>
:CSearch -p MyClass* <Tab>
:CSearch -p MyClass* -t <Tab>
:CSearch -p MyClass* -t class <Tab>
:CSearch -p MyClass* -t class -s <Tab>
:CSearch -p MyClass* -t class -s project
:CSearch -p MyClass* -t class -s project <Tab>
:CSearch -p MyClass* -t class -s project -x <Tab>
:CSearch -p MyClass* -t class -s project -x declarations
<
- -p <pattern>: The pattern to search for.
Ex.
>
MyClass
myFunction
my*
<
- -t <type> (Default: all): The type of element to search for where
possible types include
- class_struct
- function
- variable
- union
- method
- field
- enum
- enumerator
- namespace
- typedef
- macro
- -s <scope> (Default: all): The scope of the search where possible
scope values include
- all - Search the whole workspace.
- project - Search the current project, dependent projects, and
include paths.
- -x <context> (Default: declarations): The context of the search,
where possible context values include
- all - Search for declarations and references.
- declarations - Search for declarations only.
- references - Search for all references.
- -i: Ignore case when searching.
- -a: The vim command to use to open the result (edit, split,
vsplit, etc).
Element Search
==============
Element searching allows you to place the cursor over just about any
element in a source file (method call, class name, constant) and
perform a search for that element. Performing an element search is
the same as performing a pattern search with the exception that you do
not specify the -p option since the element under the cursor will be
searched for instead.
If only one result is found and that result is in the current source
file, the cursor will be moved to the element found. Otherwise, on
single result matches, the value of |g:EclimCSearchSingleResult| will
be consulted for the action to take. If there are multiple results,
the quickfix list will be opened with the list of results.
*:CSearchContext*
As a convenience eclim also provides the command :CSearchContext. This
command accepts only the optional -a argument described above, and
will perform the appropriate search depending on the context of the
element under the cursor.
- If the cursor is on an #include name, it will search the
configured include path for the file.
- Otherwise, it will search for the definition of the element (if
the cursor is on the definition, then it will search for the
declaration).
Configuration
=============
Vim Settings (vim-settings)
*g:EclimCSearchSingleResult*
- g:EclimCSearchSingleResult (Default: 'split') - Determines what
action to take when a only a single result is found.
Possible values include:
- 'split' - open the result in a new window via "split".
- 'edit' - open the result in the current window.
- 'tabnew' - open the result in a new tab.
This setting overrides the global default for all supported language
types which can be set using the g:EclimDefaultFileOpenAction
setting which accepts the same possible values.
- g:EclimQuickFixOpen (Default: 'botright copen') Specifies the
command used to open the quickfix window when multiple results are
found.
- g:EclimQuickFixHeight (Default: 10) - Sets the height, in lines,
of the quickfix window when eclim opens it to display search
results.
vim:ft=eclimhelp

48
vim-plugins/bundle/eclim/doc/vim/c/validate.txt Normal file
View file

@ -0,0 +1,48 @@
*vim-c-validate.html*
*:Validate_c*
C/C++ Validation
****************
When saving a c/c++ source file that resides in a project, eclim will
update that source file in Eclipse and will report any validation
errors found. Any errors will be placed in the current window's
location list (:help location-list) and the corresponding lines in the
source file will be marked via Vim's :sign functionality with '>>'
markers in the left margin.
Automatic validation of c/c++ source files can be disabled via the
g:EclimCValidate variable (described below). If you choose to disable
automatic validation, you can still use the :Validate command to
manually validate the current file.
Configuration
=============
Vim Settings (vim-settings)
*g:EclimCValidate*
- g:EclimCValidate (Default: 1) - If set to 0, disables source code
validation.
Note: When enabled, syntastic
(https://github.com/scrooloose/syntastic) is disabled so that
eclim and syntastic don't step on each other. If you'd like to use
syntastic over eclim for validation, then simply disable eclim's
validation.If you'd like to disable eclim's source code validation
for all languages, eclim provides a global variable for that as
well:>
let g:EclimFileTypeValidate = 0
<
- g:EclimValidateSortResults (Default: 'occurrence') - If set to
'severity', the validation results will be sorted by severity
(errors > warnings > info > etc.)
vim:ft=eclimhelp

127
vim-plugins/bundle/eclim/doc/vim/code_completion.txt Normal file
View file

@ -0,0 +1,127 @@
*vim-code_completion.html*
Code Completion
***************
Usage
=====
All the code completion functionality provided by eclim (ant, java,
etc) makes use of the new "User Defined Completion" added to Vim 7.
To initiate code completion enter insert mode and type Ctrl-X Ctrl-U.
By default Vim will open a popup if there is more than one completion.
*g:EclimCompletionMethod*
Note: If you would prefer to have eclim use vim's omni code
completion instead, you can add the following to your vimrc:>
let g:EclimCompletionMethod = 'omnifunc'
<
When using omnifunc you will use Ctrl-X Ctrl-O to start code
completion.
Example with java completion
[image]
Once you have started the completion you can use Ctrl-N to proceed to
the next match and Ctrl-P to move to the previous match.
To find out more about Vim's insert completion execute the following
from within Vim:
>
:h ins-completion
<
Third Party Completion Plugins
==============================
If you are like me and you find the above key strokes a bit
cumbersome, then you might want to check out one of the following
plugins which can make completion usage less cumbersome:
- SuperTab (https://github.com/ervandew/supertab): This plugin's aim
is to allow you to use <tab> for all your code completion needs.
By default supertab will use vim's keyword completion on <tab>, so
you probably want to at least add the following setting to your
vimrc:
>
let g:SuperTabDefaultCompletionType = 'context'
<
That will tell supertab to use keyword completion unless you are
attempting to access a member of an object or class, in which case
it will use your user completion method, such as eclim.
- AutoComplPop (https://bitbucket.org/ns9tks/vim-autocomplpop): This
plugin will automatically open the completion popup for you after
you've typed a preconfigured number of characters.
AutoComplPop by default only supports triggering code completion for
file types who have an omni completion that ships with vim, but you
can configure it to support eclim code completion. Here is an
example of some vim script you can add to your vimrc to enabled
AutoComlPop for java file types (this example will trigger the
completion popup when at least 3 characters have been typed after a
dot, but you can tweak this to your tastes):
>
let g:acp_behaviorJavaEclimLength = 3
function MeetsForJavaEclim(context)
return g:acp_behaviorJavaEclimLength >= 0 &&
\ a:context =~ '\k\.\k\{' . g:acp_behaviorJavaEclimLength . ',}$'
endfunction
let g:acp_behavior = {
\ 'java': [{
\ 'command': "\<c-x>\<c-u>",
\ 'completefunc' : 'eclim#java#complete#CodeComplete',
\ 'meets' : 'MeetsForJavaEclim',
\ }]
\ }
<
- neocomplcache (https://github.com/Shougo/neocomplcache.vim):
Another completion plugin which will automatically open the
completion popup for you as you type. Configuring neocomplecache is
a bit easier than AutoComplPop. You just need to tell eclim to
register its completion to vim's omni complete, then force
neocomplcache to use it. Here is an example for forcing the use of
eclim's code completion for the java file type when you attempt to
access an object/class member:
>
let g:EclimCompletionMethod = 'omnifunc'
if !exists('g:neocomplcache_force_omni_patterns')
let g:neocomplcache_force_omni_patterns = {}
endif
let g:neocomplcache_force_omni_patterns.java = '\k\.\k*'
<
- YouCompleteMe (https://github.com/Valloric/YouCompleteMe): Yet
another completion plugin which will automatically open the
completion popup for you and which also adds fuzzy matching of
completion results. This plugin does have a compiled component to it
so be sure to read their install docs thoroughly.
Once installed, the only required configuration you should need is
the following which tells eclim to register its completion to vim's
omni complete which YouCompleteMe will automatically detect and use:
>
let g:EclimCompletionMethod = 'omnifunc'
<
vim:ft=eclimhelp

172
vim-plugins/bundle/eclim/doc/vim/core/eclim.txt Normal file
View file

@ -0,0 +1,172 @@
*vim-core-eclim.html*
Eclim Manage / Config
*********************
Below is a list of the core commands and configuration for eclim
inside of vim.
Commands
========
*:PingEclim*
- :PingEclim - Pings eclimd to see if it is up and running.
*:ShutdownEclim*
- :ShutdownEclim - Shuts down the current running eclimd instance.
*:VimSettings*
- :VimSettings - Allows you to view and edit all of eclim's vim
client settings. Settings edited here will be stored at
$HOME/.eclim/.eclim_settings.
Note: If you have any g:EclimXXX settings in your vimrc or
equivalent, those will take precedence over any settings edited
using :VimSettings.
*:WorkspaceSettings*
- :WorkspaceSettings - Allows you to view / edit the global
workspace settings (vim-settings). For project level settings see
the |:ProjectSettings| command on the project documentation page
(vim-core-project).
*:EclimDisable*
- :EclimDisable - Allows you to temporarily disable all
communication with eclimd for the current vim session. Useful if
you need to shutdown eclimd for one reason or antoher, and would
like to disable vim's attempts to communicate with the non-existant
server.
*:EclimEnable*
- :EclimEnable - Re-enables communication with eclimd (the converse
of :EclimDisable).
*:EclimHelp*
- :EclimHelp [<topic>] - Similar to vim's :help command, with the
exception that this command is limited to opening topics for eclim.
*:EclimHelpGrep*
- :EclimHelpGrep /<pattern>/ - Command which allows you to search
the eclim help files via vimgrep.
Ex.
>
:EclimHelpGrep /completion/
<
Configuration
=============
Eclim Settings (vim-settings)
*org.eclim.user.name*
- org.eclim.user.name Should be set to your name. Used by various
commands that add contact or author information to a file.
*org.eclim.user.email*
- org.eclim.user.email Should be set to the email address where you
can be contacted. Used by various commands that add contact or
author information to a file.
*org.eclim.project.version*
- org.eclim.project.version Should be set to the version number of
your project. This is used by various commands that add version
info to a file or utilize the version number in some other manner.
Defaults to "1.0".
Vim Settings (vim-settings)
The following is a list of some of the common Vim variables available.
*g:EclimLogLevel*
- g:EclimLogLevel (Default: 'info')
This variable allows you to control the level of output from eclim
as follows:
- 'trace' - Show all trace, debug, info, warning, and error
messages.
- 'debug' - Show all debug, info, warning, and error messages.
- 'info' - Show all info, warning, and error messages.
- 'warning' - Show only warning, and error messages.
- 'error' - Show only error messages.
- 'off' - Don't display any messages.
Each level also has a corresponding variable to set the highlighting
group used for the text.
*g:EclimHighlightError*
- g:EclimHighlightError (Default: "Error")
*g:EclimHighlightWarning*
- g:EclimHighlightWarning (Default: "WarningMsg")
*g:EclimHighlightInfo*
- g:EclimHighlightInfo (Default: "Statement")
*g:EclimHighlightDebug*
- g:EclimHighlightDebug (Default: "Normal")
*g:EclimHighlightTrace*
- g:EclimHighlightTrace (Default: "Normal")
*g:EclimSignLevel*
- g:EclimSignLevel (Default: 'info')
Behaves just like g:EclimLogLevel except this applies to placing of
Vim signs for displaying validation errors / warnings, or marking
quickfix/location list entries.
The resulting signs also use the same highlighting variables above.
*g:EclimBrowser*
- g:EclimBrowser (Default: Dependent on OS)
Configures the external web browser to use when opening urls. By
default eclim will attempt to set a default browser based on your
system, but if it cannot find a compatible browser, you will need to
set one in your vimrc.
- Firefox let g:EclimBrowser = 'firefox'
- Mozilla let g:EclimBrowser = 'mozilla'
- Opera let g:EclimBrowser = 'opera'
- IE let g:EclimBrowser = 'iexplore'
Note: The above examples assume that the browser executable is in
your path. On windows machines they won't be by default, so you will
need to add them.
*g:EclimShowCurrentError*
- g:EclimShowCurrentError (Default: 1)
This variable determines whether or not a CursorHold autocommand is
created that will echo the error associated with the current line if
any error exists. Setting this variable to 0 disables this feature.
*g:EclimMakeLCD*
- g:EclimMakeLCD (Default: 1)
When set to a non-0 value, all eclim based make commands (:Ant,
:Maven, :Mvn, etc) will change to the current file's project root
before executing.
Enabling this has the benefit of allowing you to run these commands
from any file regardless of where it was opened from without having
to worry about the directory it is executing from. For example if
you have a file open from project A and split a file from project B,
you can execute :Ant from the project B file and it will utilize
project B's build.xml even though your current working directory is
in project A.
*g:EclimMenus*
- g:EclimMenus (Default: 1)
When set to a non-0 value, enabled auto generation of gvim menus
(under Plugin.eclim) for each eclim command available for the
current buffer.
*g:EclimPromptListStartIndex*
- ** g:EclimPromptListStartIndex (Default: 0)
Defines whether to use 0 or 1 based indexing when the user is
prompted to choose from a list of choices.
vim:ft=eclimhelp

85
vim-plugins/bundle/eclim/doc/vim/core/history.txt Normal file
View file

@ -0,0 +1,85 @@
*vim-core-history.html*
Eclipse Local History
*********************
Eclipse provides a feature called local history, which is basically a
simplistic version control system that is updated every time you save
a file. Using this local history, you can view diffs against
previously saved versions of your file or revert to one of those
revisions.
Eclim supports updating eclipse's local history when writing files
from vim, but by default this feature is disabled unless gvim was
started from the eclipse gui, in which case eclim will honor the
default eclipse editor behavior and update the local history. You can
turn this feature on in all cases by adding the following to your
vimrc:
>
let g:EclimKeepLocalHistory = 1
<
*:History*
:History - Opens a temporary buffer showing the local history for the
current file. In this buffer you can perform the following actions
using the specified key bindings:
- <cr> - view the contents of the revision under the cursor.
- d - diff the revision under the cursor against the current
contents.
- r - revert the current file to the revision under the cursor.
- c - clear the local history for the file.
*:HistoryClear*
:HistoryClear[!] - Clears the local history for the current file.
When the bang (!) is supplied, you are not prompted before clearing
the history.
*:HistoryDiffNext*
:HistoryDiffNext - While the history buffer is open, this command
allows you to diff the current file against the next entry in the
history stack.
*:HistoryDiffPrev*
:HistoryDiffPrev - Just like :HistoryDiffNext but diffs against the
previous entry in the stack.
Configuration
=============
Eclipse Settings
- When writing to the local history, eclim simply proxies the
request to eclipse, so all eclipse settings are honored. To modify
these settings you currently have to do so inside of the eclipse
gui. First shut down eclimd if you are running a headless version,
then open the eclipse gui and navigate to:
Window ‣ Preferences ‣ General ‣ Workspace ‣ Local History
And there you can edit your settings as necessary.
Vim Settings (vim-settings)
*g:EclimKeepLocalHistory*
- g:EclimKeepLocalHistory (Default: 0) - Controls whether writes in
vim will update the eclipse local history. This is disabled by
default unless gvim was started from the eclipse gui, in which case
eclim will honor the default eclipse editor behavior and update the
local history.
*g:EclimHistoryDiffOrientation*
- g:EclimHistoryDiffOrientation (Default: 'vertical') - When
initiating diffs, this setting controls whether the diff window is
opened as a horizontal split or vertical. Supported values include
'horizontal' and 'vertical'.
vim:ft=eclimhelp

12
vim-plugins/bundle/eclim/doc/vim/core/index.txt Normal file
View file

@ -0,0 +1,12 @@
*vim-core-index.html*
Core Functionality
******************
- Eclim Manage / Config (vim-core-eclim)
- Eclipse Project Management (vim-core-project)
- Eclipse Local History (vim-core-history)
- Locate File (vim-core-locate)
- Utility Commands (vim-core-util)
vim:ft=eclimhelp

111
vim-plugins/bundle/eclim/doc/vim/core/locate.txt Normal file
View file

@ -0,0 +1,111 @@
*vim-core-locate.html*
*:LocateFile*
Locate File
***********
Eclim provides the :LocateFile command to allow you to quickly find
and open files or buffers.
- :LocateFile [file_pattern] - Attempts to locate the supplied file
pattern or if no argument is supplied, opens a temporary window
where the text you type is turned into a pattern and search results
are presented as you type.
[image]
While in this completion mode the following key bindings are
available:
- <esc> - close the search window without selecting a file
- <tab> or <down> - cycle forward through the results
- <shift><tab> or <up> - cycle backwards through the results
- <enter> - open the selected file using the default action
- <ctrl>e - open the selected file via :edit
- <ctrl>s - open the selected file via :split
- <ctrl>t - open the selected file via :tabnew
- <ctrl>l - switch the locate scope
- <ctrl>h - toggle the help buffer
By default, the search string accepted by the completion mode is
intended to be just portions of the file name you are looking for,
which is then automatically expanded in an effort to help you find
the file with the fewest keystrokes possible.
The argument version of :LocateFile on the other hand, accepts a
hybrid glob/regex pattern. The glob portion allows you to use * and
** to match portions of a path or traverse multiple directories.
You can mix * and ** with standard perl compatible regex operators
to construct your search pattern.
If you prefer the more explicit patterns supported by the argument
version of :LocateFile over the default "fuzzy" pattern supported by
the completion version of :LocateFile, then you can turn off the
fuzzy matching support using the g:EclimLocateFileFuzzy variable
described below.
By default, all searching by both variants of this command is
limited to the current project and any projects listed as
dependencies, but you can widen the search scope to include all open
projects by setting g:EclimLocateFileScope to 'workspace', which is
the default scope when :LocateFile is executed outside of a project.
In addition to the 'project' and 'workspace' scopes, :LocateFile
also supports the following scopes:
- buffers: search listed buffers
- quickfix: search the quickfix results
Note: For performance reasons, locating files in the 'project' and
'workspace' scopes depends on eclipse being aware of all your
project files. For the most part this is handled automatically as
you create and edit files within vim. However, actions you take
outside of vim or eclipse (moving/removing files, updates from a
version control system, etc.) will not be visible until you force
a project refresh via |:ProjectRefresh|.
Note: If you would like to use :LocateFile even when eclimd is not
running or for projects not known to eclim, one option would be to
install the silver searcher
(https://github.com/ggreer/the_silver_searcher), then install my
ag plugin (https://github.com/ervandew/ag), and configure eclim to
use the plugin as the fallback default:>
let g:EclimLocateFileNonProjectScope = 'ag'
<
Configuration
Vim Settings (vim-settings)
*g:EclimLocateFileDefaultAction*
- g:EclimLocateFileDefaultAction (Default: 'split') - Determines
the command used to open the file when hitting <enter> on an entry
in the locate file results.
*g:EclimLocateFileScope*
- g:EclimLocateFileScope (Default: 'project') - Determines the
scope for which to search for files.
- 'project': search only the current project and its
dependencies.
- 'workspace': search the entire workspace (all open projects).
- 'buffers': search listed buffers
- 'quickfix': search the quickfix results
- 'vcsmodified': search files reported by your vcs as modified
or untracked.
*g:EclimLocateFileFuzzy*
- g:EclimLocateFileFuzzy (Default: 1) - Determines whether or not
'fuzzy' searching will be used on the no argument version of
:LocateFile.
*g:EclimLocateFileCaseInsensitive*
- g:EclimLocateFileCaseInsensitive (Default: 'lower') - Determines
when case insensitive searching is performed.
- 'lower': when the search string is all lower case the search
will be case insensitive, but if one or more capital letters are
present, then the search will be case sensitive.
- 'always': searching will always be case insensitive.
- 'never': searching will never be case insensitive.
Note: Search Filters: eclim does not yet expose the ability to add
filters should you want to ignore certain directories, but you can
configure this ability from within Eclipse:<right click on your
project> ‣ Properties ‣ Resource ‣ Resource Filters
vim:ft=eclimhelp

495
vim-plugins/bundle/eclim/doc/vim/core/project.txt Normal file
View file

@ -0,0 +1,495 @@
*vim-core-project.html*
Eclipse Project Management
**************************
The core concept in most IDEs is the that of a project, and Eclipse is
no different. Since a project must exist before you can perform any
of the more interesting tasks, eclim provides a set of commands to
create and manage projects from within Vim.
For the commands below that accept a project name as an argument, you
may use Vim's command line completion to complete the project name.
>
:ProjectSettings a_p<Tab>
:ProjectSettings a_project
<
*:ProjectCreate*
- :ProjectCreate <folder> [-p <project_name>] -n <nature> ... [-d
<project_dependency> ...]
- -p: Optional argument used to specify the project name. If
omitted, eclim will use the last segment of the project's path,
with any spaces replaced with underscores, as the project name.
- -n: Required argument which specifies a space separated list of
project natures (java, php, etc.) to add to the project. If you
want to create a project with no natures, you can use the word
"none" here.
>
:ProjectCreate ~/workspace/test -n none
<
Note that eclim supports command completion of available nature
names.
>
:ProjectCreate ~/workspace/test -n p<tab>
:ProjectCreate ~/workspace/test -n php
<
- -d: Optional argument used to specify a space separated list of
project names which the project you're creating depends on.
Some Examples
>
:ProjectCreate ~/projects/a_project -n java
:ProjectCreate ~/projects/a_project -n java -d another_project yet_another_project
:ProjectCreate ~/projects/a_project -n java php -p My\ Project\ Name
<
*:ProjectImport*
- :ProjectImport <folder>
If you have an existing eclipse project folder which does not exist
as a project in your current workspace, you can import that project
using this command:
>
:ProjectImport ~/workspace/some_project
<
*:ProjectImportDiscover*
- :ProjectImportDiscover <folder>
If you have several existing eclipse projects within a parent
directory that you'd like to import, you can do so using this
command, which scans the supplied folder for all .project files and
imports the corresponding project into your current workspace:
>
:ProjectImport ~/some/parent/dir
<
*:ProjectList*
- :ProjectList
Simply echo a list of available projects.
*:ProjectSettings*
- :ProjectSettings [<project>]
Opens a window with the project's available settings. If a project
name is supplied with this command, then the settings for that
project are opened. If no project name is supplied, and the current
file is in a project directory, then the settings for the current
project will be opened.
In the resulting window you can modify the values and save the
changes by simply writing the file in the usual Vim manner (:w). The
format of the buffer is in the standard properties file format as
supported by java, so all the same rules apply when editing. You can
refer to the settings (vim-settings) documentation for a description
of the available settings.
*:ProjectDelete*
- :ProjectDelete <project>
Deletes the project with the specified name.
*:ProjectRename*
- :ProjectRename [<project>] <name>
Renames a project. If two arguments are supplied then the first
argument is interpreted as the name of the project to rename and the
second argument as the new name for the project. When only a single
argument is supplied, then that argument is used as the new name for
the project which the current file belongs to.
*:ProjectMove*
- :ProjectMove [<project>] <dir>
Moves a project to the specified directory. If two arguments are
supplied then the first argument is interpreted as the name of the
project to move and the second argument as the directory to move the
project to. When only a single argument is supplied, then that
argument is used as the directory to move the current project to.
Warning: :ProjectMove, and possibly :ProjectRename, will result in
the renaming of your project's directory in the underlying file
system. Eclim will do its best to reload any files that have
moved as a result of the directory renaming and adjust your
current working directory if necessary, but only for the current
vim session. If you have other vim sessions open with files from
the project, then eclim will be unable to reload those files in
those sessions for you, so you will have to do so manually. A
best practice would be to close any other vim sessions that might
be affected by the moving or renaming of a project.
Note: When open files have moved as a result of :ProjectMove or
:ProjectRename, eclim will reload those files in the current
session, but it must do so via an :edit, which means that vim's
undo tree will be lost. However, you will still have access to the
eclipse history (vim-core-history).
*:ProjectRefresh*
- :ProjectRefresh [<project> <project> ...]
Refreshes the supplied list of named projects by synchronizing each
project against the current files on disk. If no projects names are
supplied, refresh the current project. Useful when files may have
been added, removed, or updated by a secondary application, like a
version control system (cvs, subversion, etc).
*:ProjectRefreshAll*
- :ProjectRefreshAll
Refreshes all projects.
*:ProjectInfo*
- :ProjectInfo [<project>]
Echo info about the current or supplied project.
*g:EclimProjectStatusLine*
Eclim supports displaying info about the current project in vim's
status line by adding a call to
eclim#project#util#ProjectStatusLine() to your statusline option:
>
set statusline=%<%f\ %M\ %h%r%=%-10.(%l,%c%V\ %{eclim#project#util#ProjectStatusLine()}%)\ %P
<
By default, this will just include the project name, but you can
customize the output by setting g:EclimProjectStatusLine:
>
let g:EclimProjectStatusLine = 'eclim(p=${name}, n=${natures})'
<
*:ProjectOpen*
- :ProjectOpen [<project>]
Opens a closed project.
*:ProjectClose*
- :ProjectClose [<project>]
Closes the current or supplied project. According to the Eclipse
documentation, closing unused projects can reduce the amount of
memory used, and may improve performance when building projects.
*:ProjectNatures*
- :ProjectNatures [<project>]
Echo list of natures for the supplied project name or for all
projects if no project name specified.
*:ProjectNatureAdd*
- :ProjectNatureAdd <project> [<nature> ...]
Adds one or more natures to a project. Supports command line
completion of nature names.
*:ProjectNatureRemove*
- :ProjectNatureRemove <project> [<nature> ...]
Removes one or more natures from a project. Supports command line
completion of nature names.
*:ProjectProblems*
- :ProjectProblems[!] [<project>] Populates vim's quickfix with a
list of all eclipse build errors and warnings for the current, or
specific project, and all related projects. Very similar to
eclipse's "Problems" view. By default, if the current quickfix list
represents a problems list, then as you save source files this list
will be updated accordingly.
Appending '!' limits the problem results to just errors.
Note: Problems are only reported for those projects that have an
associated builder in their .project file. If a project is not
reporting errors, first check that a proper builder is present in
the .project file. For java projects created via eclim prior to
eclim 1.5.2, the java builder may be missing, so you'll need to
recreate the project, at which time eclim will add the java
builder.
Configuration
Vim Settings (vim-settings)
*g:EclimQuickFixOpen*
- g:EclimQuickFixOpen (Default: 'botright copen')
Specifies the command used to open the quickfix window when
executing the :ref`:ProjectProblems` command.
*g:EclimProjectProblemsUpdateOnSave*
- g:EclimProjectProblemsUpdateOnSave (Default: 1)
When non 0, indicates that the problems list should be updated
when saving source files, but only if the quickfix list currently
represents a problems list.
- g:EclimProjectProblemsUpdateOnBuild (Default: 1)
When non 0, indicates that the problems list should be updated
after a :ProjectBuild, but only if the quickfix list currently
represents a problems list.
*:ProjectBuild*
- :ProjectBuild [<project>]
Builds the current or supplied project.
*:ProjectRun*
- :ProjectRun [<launch_config_name>]
Runs an eclipse launch configuration. When no launch configuration
name is supplied, the first available launch configuration will be
used.
Before you can run this command, you must first start vim with the
--servername argument (eclimd currently sends the process stdout and
stderr to vim using vim's remote invocation support):
>
$ vim --servername run ...
<
When your launch configuration is executed, a temporary buffer will
be opened in vim to display any output. When you close this window
the launch configuration process will be terminated. You can also
terminate the process from within the temporary output buffer by
running the :Terminate command (only available from that window).
Also note that if you close vim, any running launch configurations
will be terminated.
*:ProjectRunList*
- :ProjectRunList
Print a list of available eclipse launch configurations for the
current project.
*:ProjectCD*
- :ProjectCD
Changes the global current working directory to the root directory
of the current file's project (executes a :cd).
*:ProjectLCD*
- :ProjectLCD
Changes the current working directory of the current window to the
root directory of the current file's project (executes a :lcd).
*:ProjectTree*
- :ProjectTree [<project> <project> ...] :ProjectTree <dir> [<dir>
<project> ...]
Opens a window containing a navigable tree for the root directory of
one or more projects. If no arguments are supplied, the resulting
tree is for the current project. Otherwise, the tree contains
multiple root nodes, one for each project root directory. The
command also supports one or more arbitrary directories as arguments
as well should you want to open a tree for a project not managed by
eclim/eclipse (Note: the last part of the path will be used as the
project's name).
Available key mappings in project tree window.
- <cr> - Toggles expansion / collapsing of a directory, or
executes the first available action for a file.
- E - Opens the current file using 'edit' in the content window.
- S - Opens the current file in a new split.
- | (pipe) - Opens the current file in a new vertical split.
- T - Opens the current file in a new tab.
- o - Toggles folding / unfolding of a directory, or opens a
window of available actions to be executed on the selected file.
Hitting <enter> on an entry in the action window will execute that
action on the current file.
- s - Executes :shell for the directory under the cursor or the
parent directory of the file under the cursor.
- R - Refreshes the current directory against the current state of
the file system.
- A - Toggles whether or not hidden files are displayed in the
tree.
- ~ - Changes the root node to the current user's home directory.
- C - Changes the root node to the directory under cursor.
- B - Changes the root node to the parent directory of the current
root node.
- K - Changes the root node to the root path which will be either
the project root or the file system root.
- p - Moves the cursor to the parent of the node under the cursor.
- P - Moves the cursor to the last child of the nearest open
directory.
- :CD <dir> - Changes the root to the supplied directory.
- D - Prompts you for a directory name to create, pre-filled with
the directory path in the tree where this mapping was executed.
- F - Prompts you for a new or existing filename to open,
pre-filled with the directory path in the tree where this mapping
was executed.
- Y - Yanks the path of the current file/directory to your
clipboard.
- ? - View the help buffer
Configuration
Vim Settings (vim-settings)
*g:EclimProjectTreeAutoOpen*
- g:EclimProjectTreeAutoOpen (Default: 0)
When non 0, a project tree window will be auto opened for new Vim
sessions or new tabs in existing sessions if the current file is
in a project.
*g:EclimProjectTreeAutoOpenProjects*
- g:EclimProjectTreeAutoOpenProjects (Default: ['CURRENT'])
List of project names that will be in the project tree when it is
auto opened. The special name 'CURRENT' represents the current
project of the file being loaded in Vim when the tree is auto
opened.
*g:EclimProjectTreeExpandPathOnOpen*
- g:EclimProjectTreeExpandPathOnOpen (Default: 0)
When non 0, the path of the current file will be expanded in the
project tree when the project tree window is opened.
*g:EclimProjectTreePathEcho*
- g:EclimProjectTreePathEcho (Default: 1)
When non 0, the root relative path of the node under the cursor
will be echoed as you move the cursor around.
*g:EclimProjectTreeSharedInstance*
- g:EclimProjectTreeSharedInstance (Default: 1)
When non 0, a tree instance with the same list of projects will be
shared across vim tabs. This allows you to have the same project
tree open in several tabs all with the same state (with the
exception of folds).
*g:EclimProjectTreeActions*
- g:EclimProjectTreeActions
Default:
>
let g:EclimProjectTreeActions = [
\ {'pattern': '.*', 'name': 'Split', 'action': 'split'},
\ {'pattern': '.*', 'name': 'Tab', 'action': 'tabnew'},
\ {'pattern': '.*', 'name': 'Edit', 'action': 'edit'},
\ ]
<
List of mappings which link file patterns to the available actions
for opening files that match those patterns. Note that the first
mapping is the list is used as the default (<cr>).
Note: ProjectTree honors vim's 'wildignore' option by filtering
out files matching those patterns from the tree. The 'A' mapping
will toggle the display of those files along with other hidden
files and directories.
*:ProjectTreeToggle*
- :ProjectTreeToggle
Toggles (opens/closes) the project tree for the current project.
*:ProjectsTree*
- :ProjectsTree
Similar to :ProjectTree but opens a tree containing all projects.
*:ProjectTab*
- :ProjectTab <project> :ProjectTab <dir>
Command to initialize a new vim tab with the project tree open and
the tab relative working directory set to the project root. This
allows you to work on multiple projects within a single vim instance
where each project is isolated to its own tab. The command also
supports an arbitrary directory as an argument instead of a project
name should you want to open a tab for a project not managed by
eclim/eclipse (Note: the last part of the path will be used as the
project's name).
Configuration
Vim Settings (vim-settings)
*g:EclimProjectTabTreeAutoOpen*
- g:EclimProjectTabTreeAutoOpen (Default: 1)
When non 0, the project tree window will be auto opened on the
newly created tab.
*:ProjectGrep*
- :ProjectGrep /<pattern>/ <file_pattern> [<file_pattern> ...]
Executes vimgrep using the supplied arguments from the root of the
current project allowing you to run a project wide grep from any
file within the project.
*:ProjectGrepAdd*
- :ProjectGrepAdd /<pattern>/ <file_pattern> [<file_pattern> ...]
Just like :ProjectGrep but using vimgrepadd instead.
*:ProjectLGrep*
- :ProjectLGrep /<pattern>/ <file_pattern> [<file_pattern> ...]
Just like :ProjectGrep but using lvimgrep instead.
*:ProjectLGrepAdd*
- :ProjectLGrepAdd /<pattern>/ <file_pattern> [<file_pattern> ...]
Just like :ProjectGrep but using lvimgrepadd instead.
*:ProjectTodo*
- :ProjectTodo
Searches all the source files in the project (those with extensions
included in |g:EclimTodoSearchExtensions|) for the fixme / todo
pattern (defined by |g:EclimTodoSearchPattern|) and adds all
occurrences to the current location list.
*:Todo*
- :Todo
Just like :ProjectTodo, but limits the searching to the current
file.
Configuration
Vim Settings (vim-settings)
*g:EclimTodoSearchPattern*
- g:EclimTodoSearchPattern
Default:
>
let g:EclimTodoSearchPattern = '\(\<fixme\>\|\<todo\>\)\c'
<
Defines the regex pattern used to identify todo or fixme entries.
*g:EclimTodoSearchExtensions*
- g:EclimTodoSearchExtensions
Default:
>
let g:EclimTodoSearchExtensions = ['java', 'py', 'php', 'jsp', 'xml', 'html']
<
Defines a list of file extensions that will be searched for the
todo / fixme entries.
vim:ft=eclimhelp

220
vim-plugins/bundle/eclim/doc/vim/core/util.txt Normal file
View file

@ -0,0 +1,220 @@
*vim-core-util.html*
Utility Commands
****************
The following is a list of utility commands provided by eclim. These
are general purpose commands that are useful in and outside the scope
of eclim.
*:Tcd*
- :Tcd dir - Mimics vim's :lcd command but sets the current working
directory local to the current tab instead of just the current
window.
*:DiffLastSaved*
- :DiffLastSaved - Performs a diffsplit with the last saved version
of the currently modifed file.
*:SwapWords*
- :SwapWords - Swaps two words (with cursor placed on the first
word). Supports swapping around non-word characters like commas,
periods, etc.
*:Sign*
- :Sign - Toggles adding or removing a vim sign on the current line.
*:Signs*
- :Signs - Opens a new window containing a list of signs for the
current buffer. Hitting <enter> on one of the signs in the list
will take you to that sign in the corresponding buffer.
*:SignClearUser*
- :SignClearUser - Removes all vim signs added via :Sign.
*:SignClearAll*
- :SignClearAll - Removes all vim signs.
*:QuickFixClear*
- :QuickFixClear - Removes all entries from the quick fix window.
*:LocationListClear*
- :LocationListClear - Removes all entries from the location list
window.
*:Buffers*
- :Buffers - Opens a temporary window with a list of all the
currently listed buffers in vim (like :buffers). From this list you
can open any of the files using one of the following shortcuts:
- E (shift-e) - Open the file with 'edit'.
- S (shift-s) - Open the file with 'split'.
- V (shift-v) - Open the file with 'vsplit'.
- T (shift-t) - Open the file with 'tabnew'.
- D (shift-d) - Deletes the buffer and removes it from the list.
- ? - View the help buffer.
In addition to the above mappings you can also use <return> to
execute the configured default action on the buffer under the
cursor.
To configure the default action you can set the following variable:
g:EclimBuffersDefaultAction (defaults to 'split')
Note that eclim will track the tab where buffers are opened and
closed allowing :Buffers to filter the list to those whose primary
tab is the current tab, or for buffers not open, show those that
were last open on the current tab. If however you would like to
still see all listed buffers, you can append '!' to the command:
:Buffers!
By default entries will be sorted by path name, but you may change
the sorting via these two variables:
Configuration
Vim Settings (vim-settings)
*g:EclimBuffersSort*
- g:EclimBuffersSort (defaults to 'path') Supports one of 'path',
'status' (active or hidden), 'bufnr'.
*g:EclimBuffersSortDirection*
- g:EclimBuffersSortDirection (defaults to 'asc') Supports one of
'asc' or 'desc'.
*g:EclimBuffersTabTracking*
- g:EclimBuffersTabTracking (defaults to 1) When set to a non-0
value, eclim will keep track of which tabs buffers are opened on
allowing the :Buffers command to filter the list of buffers to
those accessed by the current tab. As noted above, you can still
view all buffers with this option enabled by using :Buffers! ('!'
appended).
*g:EclimBuffersDeleteOnTabClose*
- g:EclimBuffersDeleteOnTabClose (defaults to 0) When set to a
non-0 value and g:EclimBuffersTabTracking is enabled, then eclim
will delete any non-active buffers associated with the current tab
when that tab is closed. The can be useful if you use a tab per
project workflow and would like to close a project's tab and have
any buffers for that project deleted as well.
*:BuffersToggle*
- :BuffersToggle - A convenience command which opens the buffers
window if not open, otherwise closes it. Useful for creating a key
mapping to quickly open/close the buffers window.
*:Only*
- :Only - Alternative for vim's :only command. The purpose of this
command and the original vim version is to close all but the current
window. Unfortunately there is no way to tell the vim version to
exclude some windows you may wish to keep open (taglist, quickfix,
etc.). The eclim version provides that ability via the
g:EclimOnlyExclude and g:EclimOnlyExcludeFixed variables.
Configuration
Vim Settings (vim-settings)
*g:EclimOnlyExclude*
- g:EclimOnlyExclude (defaults to '^NONE$') - Regex used to match
buffer names for windows that should not be closed when issuing
the :Only command.
*g:EclimOnlyExcludeFixed*
- g:EclimOnlyExcludeFixed (defaults to 1) When non-0 all fixed
windows (ones which have 'winfixwidth' or 'winfixheight' set) will
be preserved when issuing the :Only command.
*:OpenUrl*
- :OpenUrl [url] - Opens a url in your web browser, or optionally in
Vim via netrw (:help netrw).
When executing the command you may supply the url to open, or if
ommitted, it will open the url under the cursor. By default all
urls will open in your web browser, but you may optionally configure
a list of url patterns to be opened via the netrw plugin. The
following example is configured to open all dtd, xml, xsd, and text
files via netrw.
>
let g:EclimOpenUrlInVimPatterns =
\ [
\ '\.\(dtd\|xml\|xsd\)$',
\ '\.txt$',
\ ]
<
For urls that match one of these patterns, you may also define how
the file is to be opened in Vim (split, edit, etc.).
>
let g:EclimOpenUrlInVimAction = 'split'
<
If a url you want to open matches one of these patterns, but you
want to force it to be opened in your browser, you can supply a bang
(!) to force it to do so:
>
:OpenUrl!
<
Configuration
Vim Settings (vim-settings)
*g:EclimOpenUrlInVimPatterns*
- g:EclimOpenUrlInVimPatterns (Default: []) - Defines a list of
url patterns to open in Vim via netrw.
*g:EclimOpenUrlInVimAction*
- g:EclimOpenUrlInVimAction (Default: 'split') - Defines the
command used to open files matched by g:EclimOpenUrlInVimPatterns.
*eclim#web#SearchEngine*
- eclim#web#SearchEngine Helper function which provides the
functionality needed to create search engine commands or mappings.
>
command -range -nargs=* Google call eclim#web#SearchEngine(
\ 'http://www.google.com/search?q=<query>', <q-args>, <line1>, <line2>)
<
Adding the above command to your vimrc or similar provides you with
a new :Google command allowing you to start a search on google.com
(http://google.com) in your browser from vim. This command can be
invoked in a few ways.
1. First by supplying the word or words to search for as
arguments to the command.
>
:Google "vim eclim"
:Google vim eclim
:Google +vim -eclim
<
Note that you can supply the arguments to the command just as you
would when using the search input via google's homepage, allowing
you to utilize the full querying capabilities of google.
2. The second method is to issue the command with no arguments.
The command will then query google with the word under the
cursor.
3. The last method is to visually select the text you want to
search for and then execute the command.
*eclim#web#WordLookup*
- eclim#web#WordLookup Helper function which can be used to create
commands or mappings which lookup a word using an online reference
like a dictionary or thesaurus.
>
command -nargs=? Dictionary call eclim#web#WordLookup(
\ 'http://dictionary.reference.com/search?q=<query>', '<args>')
<
Adding the above command to your vimrc or similar provides you with
a new :Dictionary command which can be used to look up a word on
dictionary.reference.com (http://dictionary.reference.com). You can
either supply the word to lookup as an argument to the command or it
will otherwise use the word under the cursor.
vim:ft=eclimhelp

55
vim-plugins/bundle/eclim/doc/vim/dltk/buildpath.txt Normal file
View file

@ -0,0 +1,55 @@
*vim-dltk-buildpath.html*
Source code completion, searching, and other features make use of the
eclipse dltk's (http://eclipse.org/dltk/) .buildpath to locate
resources. When you first create a dltk project (currently php
(vim-php-index) or ruby (vim-ruby-index)), a .buildpath file is
created in the project's root directory. If your project depends on
any source files located outside your project or in another project,
then you'll need to edit your .buildpath accordingly.
To help you do this, eclim provides several commands to ease the
creation of new build path entries and variables, all of which are
made available when you edit your .buildpath file in vim. Also when
you write the .buildpath file, Vim will issue a command to the eclim
server to update the project's build path, and will report any errors
via vim's location list (:help location-list).
The following is a list of commands that eclim provides while editing
your .buildpath.
*:NewSrcEntry_dltk*
- :NewSrcEntry <dir> [<dir> ...] - Adds one or more new entries
which reference source directories in your project.
>
<buildpathentry external="true" kind="lib" path="src/php"/>
<
This command supports command completion of project relative
directories.
*:NewLibEntry_dltk*
- :NewLibEntry <dir> [<dir> ...] - Adds one or more new entries
which reference external source directories.
>
<buildpathentry external="true" kind="lib" path="/usr/local/php/cake_1.1.16.5421"/>
<
This command supports command completion of directories.
*:NewProjectEntry_dltk*
- :NewProjectEntry <project> [<project> ...] - Adds one or more new
entries which reference other projects.
>
<buildpathentry combineaccessrules="false" kind="prj" path="/test_project"/>
<
This command supports command completion of project names.
vim:ft=eclimhelp

16
vim-plugins/bundle/eclim/doc/vim/groovy/complete.txt Normal file
View file

@ -0,0 +1,16 @@
*vim-groovy-complete.html*
Groovy Code Completion
**********************
Groovy code completion uses the standard Vim code completion mechanism
(vim-code_completion) like so:
>
list = ['foo', 'bar', 'baz']
list.s<C-X><C-U>
<
vim:ft=eclimhelp

9
vim-plugins/bundle/eclim/doc/vim/groovy/index.txt Normal file
View file

@ -0,0 +1,9 @@
*vim-groovy-index.html*
Groovy
******
- Groovy Code Completion (vim-groovy-complete)
- Groovy Validation (vim-groovy-validate)
vim:ft=eclimhelp

35
vim-plugins/bundle/eclim/doc/vim/groovy/validate.txt Normal file
View file

@ -0,0 +1,35 @@
*vim-groovy-validate.html*
*:Validate_groovy*
Groovy Validation
*****************
When saving a groovy source file that resides in a project, eclim will
update that source file in Eclipse and will report any validation
errors found. Any errors will be placed in the current window's
location list (:help location-list) and the corresponding lines in the
source file will be marked via Vim's :sign functionality with '>>'
markers in the left margin.
Automatic validation of groovy source files can be disabled via the
g:EclimGroovyValidate variable (described below). If you choose to
disable automatic validation, you can still use the :Validate command
to manually validate the current file.
Configuration
=============
Vim Settings (vim-settings)
*g:EclimGroovyValidate*
- g:EclimGroovyValidate (Default: 1) - If set to 0, disables source
code validation.
- g:EclimValidateSortResults (Default: 'occurrence') - If set to
'severity', the validation results will be sorted by severity
(errors > warnings > info > etc.)
vim:ft=eclimhelp

159
vim-plugins/bundle/eclim/doc/vim/html/index.txt Normal file
View file

@ -0,0 +1,159 @@
*vim-html-index.html*
Html / Css
**********
*html*
Html
====
Code Completion
---------------
Html code completion uses the standard Vim code completion mechanism
(vim-code_completion) like so:
>
<ht<Ctrl-X><Ctrl-U>
<html>
<he<Ctrl-X><Ctrl-U>
<html>
<head>
<lin<Ctrl-X><Ctrl-U>
<html>
<head>
<link ty<Ctrl-X><Ctrl-U>
<html>
<head>
<link type
...
<
File Validation
---------------
When editing a html file eclim will default to validating the file
when it is written. Any errors will be added to the current window's
location list (:help location-list) and their corresponding line
number noted via Vim's sign functionality.
If you do not want your html files validated automatically when saved,
you can set the |g:EclimHtmlValidate| variable described in the
configuration section below.
*:Validate_html*
Whether or not auto validation has been enabled, eclim also exposes
the command :Validate to manually execute the validation of the file.
Utils
-----
When editing html files eclim provides some utilility commands for
your convience.
*:BrowserOpen*
:BrowserOpen - Opens the current html file in your configured browser.
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimHtmlValidate*
- g:EclimHtmlValidate (Default: 1) - If set to 0, disables
validation when saving the file.
Note: When enabled, syntastic
(https://github.com/scrooloose/syntastic) is disabled so that
eclim and syntastic don't step on each other. If you'd like to use
syntastic over eclim for validation, then simply disable eclim's
validation.If you'd like to disable eclim's source code validation
for all languages, eclim provides a global variable for that as
well:>
let g:EclimFileTypeValidate = 0
<
- g:EclimValidateSortResults (Default: 'occurrence') - If set to
'severity', the validation results will be sorted by severity
(errors > warnings > info > etc.)
*css*
Css
===
Code Completion
---------------
Css code completion uses the standard Vim code completion mechanism
(vim-code_completion) like so:
>
bo<Ctrl-X><Ctrl-U>
body {
font-<Ctr-X><Ctrl-U>
body {
font-family: sa<Ctrl-X><Ctrl-U>
body {
font-family: sans-serif;
...
<
Validation
----------
When editing a css file eclim will default to validating the file when
it is written. Any errors will be added to the current window's
location list (:help location-list) and their corresponding line
number noted via Vim's sign functionality.
If you do not want your css files validated automatically when saved,
you can set the |g:EclimCssValidate| variable described in the
configuration section below.
*:Validate_css*
Whether or not auto validation has been enabled, eclim also exposes
the command :Validate to manually execute the validation of the file.
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimCssValidate*
- g:EclimCssValidate (Default: 1) - If set to 0, disables validation
when saving the file.
- g:EclimValidateSortResults (Default: 'occurrence') - If set to
'severity', the validation results will be sorted by severity
(errors > warnings > info > etc.)
vim:ft=eclimhelp

32
vim-plugins/bundle/eclim/doc/vim/index.txt Normal file
View file

@ -0,0 +1,32 @@
*vim-index.html*
Documentation
*************
Core Functionality
==================
- The Eclim Daemon (eclimd)
- Core Functionality (vim-core-index)
- Eclim Manage / Config (vim-core-eclim)
- Eclipse Project Management (vim-core-project)
- Eclipse Local History (vim-core-history)
- Locate File (vim-core-locate)
- Utility Commands (vim-core-util)
Supported Languages
===================
- C/C++ (vim-c-index)
- Html / Css (vim-html-index)
- Groovy (vim-groovy-index)
- Java (vim-java-index)
- Javascript (vim-javascript-index)
- Php (vim-php-index)
- Python (vim-python-index)
- Ruby (vim-ruby-index)
- Scala (vim-scala-index)
- Xml / Dtd / Xsd (vim-xml-index)
vim:ft=eclimhelp

70
vim-plugins/bundle/eclim/doc/vim/java/android.txt Normal file
View file

@ -0,0 +1,70 @@
*vim-java-android.html*
Android
*******
Creating a project
==================
Creating an android project is the same as creating a regular java
project, but you use the android nature instead:
>
:ProjectCreate /path/to/my_project -n android
<
This will result in a series of prompts for you to input your
project's information:
Note: at any point in this process you can use Ctrl+C to cancel the
project creation.
1. First you will be asked to choose the target android platform.
If you have only one platform installed on your system, this prompt
will be skipped and that platform will be used when creating the
project. If you have no platforms installed then you will receive
an error directing you to install a platform using the Android SDK
Manager. If you install a new platform you will need to either
restart eclipse/eclimd or run the eclim supplied |:AndroidReload|
command.
2. Next you will be asked to supply a package name (Ex:
com.mycompany.myapp).
3. Then you will need to supply a name for your application.
4. The next prompt will ask you if you are creating a library
project or not. Most likely you are not, so type 'n' here to
proceed.
5. Lastly, if you are not creating a library project, you will be
asked whether or not you want to have a new android activity
created for you and if so, you will be asked for the name of that
activity.
Once you've finished supplying the necessary information, your android
project will be created. An android project is simply a specialized
java project, so you can now leverage all the eclim provided java
functionality (vim-java-index) while developing your app.
Commands
========
*:AndroidReload*
:AndroidReload - Reloads the Android SDK environment in the running
eclimd/eclipse instance. Useful if you've made changes to the SDK
outside of eclipse (installed a new target platform, etc).
Configuration
=============
Eclim Settings (vim-settings)
*com.android.ide.eclipse.adt.sdk*
- com.android.ide.eclipse.adt.sdk - Sets the path to your system's
android sdk install.
vim:ft=eclimhelp

219
vim-plugins/bundle/eclim/doc/vim/java/ant.txt Normal file
View file

@ -0,0 +1,219 @@
*vim-java-ant.html*
Ant
***
Running
=======
For those that use Vim as an editor and ant as a build tool, is is
common to set your Vim 'makeprg' option to execute ant so that you may
navigate compilation errors via Vim's quickfix functionality.
Eclim utilizes this same paradigm to provide users with ant execution
functionality from any file without any of the setup required by Vim.
*:Ant*
Eclim provides the following command:
:Ant [<target> ...]
which performs the following steps:
- Saves any previous 'makeprg' and 'errorformat' option settings so
that you can define your own settings for the :make command.
- Sets 'makeprg' to execute ant with the -find option so that it
will search for your build.xml file in the current directory or in a
parent directory.
- Sets 'errorformat' to recognize the following errors:
- javac errors.
- javadoc errors.
- jasper jsp compilattion errors.
- junit errors / failures.
- cactus errors / failures.
- Executes :make.
- Restores your previous 'makeprg' and 'errorformat' option
settings.
Additionally, if g:EclimMakeLCD (|vim-core-eclim#g:EclimMakeLCD|) is
enabled (which it is by default), then the execution of ant will be
performed from the current buffer's project root directory, ensuring
that ant's build file discovery method is performed from the buffer's
working directory and not your own.
Note: :Ant also supports use of '!' (:Ant!) just like :make does,
which tells Vim not to jump to the first error if one exists.
The :Ant command also has the added benefit of command completion.
>
:Ant com<Tab>
:Ant compile
<
Warning: If your ant file has a lot of imports, then the command
completion may be slow as Eclipse parses all the imports when
creating the ant model. You will notice the same slow behavior when
using Eclipse directly to perform ant code completion.
Code Completion
===============
Ant code completion uses the standard Vim code completion mechanism
(vim-code_completion) like so:
>
<ja<Ctrl-X><Ctrl-U>
<jar de<Ctrl-X><Ctrl-U>
<jar destfile="${bas<Ctrl-X><Ctrl-U>
<jar destfile="${basdir
...
<
Screenshot of completion in action:
[image]
Warning: If your ant file has a lot of imports, then the code
completion may be slow as Eclipse parses all the imports when
creating the ant model. You will notice the same slow behavior when
using Eclipse directly.
Validation
==========
When editing an ant xml file eclim will default to validating the file
when it is written. Any errors will be added to the current window's
location list (:help location-list) and their corresponding line
number noted via Vim's sign functionality.
Currently the Eclipse ant file validation isn't as robust as one might
hope. It doesn't validate that element attributes are correct, that
child elements are valid, etc., but it does perform the following:
- If a default target is specified, validate that it exists and that
the target dependencies exist.
- Check for missing dependencies.
- Check for circular dependencies.
Eclim also combines the above validation with xml validation
(vim-xml-index#xml-validation) to validate that the ant file is well
formed.
If you do not want your ant files validated automatically when saved,
you can set the |g:EclimAntValidate| variable described in the
configuration section below.
*:Validate_ant*
Whether or not auto validation has been enabled, eclim also exposes
the command :Validate to manually execute the validation of the ant
file.
*:AntDoc*
Documentation Lookup
====================
When editing an ant build file eclim defines a command named :AntDoc
which will attempt to lookup and open in your configured browser
(|vim-core-eclim#g:EclimBrowser|) the documentation for the element
under the cursor or, if supplied, the element passed to it.
This command will only lookup element names, not attribute names or
values.
By default this plugin is configured to find all the standard ant
tasks, types, etc, as well as those defined by the antcontrib
(http://ant-contrib.sourceforge.net) project.
*:AntUserDoc*
If you have other tasks that you wish to add to this plugin, you can
do so by defining the global variable g:EclimAntUserDocs. The value of
this variable is expected to be a map of element names to the url
where the documentation for that element can be found. The url also
supports a substitution variable, <element> which will be substituted
with the lower case version of the element name.
The following is an example which adds the tasks from the apache
cactus project.
>
let s:cactus =
\ 'http://jakarta.apache.org/cactus/integration/ant/task_<element>.html'
let g:EclimAntUserDocs = {
\ 'cactifywar' : s:cactus,
\ 'cactifyear' : s:cactus,
\ 'cactus' : s:cactus,
\ 'runservertests' : s:cactus,
\ 'webxmlmerge' : s:cactus,
\ }
<
Configuration
=============
Vim Settings (vim-settings)
*g:EclimAntCompilerAdditionalErrorFormat*
- g:EclimAntCompilerAdditionalErrorFormat (Default: '') - Since
there are many more ant tasks beyond javac, javadoc, etc., eclim
provides this variable as a means to add error format information
for any additional ant tasks that you may be using.
Example: Adding support for xslt
>
let g:EclimAntCompilerAdditionalErrorFormat =
\ '\%A%.%#[xslt]\ Loading\ stylesheet\ %f,' .
\ '\%Z%.%#[xslt]\ %.%#:%l:%c:\ %m,'
<
Note: The xslt task is a bit flaky when it comes to reporting the
file name on errors, so the above format will catch successful
runs as well. If anyone has a better solution, please submit it.
*g:EclimAntErrorsEnabled*
- g:EclimAntErrorsEnabled (Default: 0) - When non-zero, build file
error messages will be added to vim's quickfix if encountered during
:Ant invocations. Disabled by default because it's difficult to
distinguish between actual issues with the build file (invalid
property, task, etc.) and build failure messages which occur under
normal usage (junit task failed due to test failure, javac failures
due to compile error, etc.) leading to false positives.
*g:EclimAntValidate*
- g:EclimAntValidate (Default: 1) - If set to 0, disables ant xml
validation when saving the file.
Suggested Mappings
==================
Here are some mappings for the ant funtionality provided by eclim. To
make use of these mappings, simply create a ftplugin file for ant and
place your mappings there (:help ftplugin-name).
- Lookup and open the documentation for the ant element under the
cursor with <enter>.
>
noremap <silent> <buffer> <cr> :AntDoc<cr>
<
vim:ft=eclimhelp

371
vim-plugins/bundle/eclim/doc/vim/java/classpath.txt Normal file
View file

@ -0,0 +1,371 @@
*vim-java-classpath.html*
Eclipse Classpath Editing
*************************
Source code completion, searching, auto imports, all rely on a
properly configured classpath. When you first create a project, a
.classpath file is created in the project's root directory. If you
created the project on an existing code-base, eclim will attempt to
setup the .classpath file with any source code directories or
libraries in the project.
Regardless of the state of your project you will at some point need to
update the classpath. The primary method of doing so, is to directly
edit the .classpath to add, update, or remove entries as needed. To
help you do this, eclim provides several commands to ease the creation
of new classpath entries and variables.
Note: All of the commands described below are only available while
editing the .classpath file in vim.When you write the .classpath
file, Vim will issue a command to the eclim server to update the
project's classpath, and will report any errors via vim's location
list (:help location-list).In addition to directly editing the
.classpath file, you may also use maven's support for maintaining
the eclipse classpath. For users who use ivy
(http://jayasoft.org/ivy), eclim also provides a means to auto
update the eclipse classpath when saving changes to your ivy.xml.
*:NewSrcEntry_java*
- :NewSrcEntry <dir> - Adds a new entry for a source code directory
relative to the project's root directory.
>
<classpathentry kind="src" path="src/java"/>
<
This command supports command completion of the directory relative
to the .classpath file.
*:NewProjectEntry_java*
- :NewProjectEntry <project> - Adds a new entry for a dependency on
another project.
>
<classpathentry exported="true" kind="src" path="/a_project"/>
<
This command supports command completion of the project name.
*:NewJarEntry_java*
- :NewJarEntry <file> [<src_path> <javadoc_path>] - Adds a new entry
for a jar file dependency. If the jar file is not in a folder under
the project root, you must use an absolute path (apparent limitation
with Eclipse).
>
<classpathentry exported="true" kind="lib" path="lib/commons-beanutils-1.8.3.jar"/>
<
You may optionally supply the path to the source for this jar and
the entry created will include the sourcepath attribute:
>
:NewJarEntry lib/commons-beanutils-1.8.3.jar lib/commons-beanutils-1.8.3-sources.jar
<
>
<classpathentry kind="lib" path="lib/commons-beanutils-1.8.3.jar"
sourcepath="lib/commons-beanutils-1.8.3-sources.jar"/>
<
In addition to the source path you can all supply the path to the
javadocs:
>
:NewJarEntry lib/commons-beanutils-1.8.3.jar lib/commons-beanutils-1.8.3-sources.jar lib/commons-beanutils-1.8.3-javadoc.jar
<
>
<classpathentry kind="lib" path="lib/commons-beanutils-1.8.3.jar"
sourcepath="lib/commons-beanutils-1.8.3-sources.jar">
<attributes>
<attribute name="javadoc_location" value="jar:platform:/resource/my_project/lib/commons-beanutils-1.8.3-javadoc.jar"/>
</attributes>
</classpathentry>
<
*:NewVarEntry_java*
- :NewVarEntry <VAR/file> [<src_path> <javadoc_path>] - Just like
NewJarEntry except an Eclipse "var" entry is created. When a jar
entry references an absolute path, you should instead use a var
entry. The var entry allows you to define a base dir as a variable
(ex. USER_HOME = /home/username), and then reference files relative
to that variable.
>
<classpathentry exported="true" kind="var" path="USER_HOME/lib/hibernate-4.0.jar"/>
<
This allows you to share .classpath files with other developers
without each having a local copy with environment specific paths.
To add new base classpath variables, you can edit
$ECLIPSE_HOME/plugins/org.eclim_version/classpath_variables.properties
By default, a USER_HOME variable is created that defaults to the
java System property "user.home" and you can add more as needed.
This command supports command completion of Eclipse variable names
as well as the files and directories beneath the path the variable
represents.
To manage the classpath variables, eclim also provides the following
commands.
*:VariableList*
- :VariableList - Lists all the currently available classpath
variables and their corresponding values.
*:VariableCreate*
- :VariableCreate <name> <path> - Creates or updates the variable
with the supplied name.
*:VariableDelete*
- :VariableDelete <name> - Deletes the variable with the supplied
name.
*classpath-src-javadocs*
Source and Javadoc location
===========================
For your var and lib classpath entries, if you didn't do so when you
created the entry, you can configure the location for that entry's
source code and javadocs, like the example below, allowing you to jump
to the source (|:JavaSearch|) or lookup the docs (|:JavaDocSearch|) of
classes, etc found in that library. Note that the javadoc location
must be a url, whether it be on the local file system (file:, jar:file
(jar:file):) or remote (http:).
>
<classpathentry exported="true" kind="lib" path="lib/hibernate-4.0.jar"
sourcepath="<path>">
<attributes>
<attribute name="javadoc_location" value="file:<javadoc_dir>"/>
</attributes>
</classpathentry>
<
Note: If your javadoc location is a jar in your workspace (in the
curent project or another project), then the url must be in the form
(where <project_name> is replaced with your project's name):>
jar:platform:/resource/<project_name>/path/to/javadoc.jar!/
<
If the jar file is outside of your workspace, then it would be in
the form:>
jar:file:/your/absolute/path/to/javadoc.jar!/
<
*classpath-maven*
Maven
=====
Maven (http://maven.apache.org) comes bundled with an Eclipse plugin
that allows you to easily maintain your .classpath file based on your
pom.xml (or project.xml for maven 1.x users).
Note: For additional information on the Eclipse plugin from maven,
you may visit their online documentation for maven 1.x
(http://maven.apache.org/maven-1.x/plugins/eclipse/) or maven 2.x
(http://maven.apache.org/guides/mini/guide-ide-eclipse.html).
*:MvnRepo* *:MavenRepo*
- Initial Setup
To initialize maven's support for updating the eclipse classpath you
first need to set the M2_REPO (or MAVEN_REPO for 1.x) classpath
variable in the Eclipse workspace by executing the following command
in vim:
maven 2.x:
>
:MvnRepo
<
maven 1.x:
>
:MavenRepo
<
- Updating your .classpath
Once you have performed the initial setup, updating the Eclipse
.classpath file is as easy as executing the following at a command
line:
maven 2.x:
>
mvn eclipse:eclipse
<
maven 1.x:
>
maven eclipse
<
or in Vim:
maven 2.x:
>
:Mvn eclipse:eclipse
<
maven 1.x:
>
:Maven eclipse
<
*classpath-maven-pom*
For maven 2.x users, eclim also provides support for auto updating
the .classpath for your project every time you save your pom.xml
file. Any entries found in the pom.xml that are not in the
.classpath will be added, any entries that differ in version will be
updated, and any stale entries deleted.
Note: This behavior can be disabled by adding the following
setting to your vimrc:>
let g:EclimMavenPomClasspathUpdate = 0
<
Note: This feature simply updates the entries in your project's
.classpath file, it does not download any newly added jars. When
you'd like maven to download those new jars, you can run the
following from the command line:>
mvn dependency:resolve
<
or from within Vim:>
:Mvn dependency:resolve
<
*classpath-ivy*
Ivy
===
For users of ivy (http://jayasoft.org/ivy), eclim provides support for
auto updating the .classpath for your project every time you save your
ivy.xml file. Any entries found in the ivy.xml that are not in the
.classpath will be added, any entries that differ in version will be
updated, and any stale entries deleted.
*:IvyRepo*
- Initial Setup
Before you can start utilizing the auto updating support, you must
first set the location of your ivy repository (ivy cache). This is
the directory where ivy will download the dependencies to and where
eclipse will then pick them up to be added to your project's
classpath.
To set the repository location you can use the :IvyRepo command
which is made available when editing an ivy.xml file.
>
:IvyRepo ~/.ivy2/cache/
<
If you fail to set this prior to writing the ivy.xml file, eclim
will emit an error notifying you that you first need to set the
IVY_REPO variable via this command.
- Updating your .classpath
Once you have performed the initial setup, updating the Eclipse
.classpath file is as easy as saving your ivy.xml file (:w) and
letting eclim do the rest.
Note: This behavior can be disabled by adding the following
setting to your vimrc:>
let g:EclimIvyClasspathUpdate = 0
<
Note: This feature will update your project's .classpath file
accordingly, but it will not download any newly added jars. For
that you'll need to have a target in your ant build file that will
force ivy to download dependencies. Something like the example
from the ivy docs:>
<target name="resolve" description="--> retrieve dependencies with ivy">
<ivy:retrieve/>
</target>
<
You can then run this target from the command line:>
ant resolve
<
or from within Vim>
:Ant resolve
<
- Preserving manually added entries
When utilizing the ivy support, eclim will attempt to remove any
stale entries from your .classpath file. If you have some manually
added entries, these may be removed as well. To prevent this you
can add a classpath entry attribute notifying eclim that the entry
should be preserved.
Ex.
>
<classpathentry kind="lib" path="lib/j2ee-1.4.jar">
<attributes>
<attribute name="eclim.preserve" value="true"/>
</attributes>
</classpathentry>
<
vim:ft=eclimhelp

35
vim-plugins/bundle/eclim/doc/vim/java/complete.txt Normal file
View file

@ -0,0 +1,35 @@
*vim-java-complete.html*
Java Code Completion
********************
Java code completion uses the standard Vim code completion mechanism
(vim-code_completion) like so:
>
System.o<Ctrl-X><Ctrl-U>
System.out.pri<Ctrl-X><Ctrl-U>
<
Screenshot of completion in action:
[image]
Configuration
=============
Vim Settings (vim-settings)
*g:EclimJavaCompleteCaseSensitive*
- g:EclimJavaCompleteCaseSensitive (Default: !&ignorecase) - When
set to a value greater than 0, eclim will filter out completions
that don't start with the same case base that you are attempting to
complete (the base and the suggested completion must have the same
case).
vim:ft=eclimhelp

262
vim-plugins/bundle/eclim/doc/vim/java/debug.txt Normal file
View file

@ -0,0 +1,262 @@
*vim-java-debug.html*
Java Debugging
**************
*:JavaDebugStart*
Starting a debug session
=========================
Before starting a debug session from vim you first need to do a couple
things:
1. Start your java program with the debugging hooks enabled:
>
$ java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=1044 \
-classpath ./bin org.test.debug.Main
<
2. Start vim with the --servername argument (eclimd currently sends
debugger updates to vim using vim's remote invocation support):
>
$ vim --servername debug ...
<
Note: The server name you choose doesn't matter as long as you don't
have another vim instance running with that same name.
Once you've got your java program running and vim started with a
servername, you can then start your debug session using the
:JavaDebugStart command. This command requires the hostname/IP and the
port number on which the debug server is running.
>
:JavaDebugStart localhost 1044
<
*:JavaDebugBreakpointToggle*
Add/Remove a breakpoint
=======================
To add a breakpoint, simply open the file, position the cursor on the
desired line and run the :JavaDebugBreakpointToggle command. If now
breakpoint exists, one will be created. If a breakpoint does exist,
then :JavaDebugBreakpointToggle will toggle whether that breakpoint is
enabled or not. If you'd like to delete the breakpoint on the current
line instead of disabling it, then run the toggle command with the !
option.
>
" create a breakpoint or toggle whether the current breakpoint is
" enabled/disabled
:JavaDebugBreakpointToggle
" same as the above, but instead disabling an enabled breakpoint,
" delete it instead.
:JavaDebugBreakpointToggle!
<
*:JavaDebugBreakpointsList*
Listing your breakpoints
========================
To view a list of all your breakpoints you can use the
:JavaDebugBreakpointsList command, which by default will list all
breakpoints for the current file, or with the ! suffix, it will list
all breakpoints for the current project and all project dependencies.
>
:JavaDebugBreakpointsList
:JavaDebugBreakpointsList!
<
This will open a new window which displays your breakpoints grouped by
file or by project and file.
Mappings
- <cr> - Jump to the file and line of the breakpoint under the
cursor
- T - Toggles the breakpoint under the cursor, or all breakpoints
under the file or project when used on the class name or project
name.
- D - Deletes the breakpoint under the cursor, or all breakpoints
under the file or project when used on the class name or project
name.
*:JavaDebugBreakpointRemove*
Remove breakpoints
==================
In addition to using the delete mapping provided in the
|:JavaDebugBreakpointsList| window, you can also remove all
breakpoints in the current file using the :JavaDebugBreakpointRemove
command, or with the ! suffix, you can remove all breakpoints in the
current project.
>
:JavaDebugBreakpointRemove
:JavaDebugBreakpointRemove!
<
*:JavaDebugStep*
Step Through the Code
=====================
There are 3 ways to step through code using the :JavaDebugStep command
and an action argument.
- over: Step over current line
- into: Step into a function
- return: Return from current function
>
:JavaDebugStep over
:JavaDebugStep into
:JavaDebugStep return
<
*:JavaDebugStatus*
Status
======
When a debugging session is started, a status window is automatically
opened at the bottom in a horizontal split window. It has 2 panes:
- Debug Threads: The left pane shows active threads along with its
stack frames.
Mappings
- s - Suspend the thread under the cursor.
- S - Suspend all threads.
- r - Resume the thread under the cursor.
- R - Resume all threads.
- B - Open the breakpoints window showing all breakpoints for this
project and dependencies.
- Debug Variables: The right pane shows the variables available for
the thread selected on the left pane. Variables can be seen only for
suspended threads. If there are suspended threads, then one of them
is automatically selected and its variables displayed.
Mappings
- <cr> - Expands the variable. Nested variables are shown in a
tree like structure. To collapse the variable, press <CR> again.
- p - Displays the toString value of the variable under cursor.
This is equivalent to the Details pane in Eclipse.
- B - Open the breakpoints window showing all breakpoints for this
project and dependencies.
If for some reason, the status window is not updated, or you
accidentally closed it, you can manually refresh it by running
:JavaDebugStatus command.
>
:JavaDebugStatus
<
*:JavaDebugStop*
Suspend / Resume
================
In addition to using the mappings provided in the |:JavaDebugStatus|
threads window, you can also suspend and resume threads using the
following commands:
- To suspend the entire debugging session (all threads), run
:JavaDebugThreadSuspendAll from any window.
- To resume the entire debugging session (all threads), run
:JavaDebugThreadResumeAll from any window.
Stop
====
To stop a debug session, you can use the :JavaDebugStop command.
>
:JavaDebugStop
<
*:JavaDebugThreadSuspendAll* *:JavaDebugThreadResume*
*:JavaDebugThreadResumeAll*
Configuration
=============
*g:EclimJavaDebugLineHighlight*
- g:EclimJavaDebugLineHighlight (Default: 'DebugBreak') Highlight
group to use for showing the current line being debugged.
*g:EclimJavaDebugLineSignText*
- g:EclimJavaDebugLineSignText (Default: '•') Text to use on sign
column for showing the current line being debugged.
*g:EclimJavaDebugStatusWinOrientation*
- g:EclimJavaDebugStatusWinOrientation (Default: 'vertical') Sets
the orientation for the splits inside the debug status windows; if
they should be tiled vertically or horizontally. Possible values: -
horizontal - vertical
*g:EclimJavaDebugStatusWinWidth*
- g:EclimJavaDebugStatusWinWidth (Default: 50) Sets the window width
for the splits inside the debug status window. This is only
applicable when the orientation is horizontal.
*g:EclimJavaDebugStatusWinHeight*
- g:EclimJavaDebugStatusWinHeight (Default: 10) Sets the window
height for the splits inside the debug status window. This is only
applicable when the orientation is vertical.
Troubleshooting
===============
- Expanding a variable shows an empty line with just a dot. You
probably haven't pressed the <Enter> key on the variable. Nested
variables are retreived one level at a time from the server to be
performant. Since we are using VIM folds, any mapping that simply
opens a fold will not cause variables to be retrieved.
- A split window is created when stepping into a function
(JavaDebugStep into) from the debug status window. It is not clear
why this is happening. To avoid this problem, run step into command
outside the debug status window.
vim:ft=eclimhelp

79
vim-plugins/bundle/eclim/doc/vim/java/format.txt Normal file
View file

@ -0,0 +1,79 @@
*vim-java-format.html*
Java Source Code Formatting
***************************
Eclim provides the ability to format java source code using the
eclipse formatter selected for your workspace.
Source code formatting is invoked in eclipse using the shortcut
<C-S-F>, or from the Source / Format menu. The eclim equivalent is
invoked using the :JavaFormat command described below.
*:JavaFormat*
- :JavaFormat - Formats the current visual selection (or the current
line, if nothing is selected). To format the whole file, use
:%JavaFormat.
Given the following file:
>
/**
* @return
*
* Service
* for test Eclipse <C-F> formatting.
*/
public
static String
getAbstractService
()
{
if (abstractService == null)
{
throw new RuntimeException( "abstractService isn't initialized !");
}
return abstractService;
}
<
You can execute :%JavaFormat to format the code according to your
eclipse settings.
>
/**
* @return
*
* Service for test Eclipse <C-F> formatting.
*/
public static String getAbstractService() {
if (abstractService == null) {
throw new RuntimeException("abstractService isn't initialized !");
}
return abstractService;
}
<
Configuration
=============
*org.eclim.java.format.strip_trialing_whitespace*
- org.eclim.java.format.strip_trialing_whitespace - When set to
true, all trailing whitespace will be removed when formatting java
code.
Aside from the above configuration, source code formatting is only
configurable via the eclipse GUI. So to make changes to the eclipse
java formatting rules, shutdown eclim, start the eclipse GUI and
configure your settings via:
Preferences ‣ Java ‣ Code Style ‣ Formatter ‣ Active Profile: ‣ Edit
vim:ft=eclimhelp

60
vim-plugins/bundle/eclim/doc/vim/java/import.txt Normal file
View file

@ -0,0 +1,60 @@
*vim-java-import.html*
*:JavaImport*
Automated Imports
*****************
The automated import functionality is pretty straightforward. Simply
place the cursor over the element to import and issue the command:
:JavaImport
and one of the following events will occur:
- If only one matching element is found, its import statement will
be placed in the file.
- If multiple matching elements are found, you will be prompted to
choose the element you wish to import from a list.
- If an element with the same name is already imported, the element
is in java.lang, or the element is in the same package as the
current src file, then no changes will occur.
*:JavaImportOrganize*
In addition to adding imports one by one, you can also add them in
bulk along with the removal of unused imports and the sorting and
formating of all the file's import statements using the command:
:JavaImportOrganize
Configuration
=============
Eclim Settings (vim-settings)
*org.eclipse.jdt.ui.importorder*
- org.eclipse.jdt.ui.importorder (Default: java;javax;org;com) -
Semicolon separated list of package names which specify the sorting
order for import statements. This settings is the same setting used
by the eclipse gui in the "Organize Imports" preference dialog.
*org.eclim.java.import.exclude*
- org.eclim.java.import.exclude (Default: ["^com.sun..*",
"^sunw?..*"]) - List of patterns to exclude from import results.
*org.eclim.java.import.package_separation_level*
- org.eclim.java.import.package_separation_level (Default: 1) - Used
to determine how imports are grouped together (or spaced apart). The
number represents how many segments of the package name to use to
determine equality, where equal imports are grouped together and
separated from other groups with a blank line.
- -1: Use the entire package name. Only imports from the same full
package are grouped together.
- 0: Don't look at any package segments. All imports are grouped
together with no spacing.
- n: Look at the first n segments of the package name.
vim:ft=eclimhelp

57
vim-plugins/bundle/eclim/doc/vim/java/index.txt Normal file
View file

@ -0,0 +1,57 @@
*vim-java-index.html*
Java
****
Features
========
- Eclipse Classpath Editing (vim-java-classpath)
- Java Validation / Correction (vim-java-validate)
- Java Code Completion (vim-java-complete)
- Java Search (vim-java-search)
- Java / Jps (vim-java-java)
- Java Debugging (vim-java-debug)
- Javadoc Support (vim-java-javadoc)
- Java Source Code Formatting (vim-java-format)
- Java Refactoring (vim-java-refactor)
- Java Code Inspection (vim-java-inspection)
- Automated Imports (vim-java-import)
- Type Creation (vim-java-types)
- Method Generation (vim-java-methods)
- Unit Tests (vim-java-unittests)
- Logging (log4j, etc) (vim-java-logging)
- Ant (vim-java-ant)
- Maven (vim-java-maven)
- Android (vim-java-android)
- WEB-INF/web.xml (vim-java-webxml)
Suggested Mappings
==================
Here are some mappings for the java funtionality provided by eclim.
To make use of these mappings, simply create a ftplugin file for java
and place your mappings there (:help ftplugin-name).
- Import the class under the cursor with <leader>i (:h mapleader):
>
nnoremap <silent> <buffer> <leader>i :JavaImport<cr>
<
- Search for the javadocs of the element under the cursor with
<leader>d.
>
nnoremap <silent> <buffer> <leader>d :JavaDocSearch -x declarations<cr>
<
- Perform a context sensitive search of the element under the cursor
with <enter>.
>
nnoremap <silent> <buffer> <cr> :JavaSearchContext<cr>
<
vim:ft=eclimhelp

112
vim-plugins/bundle/eclim/doc/vim/java/inspection.txt Normal file
View file

@ -0,0 +1,112 @@
*vim-java-inspection.html*
Java Code Inspection
********************
*:JavaHierarchy*
Class / Interface Hierarchy
===========================
When viewing a java class or interface you can view the type hierarchy
by issuing the command :JavaHierarchy. This will open a temporary
buffer with an inversed tree view of the type hierarchy with the
current class / interface at the root.
>
public class XmlCodeCompleteCommand
public class WstCodeCompleteCommand
public class AbstractCodeCompleteCommand
public class AbstractCommand
public interface Command
<
Inner classes / interfaces are also supported. Just place the cursor
on the inner class / interface before calling :JavaHierarchy.
While you are in the hierarchy tree buffer, you can jump to the type
under the cursor using one of the following key bindings:
- <cr> - open the type using the (default action).
- E - open the type via :edit
- S - open the type via :split
- T - open the type via :tabnew
- ? - view help buffer
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimJavaHierarchyDefaultAction*
- g:EclimJavaHierarchyDefaultAction (defaults to 'split') -
Determines the command used to open the type when hitting <enter> on
the type entry in the hierarchy buffer.
*:JavaCallHierarchy*
Call Hierarchy
==============
When viewing a java source file you can view the call hierarchy of a
method by issuing the command :JavaCallHierarchy. This will open a
temporary buffer with an inversed tree view of the hierarchy of
callers of the requested method.
>
foo(int) : Object - org.test.SomeClass
bar() : void - org.test.AnotherClass
main() : void - org.test.MainClass
baz(String) : int - org.test.AnotherClass
<
While you are in the hierarchy tree buffer, you can jump to the call
under the cursor using one of the following key bindings:
- <cr> - open the type using the (default action).
- E - open the type via :edit
- S - open the type via :split
- T - open the type via :tabnew
- ? - view help buffer
:JavaCallHierarchy can also be used to view the callees for a method
by invoking the command with a !:
>
:JavaCallHierarchy!
<
By default the call hierarchy (caller and callee) will search across
your entire workspace. If you want to limit the search to just the
current project you can use the scope (-s) option:
>
:JavaCallHierarchy -s project
<
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimJavaCallHierarchyDefaultAction*
- g:EclimJavaCallHierarchyDefaultAction (defaults to 'split') -
Determines the command used to open the file when hitting <enter> on
an entry in the hierarchy buffer.
vim:ft=eclimhelp

109
vim-plugins/bundle/eclim/doc/vim/java/java.txt Normal file
View file

@ -0,0 +1,109 @@
*vim-java-java.html*
Java / Jps
**********
*:Java*
Java
====
To run the configured main class for your project, you may use the
:Java command, which executes java and displays the results in a
temporary buffer.
Note: Please note that this command is not intended to be a full
replacement for the more advance support provided by eclipse, ant,
or maven.
The :Java will locate the main class to run using the following steps:
1. if the first argument is '%' (:Java %) then run the current
class.
2. if the setting org.eclim.java.run.mainclass is set, then use the
value as the fully qualified class name to run.
3. lastly, attempt to locate a class containing a static main
method, if only one is found, use that class.
Configuration
-------------
*org.eclim.java.run.mainclass*
Eclim Settings (vim-settings)
- org.eclim.java.run.mainclass - Fully qualified name of the class
containing the main method.
- org.eclim.java.run.jvmargs - Json formatted list of default jvm
args.
*:JavaClasspath*
Echo the classpath for the current project
------------------------------------------
When editing a java file, eclim provides the command :JavaClasspath
which will echo the project's resolved classpath entries separated by
the system path separator or a supplied delimiter:
>
:JavaClasspath
:JavaClasspath -d \\n
<
If you would like to get the classpath from a script, you can also
call eclim directly:
>
$ $ECLIPSE_HOME/eclim -command java_classpath -p <project_name>
<
*:JavaListInstalls*
Viewing list of known JDKs/JREs installed
-----------------------------------------
To view a list of all the JDKs/JREs that eclipse is aware of, eclim
provides the command :JavaListInstalls.
*:Jps*
Jps (Process Status Tool)
=========================
As of Java 1.5 (Java 5.0), the sun jdk started shipping with some
useful tools for viewing information about running java processes. To
provide quick and easy access to some of the information these
commands provide, eclim exposes the command :Jps.
Note: For more information on the jdk tools you may view the online
documentation
(http://docs.oracle.com/javase/6/docs/technotes/tools/#monitor).
When invoked it will open a window containing information about the
current processes and some links for viewing additional info
(depending upon availability of required tools on your platform).
Example content:
[image]
- Line 1 consists of the process id followed by either the class
name the process was started with or the path to the jar file.
- Lines 2 - 5 contains links that when you hit <enter> on, will open
another window displaying the requested additional info.
- Lines 7 - 13 is a foldable block which contains a list of all the
arguments passed to the main method of the process.
- Lines 15 - 21 is a foldable block which contains a list of all the
arguments passed to the JVM.
vim:ft=eclimhelp

110
vim-plugins/bundle/eclim/doc/vim/java/javadoc.txt Normal file
View file

@ -0,0 +1,110 @@
*vim-java-javadoc.html*
Javadoc Support
***************
*:JavaDocComment*
Commenting
==========
Eclim provides the :JavaDocComment command which will add or update
the javadoc comments for the element under the cursor.
*:JavaDocPreview*
Viewing
=======
While editing java code, if you'd like to view the javadoc of the
element under the cursor, you can run the :JavaDocPreview command
which will open vim's preview window with the element's javadoc
content. In the preview window any links to classes, methods, etc. in
the javadoc will be highlighted and you can view follow those links by
hitting <cr> on the link. You can also use <c-o> to navigate back to
the previous javadoc preview and <c-i> to navigate forward.
*:JavaDocSearch*
Searching
=========
Eclim supports searching of javadocs just like you would search the
source code (vim-java-search).
The only difference is that you use :JavaDocSearch instead of
:JavaSearch.
The results will be displayed in a window and you can simply hit <cr>
on an entry to open it using the browser you configured via
g:EclimBrowser (|vim-core-eclim#g:EclimBrowser|).
The locations of the javadocs are determined via your Eclipse
project's .classpath file. For each library entry you can define a
javadoc attribute that points to the base url of the javadoc (http,
file, etc).
>
<classpathentry kind="lib" path="lib/hibernate-3.0.jar">
<attributes>
<attribute value="http://hibernate.org/hib_docs/v3/api" name="javadoc_location"/>
</attributes>
</classpathentry>
<
If you would like to set the javadoc url for your project's source
files, you will instead need to set the
org.eclipse.jdt.ui.project_javadoc_location option via
|:ProjectSettings|. Also note that the javadocs for your source files
are not generated automatically, so if you would like to use
:JavaDocSearch to open your project's javadocs, you will first need to
generate those javadocs as described in the next section.
*:Javadoc*
Executing javadoc
=================
To run the javadoc utility on your project's source code, you may use
the :Javadoc command, which with no arguments will execute javadoc
against all your project's source code (as specified by any optional
settings described below).
If you wish to run javadoc only against one or more files, you can
supply the project relative paths as arguments to the :Javadoc command
and only those files will be used.
Note: Please note that this command is not intended to be a full
replacement for javadoc support provided by more comprehensive build
tools like ant or maven.
Configuration
=============
Eclim Settings (vim-settings)
- org.eclim.user.name - Used as the name portion of the author tag.
Consult the settings page (vim-settings) for more info.
- org.eclim.user.email - Used as the email portion of the author
tag. Consult the settings page (vim-settings) for more info.
- org.eclim.java.doc.dest (Default: doc) - The project relative
directory where the javadocs with be written to.
- org.eclim.java.doc.packagenames - Optional space separated list of
package names to run javadoc against.
- org.eclim.java.doc.sourcepath - The project relative javadoc
sourcepath to use. This should be a space separated list of project
relative source directories which you want javadoc to be executed
against. When unset, all your configured source directories will be
used.
- org.eclipse.jdt.ui.project_javadoc_location - URL where your
project's javadocs can be found.
vim:ft=eclimhelp

104
vim-plugins/bundle/eclim/doc/vim/java/logging.txt Normal file
View file

@ -0,0 +1,104 @@
*vim-java-logging.html*
Logging (log4j, etc)
********************
Auto import / initialize
========================
While editing a java source file, if you start to create a logging
statement (log. or logger.), the logging plugin will attempt to
perform the appropriate initialization (imports, static variable) for
the configured logging implementation.
Eclim provides a handful of templates for the most widely used
implementations (commons-logging, slf4j, log4j, and jdk). However, if
you happen to use an alternate logging framework, or perhaps a home
grown framework, eclim also provides the means to supply a custom
template. To utilize it, simply set the org.eclim.java.logging.impl
setting to "custom" and add your template to
~/.eclim/resources/jdt/templates/logger.gst. Two variables will be
supplied to your template: var, which is the logger instance variable,
and class, which is the class name of the current class you are
implementing.
Here is an example which eclim uses for its logger implementation:
>
import org.eclim.logging.Logger;
private static final Logger ${var} = Logger.getLogger(${class}.class);
<
After performing the necessary variable substitution, eclim will take
any imports and insert them amongst your existing import statements.
The remaining code will be inserted after your class definition.
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimLoggingDisabled*
- g:EclimLoggingDisabled (Default: 0) - If set to a value greater
than 0, then this plugin will be disabled.
Eclim Settings (vim-settings)
*org.eclim.java.logging.impl*
- org.eclim.java.logging.impl (Default: "commons-logging") -
Determines which logging implementation to use.
Possible values include "commons-logging", "slf4j", "log4j", "jdk",
and "custom".
*org.eclim.java.logging.template*
- org.eclim.java.logging.template (Default: 'logger.gst') -
Determines the name of the template to use for the custom logger.
The name must be a file name relative to
~/.eclim/resources/jdt/templates/.
*log4j*
Log4j
=====
Validation
----------
When editing a log4j xml file eclim will default to validating the
file when it is written. Any errors will be added to the current
window's location list (:help location-list) and their corresponding
line number noted via Vim's sign functionality.
Eclim also combines the above validation with xml validation
(vim-xml-index#xml-validation) to validate that the file is well
formed.
If you do not want your log4j files validated automatically when
saved, you can set the |g:EclimLog4jValidate| variable described in
the configuration section below.
*:Validate_log4j*
Whether or not auto validation has been enabled, eclim also exposes
the command :Validate to manually execute the validation of the file.
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimLog4jValidate*
- g:EclimLog4jValidate (Default: 1) - If set to 0, disables
validation when saving the file.
vim:ft=eclimhelp

51
vim-plugins/bundle/eclim/doc/vim/java/maven.txt Normal file
View file

@ -0,0 +1,51 @@
*vim-java-maven.html*
Maven
*****
*:Maven* *:Mvn*
Running
=======
Much like the provided ant (vim-java-ant) execution functionality,
eclim also provides commands for running maven 1.x or 2.x.
Eclim provides the following commands:
>
:Maven [<goal> ...]
:Mvn [<goal> ...]
<
which perform the following steps:
- Save any previous 'makeprg' and 'errorformat' option settings so
that you can define your own settings for the :make command.
- Set 'makeprg' to execute maven or mvn with the --find option so
that it will search for your pom file in the current directory or in
a parent directory.
- Set 'errorformat' to recognize the following errors:
- javac errors.
- javadoc errors.
- junit errors / failures.
- Execute :make.
- Restore your previous 'makeprg' and 'errorformat' option settings.
Additionally, if g:EclimMakeLCD (|vim-core-eclim#g:EclimMakeLCD|) is
enabled (which it is by default), then the execution of maven will be
performed from the current buffer's project root directory, ensuring
that mavens's build file discovery method is performed from the
buffer's working directory and not your own.
Note that :Mvn MUST have this enabled since maven 2.x no longer has
support for the --find option.
Note: Both :Maven and :Mvn also supports use of '!' (:Maven!) just
like :make does, which tells Vim not to jump to the first error if
one exists.
vim:ft=eclimhelp

258
vim-plugins/bundle/eclim/doc/vim/java/methods.txt Normal file
View file

@ -0,0 +1,258 @@
*vim-java-methods.html*
Method Generation
*****************
*:JavaConstructor*
Constructors
============
:JavaConstructor is a command that will create either an empty
constructor, or one that takes any selected fields as arguments.
For example if you have the following class:
>
public class Foo
{
private int id;
private String name;
}
<
If you were to select the range containing the 'id' and 'name' fields
and issue :JavaConstructor, then you would end up with the following
code.
>
public class Foo
{
private int id;
private String name;
/**
* @param id
* @param name
*/
public Foo(int id, String name) {
this.id = id;
this.name = name;
}
}
<
If you issue the command with no fields selected, then a default empty
constructor is created.
When attempting to create an empty constructor, if the super class
doesn't define a default constructor, but instead has one or more
constructors which takes arguments, then calling :JavaConstructor
without a range will result in the creation of a constructor which
overrides the super class constructor containing the least number of
arguments. Although an empty constructor won't pass code validation,
you can force the creation of one in this case by suffixing the
command with a '!':
>
:JavaConstructor!
<
*:JavaGetSet*
Getters / Setters
=================
- :JavaGetSet - Generates both getters and setters for the field
under the cursor or for all fields in the specified range.
*:JavaGet*
- :JavaGet - Generates getters for the field under the cursor or for
all fields in the specified range.
*:JavaSet*
- :JavaSet - Generates setters for the field under the cursor or for
all fields in the specified range.
Note: If you would like to generate the indexed getter or setter
then you can suffix the appropriate command above with '!' and if
the property is an array, an indexed accessor will be created.>
:JavaGetSet!
<
Given the following file:
>
public class Foo
{
private String name;
private Bar[] bars;
}
<
You can place the cursor on one of the fields and execute :JavaGetSet
to generate the getters and setters for the field. All of the above
commands support ranges as well, so you can use a visual selection or
a numbered range to generate methods for a set of fields.
*:JavaImpl*
Override / Impl
===============
Eclim provides the ability to view all the methods that the current
source file can implement or override according to what interfaces it
implements and classes it extends. From the list of methods you can
then choose which you want to implement or override, and the
appropriate method stub will be inserted into the file.
The first step in the process is to execute :JavaImpl which will open
a Vim window containing a list possible methods to implement /
override and the interface / class which defines those methods.
Here is some example content from a class that extends
java.io.InputStream:
>
com.test.TestStream
package java.io;
class InputStream
public int read()
public int read(byte[])
public int read(byte[], int, int)
public long skip(long)
public int available()
public void close()
public void mark(int)
public void reset()
public boolean markSupported ()
package java.lang;
class Object
public int hashCode()
public boolean equals(Object)
protected Object clone()
public String toString()
protected void finalize()
<
From the newly opened window you can select a method to generate a
stub for by simply hitting <enter> with the cursor over the method
signature.
If you would like to generate stubs for all methods in an interface or
class, then simply hit <enter> with the cursor over the class name and
stub methods will be created for each method in that class or
interface.
This functionality supports outer, inner, and anonymous classes
classes. To view the list of methods to override for an inner or
anonymous class, simply execute :JavaImpl with the cursor somewhere in
the body of the inner or anonymous class.
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimJavaImplInsertAtCursor*
- g:EclimJavaImplInsertAtCursor (Default: 0) - By default eclim will
insert methods you've chosen after all the existing methods, but
before any inner classes. If you enable this setting, then the
methods will instead be inserted near where your cursor was when you
first invoked :JavaImpl.
*:JavaDelegate*
Delegate Methods
================
Eclim supports generation of delegate methods via the :JavaDelegate
command. To utilize this functionality you must first place the cursor
on a global field (in the main source file class or within an inner
class), and then invoke the :JavaDelegate command.
In the following source, you can place the cursor anywhere starting
from the first 'p' in private, to the trailing semicolon, and then
invoke the :JavaDelegate command.
>
private List myList;
<
Invoking this command with the cursor on some other source element
will generate the appropriate error.
Once successfully invoked, the result will be the opening of a lower
window with all the methods that may be inserted that will delegate to
the value of the field.
Here is a section of the content displayed when invoking the command
on a field of type java.util.List like the one above.
>
com.test.TestList.myList
package java.util;
interface List
public abstract int size()
public abstract boolean isEmpty()
public abstract boolean contains(Object)
public abstract Object[] toArray()
...
<
From this newly opened window you can select a method by simply
hitting <enter> with the cursor over the method signature and a
delegate method will be created.
For example, if you hit <enter> on the size() method, then the
following code will be inserted.
>
/**
*/
public int size ()
{
return myList.size();
}
<
If you would like to generate delegate methods for all methods in an
interface or class, then simply hit <enter> with the cursor over the
class name, and delegate methods will be created for each method in
that interface or class.
vim:ft=eclimhelp

171
vim-plugins/bundle/eclim/doc/vim/java/refactor.txt Normal file
View file

@ -0,0 +1,171 @@
*vim-java-refactor.html*
Java Refactoring
****************
*:JavaRename*
Rename
======
The first refactoring that eclim supports is :JavaRename, which can be
used to rename various java elements.
Example:
>
package org.foo.bar;
public class Foo {
public void bar(){
}
}
<
To rename the class from 'Foo' to 'Bar' you simply position the cursor
over the class name 'Foo' and execute:
>
:JavaRename Bar
<
The result of which will the following prompt:
>
Rename "Foo" to "Bar"
([e]xecute / [p]review / [c]ancel):
<
This prompt give you three options:
1. execute: Execute the refactoring without previewing the changes
to be made. The current file and any other changed files open in
the current instance of vim will be reloaded.
2. preview: Preview the changes that the refactoring will perform.
This will open a scratch buffer with a list of changes to be made
along with a link at the bottom to execute the refactoring.
The contents of the preview window will vary depending on what you
are renaming.
If we are renaming 'Foo' to 'Bar' the contents would be like so:
>
other: Rename compilation unit 'Foo.java' to 'Bar.java'
|Execute Refactoring|
<
If we are renaming the method 'bar' to 'foo', the contents would
look like so:
>
|diff|: /home/someuser/workspace/test_java/src/org/foo/bar/Foo.java
|Execute Refactoring|
<
If the first instance, there is not much to preview. Since this
particular class is not referenced anywhere else, the only
operation eclipse will perform, is to rename the file from
'Foo.java' to 'Bar.java' which will also update the class name in
that file.
In the second instance eclipse provides a preview of the actual
changes to the file what will be performed. If the method were
referenced elsewhere, you would see an entry for each file that
would be modified by the refactoring. To actually for a vim diff
split of the changes that will be performed, simple position the
cursor on the diff entry and hit <enter>.
Once you are satisfied with changes that eclipse will perform, you
can then execute the refactoring by positioning the cursor over the
"|Execute Refactoring|" link and hit <enter>.
3. cancel: Cancel the refactoring (Hitting enter without typing a
choice or hitting Ctrl-C will also cancel the refactoring).
Package Renaming
Renaming a package is performed just like renaming any other element.
However, the name you supply to the :JavaRename command must be the
full package name that you are renaming the package to. For example.
In sample java file above, if you place the cursor on the 'org'
portion of the package declaration, you can rename 'org' to 'com' by
running :JavaRename com. If you want to rename the 'foo' package to
'baz' you can do so by running :JavaRename org.baz. Note that if you
were to only supply the name 'baz', the 'foo' package would be moved
to the same level as 'org' and then renamed.
Warning: When renaming a package, the associated directory will also
be renamed in the underlying file system. Eclim will do its best to
reload any files that have moved as a result of the directory
renaming and adjust your current working directory if necessary, but
only for the current vim session. If you have other vim sessions
open with files located in the directory that is renamed, then eclim
will be unable to reload those files in those sessions for you, so
you will have to do so manually. A best practice would be to close
any other vim sessions that might be affected by the renaming of a
package.
*:JavaMove*
Move
====
Eclim also supports moving a top level class or interface from one
package to another using the :JavaMove command.
In this example the current file would be moved from its current
package to the package org.foo:
>
:JavaMove org.foo
<
Like the package renaming described in the previous section, the
argument to :JavaMove must be the full package name you want to move
the current file to.
Refactor Undo/Redo
==================
In the event that you need to undo a refactoring, eclim provides the
:RefactorUndo command. When executed, the last refactoring will be
reverted. If you are unsure what the last refactoring was, the
:RefactorUndoPeek command will print the name of the top most
refactoring on the undo stack.
Eclim also provides the :RefactorRedo and :RefactorRedoPeek commands
which provide the redo counterpart to the undo commands.
Configuration
=============
Vim Settings (vim-settings)
*g:EclimRefactorDiffOrientation_java*
- g:EclimRefactorDiffOrientation (Default: 'vertical') - Specifies
the orientation used when previewing a refactoring and performing a
diff split between the current file contents and the changes to be
performed by the refactoring. Possible values include 'vertical' or
'horizontal'.
vim:ft=eclimhelp

246
vim-plugins/bundle/eclim/doc/vim/java/search.txt Normal file
View file

@ -0,0 +1,246 @@
*vim-java-search.html*
Java Search
***********
*:JavaSearch*
Pattern Search
==============
Pattern searching provides a means to widen a search beyond a single
element. A pattern search can be executed using the command
:JavaSearch -p <pattern> [-t <type> -x <context> -s <scope> -i -a
<action>]
When there is more than 1 result, those results will be placed into
vim's quickfix list (:help quickfix) so that you can easily navigate
them using vim's quickfix commands.
Vim command completion is supported through out the command with the
excption of the pattern to search for.
>
:JavaSearch <Tab>
:JavaSearch -p MyClass* <Tab>
:JavaSearch -p MyClass* -t <Tab>
:JavaSearch -p MyClass* -t all <Tab>
:JavaSearch -p MyClass* -t all -x <Tab>
:JavaSearch -p MyClass* -t all -x declarations
<
- -p <pattern>: The pattern to search for.
Ex.
>
MyClass*
MyClass.someMethod*
<
- -t <type> (Default: type): The type of element to search for where
possible types include
- annotation
- class
- classOrEnum
- classOrInterface
- constructor
- enum
- field
- interface
- method
- package
- type
- -x <context> (Default: declarations): The context of the search,
where possible context values include
- all - All occurrences.
- declarations - Declarations matching the pattern or element.
- implementors - Implementors of the pattern or element.
- references - References of the pattern or element.
- -s <scope> (Default: all): The scope of the search where possible
values include
- all - Search the whole workspace.
- project - Search the current project, dependent projects, and
libraries.
- -i: Ignore case when searching.
- -a: The vim command to use to open the result (edit, split,
vsplit, etc).
Eclim also provides a shortcut when issuing a pattern search for a
type. You may simply invoke :JavaSearch supplying only the pattern.
>
:JavaSearch SomeType
<
To shorten things even more, there is support for camel case searching
as well.
>
:JavaSearch NPE
<
However, please note that camel case searching does not permit wild
card characters ('*', '?').
Element Search
==============
Element searching allows you to place the cursor over just about any
element in a source file (method call, class name, field) and perform
a search for that element. Performing an element search is the same
as performing a pattern search with the exception that you do not
specify the -p option since the element under the cursor will be
searched for instead.
If only one result is found and that result is in the current source
file, the cursor will be moved to the element found.
*:JavaSearchContext*
As a convenience eclim also provides the command :JavaSearchContext.
This command accepts only the optional -a argument described above,
and will perform the appropriate search depending on the context of
the element under the cursor.
- If the cursor is on a class or interface declaration, the command
will search for all classes / interfaces that implement / extend the
element.
- If the cursor is on a method or field declaration, the command
will search for all references to the element.
- Otherwise, it will search for the declaration of the element.
Alternate Searching
===================
For those occasions that you find yourself browsing a third party
source distribution that you want to be able to search without going
through the steps of setting up a project, eclim provides an alternate
searching mechanism. To utilize the alternate searching requires no
change in behavior or commands, but to achieve the best results, you
should know how it works.
The first thing worth noting is that the alternate search is currently
a bit limited. It only supports searches involving types (classes,
interfaces, annotations, and enums). It doesn't currently have any
support for methods or fields.
Secondly, it can only search for and locate types within the current
source tree. Searching across the jdk source or other third party
source files without setting up an Eclipse or similar classpath, is
difficult at worst, and slow at best.
With that said, I've found that when I'm walking through a third party
source tree, my main focus is on finding referenced classes /
interfaces quickly and easily, and the eclim alternate searching does
just that.
Invoking the search is the same as the standard search mechanism. You
simply use the same :JavaSearch command as you normally would. The
only difference is that the alternate search doesn't support the -t
option and will notify you of such if supplied.
When invoked, the alternate search will perform the following:
- It will grab the full path of the current source file, strip off
the package and search from the resulting directory.
Ex. When editing a file
/usr/local/java/foo/src/org/foo/bar/Baz.java, the alternate search
will first search the directory /usr/local/java/foo/src.
- If no files are found in that directory, then it will proceed to
search Vim's 'path' option (:h 'path' for more info on this option).
As an example, I have my 'path' set to '/usr/local/java/java-src'
and in that directory is where I store all my third party source
distributions (hibernate, spring, axis, etc.).
- Once one or more files are found, the search will stop if the
requested search was for declarations. For all searches, eclim will
first try to find the declarations and if the user requested a
search for implementors, references, or all, then the eclim will
proceed to the next step.
- For non-declaration searches, if multiple declaring source files
are found, eclim will prompt you to narrow the results down to the
type you would like results for.
- Once eclim has narrowed the search down to the specific type to
proceed with, it will then attempt to narrow the search down to a
specific source distribution directory. To do this it locates the
relevant entry from the 'path' option, tacks on one more level of
the path from the resulting file, and commences its search from
there.
Ex. When searching for all implementors of MyType, if eclim finds a
file /usr/local/java/java-src/myproject/core/src/org/my/MyType.java
and a 'path' entry of /usr/local/java/java-src exists, then eclim
will deduce that that search must continue in the directory
/usr/local/java/java-src/myproject.
This may seem a bit complicated for a simple search, but in practice
it's actually quite simple, and as usual, I'm open to any and all
comments and suggestions.
Note: Alternate searching is bound to the performance of the file
system and as such, the response time on Windows can be
significantly slower than Linux. This is most noticable when
searching for 'implementors', 'references', and 'all'. The number
of and depth of the directories in your Vim 'path' option may also
impact performance.
Configuration
=============
Eclim Settings (vim-settings)
*org.eclim.java.search.sort*
- org.eclim.java.search.sort - Json formatted list of project
releative paths used to sort the search results.
For example, if your projects follow maven hierarchy and you want
the test references to be listed after the main code references,
then you can configure this setting like so:
>
org.eclim.java.search.sort=["src/main", "src/test"]
<
Vim Settings (vim-settings)
*g:EclimJavaSearchSingleResult*
- g:EclimJavaSearchSingleResult (Default: 'split') - Determines what
action to take when a only a single result is found.
Possible values include:
- 'split' - open the result in a new window via "split".
- 'edit' - open the result in the current window.
- 'tabnew' - open the result in a new tab.
This setting overrides the global default for all supported language
types which can be set using the g:EclimDefaultFileOpenAction
setting which accepts the same possible values.
- g:EclimQuickFixOpen (Default: 'botright copen') Specifies the
command used to open the quickfix window when multiple results are
found.
- g:EclimQuickFixHeight (Default: 10) - Sets the height, in lines,
of the quickfix window when eclim opens it to display search
results.
*g:EclimJavaSearchMapping*
- g:EclimJavaSearchMapping (Default: 1) - When set to 1, <enter>
will be mapped to the java search functionality for the various java
related xml files (spring, hibernate, web.xml, and
struts-config.xml).
vim:ft=eclimhelp

51
vim-plugins/bundle/eclim/doc/vim/java/types.txt Normal file
View file

@ -0,0 +1,51 @@
*vim-java-types.html*
Type Creation
*************
*:JavaNew*
Creating a new Class, Interface, etc.
=====================================
:JavaNew is a command that allows you to create new classes,
interfaces, enums, or annotations by specifying which of those you'd
like to create, followed by the fully qualified path of the new type.
The available types you can create include:
- class - a new class
- interface - a new interface
- abstract - a new abstract class
- enum - a new enum
- @interface - a new annotation
Here are some examples:
>
:JavaNew class org.test.MyNewClass
:JavaNew interface org.test.MyNewInterface
<
If you ommit the package name, the new type will be created in the
same package as the file you are currently editing:
>
:JavaNew class MyNewClass
<
Note: This command supports command completion of the available
types (class, interface, etc) as well as completion of existing
package names.
In the case where the source directory to create the type in is
ambiguous, you will be prompted to choose the source directory from a
list.
vim:ft=eclimhelp

233
vim-plugins/bundle/eclim/doc/vim/java/unittests.txt Normal file
View file

@ -0,0 +1,233 @@
*vim-java-unittests.html*
Unit Tests
**********
*:JUnit*
JUnit
=====
Executing tests.
----------------
Eclim's :JUnit command allows you to execute individual test or
individual methods from your tests.
If you'd like to run a particular test you can do so by supplying the
fully qualified class name of the test to run (you can use vim's tab
completion here to alleviate having to type the full name):
>
:JUnit org.test.MyTest
<
Another way is to simply run :JUnit with no arguments and let it
decide what to run based on the current context of the cursor:
- If you have a junit test file open and the cursor is not inside
one of the test methods, then all of the current file's test methods
will be executed.
- If the cursor is on or inside of a test method, then just that
method will be run.
- If you have a regular class open and run :JUnit, eclim will
attempt to locate the corresponding test and run it.
- If the cursor is on or inside of a method in a regular class,
eclim will attempt to locate the test and then locate the
corresponding test method for the current method in that test and
run just that test method.
If you'd like to run all tests for the current file, regardless of
whether the cursor is on a method or not, you can do so by running
:JUnit with the '%' argument:
>
:JUnit %
<
For cases where you'd like to run all your unit tests you can run
:JUnit with the '*' argument and eclim will locate all your test files
and run them:
>
:JUnit *
<
You can also pass in an ant compatible pattern
(http://ant.apache.org/manual/dirtasks.html#patterns) to match the
tests you'd like to run:
>
:JUnit **/tests/*Test
<
*:JUnitFindTest*
Find the test for the current source file.
------------------------------------------
When editing a java file, if you would like to open the corresponding
test, you can issue the command :JUnitFindTest. When the cursor is on
a method in your source file this command will also try to find the
corresponding test method within the test file.
If you run :JUnitFindTest from a test class, eclim will attempt to
find the corresponding class that is being tested.
*:JUnitResult*
Opening test results run from you build tool.
---------------------------------------------
If you are running your unit tests from a build tool like ant or
maven, then you most likely are writing those results to a directory
in your project. If so then you can set the
org.eclim.java.junit.output_dir setting to that location which then
allows you to use the command :JUnitResult to locate and opening the
result file for the currently open test or the test supplied as an
argument.
*:JUnitImpl*
Generating test method stubs.
-----------------------------
While editing junit files, eclim provides functionality to generate
test method stubs similar to the method override / impl (|:JavaImpl|)
functionality provided for non-test-case classes. The only difference
is that instead of :JavaImpl, you use :JUnitImpl to open the window of
possible methods to implement.
To determine what class the current test is for, eclim expects that
the standard naming convention for tests is followed, where the test
has the same fully qualified class name as the target class with a
'Test' suffix.
So for the test org.foo.bar.BazTest, the exepected class being tested
would be org.foo.bar.Baz.
Note: Eclim also supports tests with a 'Test' prefix instead of a
suffix and in the case of neither a 'Test' prefix or suffix, it will
search for a class of the same name in a different package should
you perhaps use a package convention for your tests rather than a
class name convention.
When invoking :JUnitImpl from within org.foo.bar.BazTest, eclim will
locate the class org.foo.bar.Baz and generate a list of methods to
test from it.
When you hit <enter> on the method to add, if that method belongs to a
type in the hierarchy for the class being tested, then the
corresponding test method stub will be inserted, otherwise a regular
overriding stub will be generated.
Configuration
-------------
Eclim Settings (vim-settings)
*org.eclim.java.junit.output_dir*
- org.eclim.java.junit.output_dir - Defines the project relative
location of the junit test results.
Ex.
>
org.eclim.java.junit.output_dir=build/test/results
<
*org.eclim.java.junit.jvmargs*
- org.eclim.java.junit.jvmargs - Json formatted list of strings to
supply as args to the jvm when forking to run unit tests.
Ex.
>
org.eclim.java.junit.jvmargs=["-Xmx512m"]
<
*org.eclim.java.junit.sysprops*
- org.eclim.java.junit.sysprops - Json formatted list of strings to
supply as system properties to the jvm when forking to run unit
tests.
Ex.
>
org.eclim.java.junit.sysprops=["file.encoding=UTF8", "foo.bar=baz"]
<
*org.eclim.java.junit.envvars*
- org.eclim.java.junit.envvars - Json formatted list of strings to
supply as environment variables to the jvm when forking to run unit
tests.
Ex.
>
org.eclim.java.junit.envvars=["FOO=bar"]
<
TestNG
======
Currently eclim's support for TestNG (http://testng.org/doc) is
limited to supporting Vim's :make in conjunction with ant to populate
vim's quickfix results with failed tests.
By default TestNG's output to the console is very terse. So in order
to support monitoring of failed tests via vim's error format, eclim
provides a custom TestNG listener which must be installed into your
build environment.
1. The first step is to place the eclim-testng.jar file in your
TestNG classpath you have configured for ant. You can find this
jar file in your $ECLIPSE_HOME/plugins/org.eclim.jdt_version/
directory.
2. The second step is to add the listener attribute to your testng
task which references the required eclim testng listener:
>
...
<testng ... listener="org.eclim.testng.TestNgListener">
...
<
See the testng ant task docs (http://testng.org/doc/ant.html) for
more information.
Once you have completed that setup, you should then be able to run
your ant target from vim and (as long as eclim is running) all failed
tests will be added to your vim quickfix results.
Ex. Assuming your ant task is named 'test':
>
:Ant test
<
vim:ft=eclimhelp

142
vim-plugins/bundle/eclim/doc/vim/java/validate.txt Normal file
View file

@ -0,0 +1,142 @@
*vim-java-validate.html*
*:Validate_java*
Java Validation / Correction
****************************
Validation
==========
When saving a java source file that resides in a project, eclim will
update that source file in Eclipse and will report any validation
errors found. Any errors will be placed in the current window's
location list (:help location-list) and the corresponding lines in the
source file will be marked via Vim's :sign functionality with '>>'
markers in the left margin.
Automatic validation of java source files can be disabled via the
g:EclimJavaValidate variable (described below). If you choose to
disable automatic validation, you can still use the :Validate command
to manually validate the current file.
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimJavaValidate*
- g:EclimJavaValidate (Default: 1) - If set to 0, disables source
code validation.
Note: When enabled, syntastic
(https://github.com/scrooloose/syntastic) is disabled so that
eclim and syntastic don't step on each other. If you'd like to use
syntastic over eclim for validation, then simply disable eclim's
validation.If you'd like to disable eclim's source code validation
for all languages, eclim provides a global variable for that as
well:>
let g:EclimFileTypeValidate = 0
<
- g:EclimValidateSortResults (Default: 'occurrence') - If set to
'severity', the validation results will be sorted by severity
(errors > warnings > info > etc.)
Eclim settings
*org.eclipse.jdt.core.compiler.source*
- org.eclipse.jdt.core.compiler.source - Determines the target java
vm version (1.2, 1.3, 1.4, 1.5).
*:JavaCorrect*
Code Correction
===============
Code correction in eclim is equivalent to the quick fix functionality
of Eclipse. When you save a java source file, eclim validates () the
file and notes which lines contain errors. To have eclim suggest
possible corrections for an error, you simply place the cursor on the
error line and issue :JavaCorrect.
The result will be a small window opened at the bottom of Vim where
any correction proposals will be noted. To apply a suggested change,
simply move the cursor to the line describing the modification and hit
<enter>. Upon doing so, the change will be applied to the source file.
Example output of :JavaCorrect.
>
The serializable class Foo does not declare a static final serialVersionUID field of type long
0.1227: Add @SuppressWarnings 'serial' to 'Foo'
...
@SuppressWarnings("serial")
public class Foo
implements Serializable
...
<
To apply the above change you would hit <enter> on the line:
>
0.1227: Add @SuppressWarnings 'serial' to 'Foo'
<
Note: Java code corrections are handled just like a refactoring
(vim-java-refactor) so the RefactorUndo (|:RefactorUndo|) and
RefactorRedo (|:RefactorRedo|) commands can be used to undo/redo
corrections that can't be handled by vim's undo (like file moves).
*:Checkstyle*
Checkstyle
==========
When editing a java source file, eclim provides the command
:Checkstyle which will invoke checkstyle
(http://checkstyle.sourceforge.net/) on the current file.
Additionally, you can configure eclim to execute checkstyle
automatically when you save a java source file by setting the eclim
project settings org.eclim.java.checkstyle.onvalidate to true.
Please note that both methods of invoking checkstyle require that you
first configure the location of your checkstyle config file using the
eclim setting org.eclim.java.checkstyle.config, described in the
configuration section below.
Configuration
-------------
Eclim Settings (vim-settings)
*org.eclim.java.checkstyle.config*
- org.eclim.java.checkstyle.config - Defines the location (project
relative or absolute) or your checkstyle config file.
*org.eclim.java.checkstyle.properties*
- org.eclim.java.checkstyle.properties - Defines the location
(project relative or absolute) or your checkstyle properties file.
*org.eclim.java.checkstyle.onvalidate*
- org.eclim.java.checkstyle.onvalidate - When set to true,
checkstyle will be run on the file along with the regular java
validation upon writing the file.
vim:ft=eclimhelp

39
vim-plugins/bundle/eclim/doc/vim/java/webxml.txt Normal file
View file

@ -0,0 +1,39 @@
*vim-java-webxml.html*
WEB-INF/web.xml
***************
Validation
==========
When editing a web.xml file eclim will default to validating the file
when it is written. Any errors will be added to the current window's
location list (:help location-list) and their corresponding line
number noted via Vim's sign functionality.
Eclim also combines the above validation with xml validation
(vim-xml-index#xml-validation) to validate that the file is well
formed.
If you do not want your web.xml files validated automatically when
saved, you can set the |g:EclimWebXmlValidate| variable described in
the configuration section below.
*:Validate_webxml*
Whether or not auto validation has been enabled, eclim also exposes
the command :Validate to manually execute the validation of the file.
Configuration
=============
Vim Settings (vim-settings)
*g:EclimWebXmlValidate*
- g:EclimWebXmlValidate (Default: 1) - If set to 0, disables
validation when saving the file.
vim:ft=eclimhelp

66
vim-plugins/bundle/eclim/doc/vim/javascript/index.txt Normal file
View file

@ -0,0 +1,66 @@
*vim-javascript-index.html*
Javascript
**********
Validation
==========
When editing a javascript file eclim will default to validating the
file when it is written. Any errors will be added to the current
window's location list (:help location-list) and their corresponding
line number noted via Vim's sign functionality.
Javascript validation currently uses JavaScript Lint
(http://www.javascriptlint.com/) to perform the validation. To use it
you will need to first install JavaScript Lint and put it in your
path.
Installing on windows and the mac should be very straight forward
since pre-compiled version for each are available for download on the
JavaScript Lint (http://www.javascriptlint.com/) site. For other unix
based systems (linux, bsd, etc.) the installation procedure is not so
obvious. Here are the steps used to compile and install it on a linux
machine (your paths may vary):
>
$ cd jsl-<version>/src
$ make -f Makefile.ref
# this path will undoubtedly vary on non-linux machines, so watch the
# make output for the real destination.
$ sudo cp Linux_All_DBG.OBJ/jsl /usr/local/bin
<
If you don't want javascript files validated when saving them, you can
set the g:EclimJavascriptValidate variable described in the
configuration section below.
*:Validate_javascript*
Regardless of whether you have validation enabled upon saving or not,
the command :Validate is available to manually execute the validation.
Configuration
=============
Vim Settings (vim-settings)
*g:EclimJavascriptValidate*
- g:EclimJavascriptValidate (Default: 1) - If set to 0, disables
javascript validation when saving the file.
- g:EclimValidateSortResults (Default: 'occurrence') - If set to
'severity', the validation results will be sorted by severity
(errors > warnings > info > etc.)
*g:EclimJavascriptLintConf*
- g:EclimJavascriptLintConf (Default: '~/.jslrc') - Used to set the
location of your jsl config file.
vim:ft=eclimhelp

58
vim-plugins/bundle/eclim/doc/vim/php/buildpath.txt Normal file
View file

@ -0,0 +1,58 @@
*vim-php-buildpath.html*
Php Build Path
**************
Source code completion, searching, and other features make use of the
eclipse dltk's (http://eclipse.org/dltk/) .buildpath to locate
resources. When you first create a dltk project (currently php
(vim-php-index) or ruby (vim-ruby-index)), a .buildpath file is
created in the project's root directory. If your project depends on
any source files located outside your project or in another project,
then you'll need to edit your .buildpath accordingly.
To help you do this, eclim provides several commands to ease the
creation of new build path entries and variables, all of which are
made available when you edit your .buildpath file in vim. Also when
you write the .buildpath file, Vim will issue a command to the eclim
server to update the project's build path, and will report any errors
via vim's location list (:help location-list).
The following is a list of commands that eclim provides while editing
your .buildpath.
*:NewSrcEntry_dltk_php*
- :NewSrcEntry <dir> [<dir> ...] - Adds one or more new entries
which reference source directories in your project.
>
<buildpathentry external="true" kind="lib" path="src/php"/>
<
This command supports command completion of project relative
directories.
*:NewLibEntry_dltk_php*
- :NewLibEntry <dir> [<dir> ...] - Adds one or more new entries
which reference external source directories.
>
<buildpathentry external="true" kind="lib" path="/usr/local/php/cake_1.1.16.5421"/>
<
This command supports command completion of directories.
*:NewProjectEntry_dltk_php*
- :NewProjectEntry <project> [<project> ...] - Adds one or more new
entries which reference other projects.
>
<buildpathentry combineaccessrules="false" kind="prj" path="/test_project"/>
<
This command supports command completion of project names.
vim:ft=eclimhelp

27
vim-plugins/bundle/eclim/doc/vim/php/complete.txt Normal file
View file

@ -0,0 +1,27 @@
*vim-php-complete.html*
Php Code Completion
*******************
Php code completion uses the standard Vim code completion mechanism
(vim-code_completion) like so:
>
<?php
class Test {
function getName () {
}
function getValue () {
}
}
$test = new Test();
$test->get<C-X><C-U>
$test->getName()
?>
<
vim:ft=eclimhelp

29
vim-plugins/bundle/eclim/doc/vim/php/index.txt Normal file
View file

@ -0,0 +1,29 @@
*vim-php-index.html*
Php
***
Features
========
- Php Build Path (vim-php-buildpath)
- Php Code Completion (vim-php-complete)
- Php Validation (vim-php-validate)
- Php Search (vim-php-search)
Suggested Mappings
==================
Here are some mappings for the php funtionality provided by eclim. To
make use of these mappings, simply create a ftplugin file for php and
place your mappings there (:help ftplugin-name).
- The following mapping allows you to simply hit <enter> on an
element to perform a search to find it.
>
nnoremap <silent> <buffer> <cr> :PhpSearchContext<cr>
<
vim:ft=eclimhelp

112
vim-plugins/bundle/eclim/doc/vim/php/search.txt Normal file
View file

@ -0,0 +1,112 @@
*vim-php-search.html*
Php Search
**********
*:PhpSearch*
Pattern Search
==============
Pattern searching provides a means to widen a search beyond a single
element. A pattern search can be executed using the command
:PhpSearch -p <pattern> [-t <type> -s <scope> -i -a <action>]
When there is more than 1 result, those results will be placed into
vim's quickfix list (:help quickfix) so that you can easily navigate
them using vim's quickfix commands.
Vim command completion is supported through out the command with the
exception of the pattern to search for.
>
:PhpSearch <Tab>
:PhpSearch -p MyClass* <Tab>
:PhpSearch -p MyClass* -t <Tab>
:PhpSearch -p MyClass* -t class <Tab>
:PhpSearch -p MyClass* -t class -s <Tab>
:PhpSearch -p MyClass* -t class -s project
<
- -p <pattern>: The pattern to search for.
Ex.
>
MyClass
myFunction
my*
<
- -t <type> (Default: all): The type of element to search for where
possible types include
- class
- function
- field
- -s <scope> (Default: all): The scope of the search where possible
values include
- all - Search the whole workspace.
- project - Search the current project, dependent projects, and
libraries.
- -i: Ignore case when searching.
- -a: The vim command to use to open the result (edit, split,
vsplit, etc).
Element Search
==============
Element searching allows you to place the cursor over just about any
element in a source file (method call, class name, constant) and
perform a search for that element. Performing an element search is
the same as performing a pattern search with the exception that you do
not specify the -p option since the element under the cursor will be
searched for instead.
If only one result is found and that result is in the current source
file, the cursor will be moved to the element found. Otherwise, on
single result matches, the value of |g:EclimPhpSearchSingleResult|
will be consulted for the action to take. If there are multiple
results, the quickfix list will be opened with the list of results.
*:PhpSearchContext*
As a convenience eclim also provides the command :PhpSearchContext.
This command accepts only the optional -a argument described above,
and will perform the appropriate search depending on the context of
the element under the cursor.
- If the cursor is on the file name in a require or include call, it
will search the configured include path for the file.
- Otherwise, it will search for the declaration of the element.
Configuration
=============
Vim Settings (vim-settings)
*g:EclimPhpSearchSingleResult*
- g:EclimPhpSearchSingleResult (Default: 'split') - Determines what
action to take when a only a single result is found.
Possible values include:
- 'split' - open the result in a new window via "split".
- 'edit' - open the result in the current window.
- 'tabnew' - open the result in a new tab.
This setting overrides the global default for all supported language
types which can be set using the g:EclimDefaultFileOpenAction
setting which accepts the same possible values.
- g:EclimQuickFixOpen (Default: 'botright copen') Specifies the
command used to open the quickfix window when multiple results are
found.
- g:EclimQuickFixHeight (Default: 10) - Sets the height, in lines,
of the quickfix window when eclim opens it to display search
results.
vim:ft=eclimhelp

57
vim-plugins/bundle/eclim/doc/vim/php/validate.txt Normal file
View file

@ -0,0 +1,57 @@
*vim-php-validate.html*
*:Validate_php*
Php Validation
**************
When saving a php source file that resides in a project, eclim will
update that source file in Eclipse and will report any validation
errors found. Any errors will be placed in the current window's
location list (:help location-list) and the corresponding lines in the
source file will be marked via Vim's :sign functionality with '>>'
markers in the left margin.
Automatic validation of php source files can be disabled via the
g:EclimPhpValidate variable (described below). If you choose to
disable automatic validation, you can still use the :Validate command
to manually validate the current file.
Configuration
=============
Vim Settings (vim-settings)
*g:EclimPhpValidate*
- g:EclimPhpValidate (Default: 1) - If set to 0, disables source
code validation.
Note: When enabled, syntastic
(https://github.com/scrooloose/syntastic) is disabled so that
eclim and syntastic don't step on each other. If you'd like to use
syntastic over eclim for validation, then simply disable eclim's
validation.If you'd like to disable eclim's source code validation
for all languages, eclim provides a global variable for that as
well:>
let g:EclimFileTypeValidate = 0
<
- g:EclimPhpHtmlValidate (Default: 0) - If set to a non 0 value,
enables validating html markup in the php file. Enabling of html
validation can also be enabled on a per buffer basis using a buffer
local setting:
>
let b:EclimPhpHtmlValidate = 1
<
- g:EclimValidateSortResults (Default: 'occurrence') - If set to
'severity', the validation results will be sorted by severity
(errors > warnings > info > etc.)
vim:ft=eclimhelp

21
vim-plugins/bundle/eclim/doc/vim/python/complete.txt Normal file
View file

@ -0,0 +1,21 @@
*vim-python-complete.html*
Python Code Completion
**********************
Python code completion uses the standard Vim code completion mechanism
(vim-code_completion) like so:
>
class Test (object):
def testMethod (self):
pass
t = Test()
t.te<C-X><C-U>
t.testMethod
<
vim:ft=eclimhelp

285
vim-plugins/bundle/eclim/doc/vim/python/django.txt Normal file
View file

@ -0,0 +1,285 @@
*vim-python-django.html*
Django
******
*:DjangoManage*
Django manage.py
================
For each project you create with the django framework, django provides
you with a manage.py which can be used to perform various tasks. To
make the invocation of the manage.py script even easier, eclim
provides the command :DjangoManage which can be invoked from any file
in the same directory as your manage.py or in any of the child
directories.
:DjangoManage supports all the same commands as manage.py and supports
command line completion of command names and app names where
supported.
Several of the manage.py commands simply perform an action without
generating much if any output. However there is also a set of
commands which generate sql statements. For all of these commands,
instead of just running the command in a shell, :DjangoManage will run
the command and populate a new buffer with the resulting output and
set the proper file type.
Configuration
=============
Vim Settings (vim-settings)
*g:EclimDjangoAdmin*
- g:EclimDjangoAdmin (Default: 'django-admin.py') - This setting
specifies the location of your django-admin.py file. By default it
will attempt to locate it in your system path, but you can
optionally set an absolute path for eclim to use. Eclim currently
only needs access to this script when running :DjangoManage
startproject <project_name> [destination]. All other :DjangoManage
commands will use your project's manage.py.
Django python support
=====================
*:DjangoTemplateOpen*
Locating templates
The command :DjangoTemplateOpen supports finding and opening a
template referenced under the cursor.
Ex.
>
# w/ cursor on 'mytemplates/mytemplate.html'
return render_to_response('mytemplates/mytemplate.html', ...)
<
*:DjangoViewOpen*
Locating views
The command :DjangoViewOpen supports finding and opening a view
referenced under the cursor.
Ex.
>
# w/ cursor on 'myproject.myapp.views' or 'my_view' on the second line.
urlpatterns = patterns('myproject.myapp.views',
(r'^$', 'my_view'),
)
<
*:DjangoContextOpen*
Contextually locate file
The command :DjangoContextOpen supports executing :DjangoViewOpen,
:DjangoTemplateOpen, or :PythonSearchContext depending on the
context of the text under the cursor.
Specifying the open command to use
All of the above :Django*Open commands support an optional -a
argument to specify the vim command used to open the result:
- -a: The vim command to use to open the result (edit, split,
tabnew, etc).
*htmldjango*
Django html template support
============================
Syntax
Vim ships with a syntax file for django html template files, but
eclim builds on that base to support highlighting of user defined
tags and filters (see the configuration section below.
Indent
Using the same settings as the enhanced syntax file, eclim also
ships with an indent script which provides indentation support all
of the default django tags and any user defined tags that have been
configured.
Match It
Again, using the same set of variables, eclim sets the necessary
variables to allow proper matchit.vim support for django default
and user defined tags.
End Tag Completion
Using the |g:HtmlDjangoUserBodyElements| setting along with the
pre-configured default list of body elements, eclim includes
support for auto completion of ending template tags when you type
an {%e or {% e.
*:DjangoFind*
Contextual Find
While editing django html templates, the command :DjangoFind which
will attempt to locate the relevant resource depending on what is
under the cursor.
- If on a user defined tag, attempt to find the tag definition
within the python tag definition file.
Ex.
>
{# w/ cursor on 'mytag' #}
{% mytag somearg %}
<
- If on a user defined filter, attempt to find the filter
definition within the python filter definition file.
Ex.
>
{# w/ cursor on 'myfilter' #}
{{ somevalue|myfilter }}
<
- If on the tag/filter definition portion of of a 'load' tag,
attempt to find the definition file.
Ex.
>
{# w/ cursor on 'mytags' #}
{% load mytags %}
<
- If on a reference to a template for ethier an 'extends' or
'include' tag, attempt to find that template file.
Ex.
>
{# w/ cursor on 'include/mytemplate.html' #}
{% include "include/mytemplate.html" %}
<
- If on static file reference, as defined in a 'src' or 'href'
attribute of an element, attempt to find that static file.
Ex.
>
{# w/ cursor on '/css/my.css' #}
<link rel="stylesheet" href="/css/my.css" type="text/css" />
<
Note: this functionality requires that g:EclimDjangoStaticPaths
is set to a list of absolute or django project relative (relative
to directory containing manage.py and settings.py) directories,
though it will fallback to using eclim's locate file
functionality.
Ex.
>
let g:EclimDjangoStaticPaths = ["../static/"]
<
Like the :Django*Open commands, :DjangoFind supports an optional -a
<action> argument to specify the vim command used to open the
resulting file.
Configuration
=============
Vim Settings (vim-settings)
*g:HtmlDjangoUserBodyElements*
- g:HtmlDjangoUserBodyElements - List of lists, where each list
contains the name of the start and end tag, as well as any
intermediary tags of any custom tags which have a body.
Ex.
>
let g:HtmlDjangoUserBodyElements = [
\ ['repeat', 'endrepeat'],
\ ['try', 'except', 'finally', 'endtry'],
\ ]
<
This setting is used for indentation of the custom tag's body, as
well as arguments for proper matchit support, end tag completion,
and syntax highlighting.
*g:HtmlDjangoUserTags*
- g:HtmlDjangoUserTags - This setting is a list of any non-body tags
which don't require indentation or matchit support. The items
configured here will be used for syntax highlighting.
*g:HtmlDjangoUserFilters*
- g:HtmlDjangoUserFilters - This settings contains a list of any
user defined django filters. It is currently used for syntax
highlighting.
*g:HtmlDjangoCompleteEndTag*
- g:HtmlDjangoCompleteEndTag (Default: 1) - When set to 0, disables
the auto completion of end tags.
*g:EclimDjangoStaticPaths*
- g:EclimDjangoStaticPaths - Used as a list of directories to search
when looking for static files (js, css, etc). Expected to be a list
of absolute or django project relative (relative to directory
containing manage.py and settings.py) directories.
Ex.
>
let g:EclimDjangoStaticPaths = ["../static/"]
<
*g:EclimDjangoStaticPattern*
- g:EclimDjangoStaticPattern - If you have a custom tag to load
static files, then eclim by default may not be able to determine
that it should be attempting to search for the static file
referenced by that custom tag. In this case you can set
g:EclimDjangoStaticPattern to a vim regular expression which matches
your custom tag. For example, if you have a custom tag called static
to load static files like so:
>
{% static 'lib/somefile.js' %}
<
Then you could set g:EclimDjangoStaticPattern to:
>
let g:EclimDjangoStaticPattern = "{%\\s*static(['\"]<element>['\"]"
<
Note that this pattern allows either ' or " to quote the static file
path and since we are doing this we need to use double quotes around
the pattern which in turn means that we need to double escape back
slashes (note the double backslashes when matching 0 or more spaces:
\\s*). Also note that the <element> portion of the pattern will be
replaced with the path of the static file that eclim extracted while
the cursor was over that portion of the tag.
*g:EclimDjangoFindAction*
- g:EclimDjangoFindAction (Default: "split") - For :DjangoFind and
:DjangoTemplateOpen, used as the action to perform on the file
found.
vim:ft=eclimhelp

41
vim-plugins/bundle/eclim/doc/vim/python/index.txt Normal file
View file

@ -0,0 +1,41 @@
*vim-python-index.html*
Python
******
Features
========
- Python Interpreter / Paths (vim-python-path)
- Python Validation (vim-python-validate)
- Python Code Completion (vim-python-complete)
- Python Search (vim-python-search)
- Django (vim-python-django)
Suggested Mappings
==================
Here are some mappings for the python funtionality provided by eclim.
To make use of these mappings, simply create a ftplugin file for
python and place your mappings there (:help ftplugin-name).
- The following mapping allows you to simply hit <enter> on an
element to perform a search to find its definition or occurrences
depending on the context.
>
nnoremap <silent> <buffer> <cr> :PythonSearchContext<cr>
<
- If you are doing django development you may want to use the
following mapping instead which also supports locating django
templates when executed over a quoted template path in a view, or
locating django views when executed on a quoted view name in a
urls.py file.
>
nnoremap <silent> <buffer> <cr> :DjangoContextOpen<cr>
<
vim:ft=eclimhelp

100
vim-plugins/bundle/eclim/doc/vim/python/path.txt Normal file
View file

@ -0,0 +1,100 @@
*vim-python-path.html*
Python Interpreter / Paths
**************************
Python code completion, searching, and other features require that you
first create a python (pydev) project:
>
:ProjectCreate path/to/project -n python
<
If you haven't already configured a python interpreter, then you will
be prompted to do so when creating your first python project. When
creating your project a .pydevproject file will be also be created.
This file is used to define which interpreter to use for your project,
the location of your project's python source files, and the location
of any third party libraries your project requires (if not already on
your project's interpreter path).
Note: When saving the .pydevproject file from within vim, eclim will
update your project's configuration in memory or report any errors
raised by pydev.Also note that although the .pydevproject file is
xml, pydev doesn't handle stripping leading/trailing space or new
lines from xml text values, so refrain from attempting to format
this file and try to stick to using the commands below to configure
your project.
Interpreter
===========
Eclim provides commands to help you manage python interpreters
available to pydev projects as well as which interpreter to use for
each of your projects.
*:PythonInterpreterAdd*
- :PythonInterpreterAdd [-n <name>] </path/to/pythonX> Command to
add a new interpreter to pydev which will then be available to your
projects. If you supply only the path to the interpreter, then eclim
will set the name of that interpreter to the basename of the path
supplied.
>
:PythonInterpreterAdd /usr/bin/python3
:PythonInterpreterAdd -n python3.3 /usr/bin/python3
<
*:PythonInterpreterRemove*
- :PythonInterpreterRemove </path/of/pythonX> Command to remove an
interpreter from pydev.
>
:PythonInterpreterRemove /usr/bin/python3
<
*:PythonInterpreterList*
- :PythonInterpreterList Command to list all interpreters configured
with pydev.
*:PythonInterpreter*
- :PythonInterpreter [<interpreter_name or /path/to/interpreter>]
When invoked with no arguments this command will print out the path
to the python interpreter currently set for your project. This
command can also be use to set your project's interpreter by
supplying either the name of an interpreter already configured with
pydev (via |:PythonInterpreterAdd|), or the absolute path to an
interpreter on your system.
>
:PythonInterpreter python_2.7
:PythonInterpreter /usr/bin/python3
<
This command supports command completion of interpreter names or
paths (if you start typing an absolute path).
Paths
=====
*:NewSrcEntry_pydev*
- :NewSrcEntry <dir> - Add a new source entry which references a
source directory in your project.
>
<path>/myproject/src</path>
<
This command supports command completion of project relative
directories.
vim:ft=eclimhelp

80
vim-plugins/bundle/eclim/doc/vim/python/search.txt Normal file
View file

@ -0,0 +1,80 @@
*vim-python-search.html*
Python Search
*************
*:PythonSearch*
Element Search
==============
Element searching allows you to place the cursor over just about any
element in a source file (method call, class name, constant) and
perform a search for that element by issuing the command
:PythonSearch. By default this command will search for declarations,
but you can specify that you want to search for references using:
>
:PythonSearch -x references
<
If only one result is found and that result is in the current source
file, the cursor will be moved to the element found. Otherwise, on
single result matches, the value of |g:EclimPythonSearchSingleResult|
will be consulted for the action to take. If there are multiple
results, the quickfix list will be opened with the list of results.
You can also force the action to use for the current search by
suppling the -a <action> arg:
>
:PythonSearch -x references -a edit
<
Note: :PythonSearch does not currently support searching for
patterns. Attempting to supply a pattern to search for will result
in an error.
*:PythonSearchContext*
As a convenience eclim also provides the command :PythonSearchContext.
This command accepts only the optional -a argument described above,
and will perform the appropriate search depending on the context of
the element under the cursor.
- If the cursor is on the declaration of a class, function, or
method then it will search for all occurrences.
- Otherwise, it will search for the declaration of the element.
Configuration
=============
Vim Settings (vim-settings)
*g:EclimPythonSearchSingleResult*
- g:EclimPythonSearchSingleResult (Default: 'split') - Determines
what action to take when a only a single result is found.
Possible values include:
- 'split' - open the result in a new window via "split".
- 'edit' - open the result in the current window.
- 'tabnew' - open the result in a new tab.
This setting overrides the global default for all supported language
types which can be set using the g:EclimDefaultFileOpenAction
setting which accepts the same possible values.
- g:EclimQuickFixOpen (Default: 'botright copen') Specifies the
command used to open the quickfix window when multiple results are
found.
- g:EclimQuickFixHeight (Default: 10) - Sets the height, in lines,
of the quickfix window when eclim opens it to display search
results.
vim:ft=eclimhelp

47
vim-plugins/bundle/eclim/doc/vim/python/validate.txt Normal file
View file

@ -0,0 +1,47 @@
*vim-python-validate.html*
Python Validation
*****************
When editing a python file eclim will default to validating the file
when it is written. Any errors will be added to the current window's
location list (:help location-list) and their corresponding line
number noted via Vim's sign functionality.
If you don't want python files validated when saving them, you can set
the g:EclimPythonValidate variable described in the configuration
section below.
*:Validate_python*
Regardless of whether you have validation enabled upon saving or not,
the command :Validate is available to manual validate the file.
Configuration
=============
Vim Settings (vim-settings)
*g:EclimPythonValidate*
- g:EclimPythonValidate (Default 1) - If set to 0, disables python
validation when saving the file.
Note: When enabled, syntastic
(https://github.com/scrooloose/syntastic) is disabled so that
eclim and syntastic don't step on each other. If you'd like to use
syntastic over eclim for validation, then simply disable eclim's
validation.If you'd like to disable eclim's source code validation
for all languages, eclim provides a global variable for that as
well:>
let g:EclimFileTypeValidate = 0
<
- g:EclimValidateSortResults (Default: 'occurrence') - If set to
'severity', the validation results will be sorted by severity
(errors > warnings > info > etc.)
vim:ft=eclimhelp

42
vim-plugins/bundle/eclim/doc/vim/refactoring.txt Normal file
View file

@ -0,0 +1,42 @@
*vim-refactoring.html*
Refactoring
***********
Described below are some common commands and configuration for eclim's
refactoring support.
Note: Eclim does not provide refactoring support for all languages,
so be sure to check the available features for the language of your
choice.
*:RefactorUndo* *:RefactorRedo* *:RefactorUndoPeek*
Refactor Undo/Redo
==================
In the event that you need to undo a refactoring, eclim provides the
:RefactorUndo command. When executed, the last refactoring will be
reverted. If you are unsure what the last refactoring was, the
:RefactorUndoPeek command will print the name of the top most
refactoring on the undo stack.
Eclim also provides the :RefactorRedo and :RefactorRedoPeek commands
which provide the redo counterpart to the undo commands.
Configuration
=============
Vim Settings (vim-settings)
*g:EclimRefactorDiffOrientation*
- g:EclimRefactorDiffOrientation (Default: 'vertical') - Specifies
the orientation used when previewing a refactoring and performing a
diff split between the current file contents and the changes to be
performed by the refactoring. Possible values include 'vertical' or
'horizontal'.
vim:ft=eclimhelp

113
vim-plugins/bundle/eclim/doc/vim/ruby/buildpath.txt Normal file
View file

@ -0,0 +1,113 @@
*vim-ruby-buildpath.html*
Ruby Interpreters / Build Path
******************************
*:RubyInterpreterAdd* *:RubyInterpreterRemove* *:RubyInterpreterList*
Interpreters
============
When creating your first ruby project you will be prompted to
configure a new interpreter if you haven't already done so in eclipse.
You can also manually manage your ruby interpreters with the following
commands:
- :RubyInterpreterAdd [-n <name>] <path> - Add a ruby interpreter.
- :RubyInterpreterRemove <path> - Remove a ruby interpreter.
- :RubyInterpreterList - List the available ruby interpreters.
If you have more than one interpreter configured when you create
subsequent projects you will be prompted to choose the interpreter to
use. If you remove an interpreter used by one of your projects, you'll
have to go back to that project and edit its .buildpath file and
change the interpreter name in the container entry.
Example (wrapped for readability): Changing ruby1.9 to ruby1.8:
>
<buildpathentry kind="con"
path="org.eclipse.dltk.launching.INTERPRETER_CONTAINER/
org.eclipse.dltk.internal.debug.ui.launcher.GenericRubyInstallType/ruby1.9"/>
<
>
<buildpathentry kind="con"
path="org.eclipse.dltk.launching.INTERPRETER_CONTAINER/
org.eclipse.dltk.internal.debug.ui.launcher.GenericRubyInstallType/ruby1.8"/>
<
If there is no suffix on the container entry, that project will be
using what ever is he default interpreter:
>
<buildpathentry kind="con"
path="org.eclipse.dltk.launching.INTERPRETER_CONTAINER"/>
<
Build Path
==========
Source code completion, searching, and other features make use of the
eclipse dltk's (http://eclipse.org/dltk/) .buildpath to locate
resources. When you first create a dltk project (currently php
(vim-php-index) or ruby (vim-ruby-index)), a .buildpath file is
created in the project's root directory. If your project depends on
any source files located outside your project or in another project,
then you'll need to edit your .buildpath accordingly.
To help you do this, eclim provides several commands to ease the
creation of new build path entries and variables, all of which are
made available when you edit your .buildpath file in vim. Also when
you write the .buildpath file, Vim will issue a command to the eclim
server to update the project's build path, and will report any errors
via vim's location list (:help location-list).
The following is a list of commands that eclim provides while editing
your .buildpath.
*:NewSrcEntry_dltk_ruby*
- :NewSrcEntry <dir> [<dir> ...] - Adds one or more new entries
which reference source directories in your project.
>
<buildpathentry external="true" kind="lib" path="src/php"/>
<
This command supports command completion of project relative
directories.
*:NewLibEntry_dltk_ruby*
- :NewLibEntry <dir> [<dir> ...] - Adds one or more new entries
which reference external source directories.
>
<buildpathentry external="true" kind="lib" path="/usr/local/php/cake_1.1.16.5421"/>
<
This command supports command completion of directories.
*:NewProjectEntry_dltk_ruby*
- :NewProjectEntry <project> [<project> ...] - Adds one or more new
entries which reference other projects.
>
<buildpathentry combineaccessrules="false" kind="prj" path="/test_project"/>
<
This command supports command completion of project names.
vim:ft=eclimhelp

25
vim-plugins/bundle/eclim/doc/vim/ruby/complete.txt Normal file
View file

@ -0,0 +1,25 @@
*vim-ruby-complete.html*
Ruby Code Completion
********************
Ruby code completion uses the standard Vim code completion mechanism
(vim-code_completion) like so:
>
class Test
def getName()
end
def getValue()
end
end
test = Test.new
test.get<C-X><C-U>
test.getName()
<
vim:ft=eclimhelp

11
vim-plugins/bundle/eclim/doc/vim/ruby/index.txt Normal file
View file

@ -0,0 +1,11 @@
*vim-ruby-index.html*
Ruby
****
- Ruby Interpreters / Build Path (vim-ruby-buildpath)
- Ruby Code Completion (vim-ruby-complete)
- Ruby Validation (vim-ruby-validate)
- Ruby Search (vim-ruby-search)
vim:ft=eclimhelp

117
vim-plugins/bundle/eclim/doc/vim/ruby/search.txt Normal file
View file

@ -0,0 +1,117 @@
*vim-ruby-search.html*
Ruby Search
***********
*:RubySearch*
Pattern Search
==============
Pattern searching provides a means to widen a search beyond a single
element. A pattern search can be executed using the command
:RubySearch -p <pattern> [-t <type> -s <scope> -i -a <action>]
When there is more than 1 result, those results will be placed into
vim's quickfix list (:help quickfix) so that you can easily navigate
them using vim's quickfix commands.
Vim command completion is supported through out the command with the
exception of the pattern to search for.
>
:RubySearch <Tab>
:RubySearch -p MyClass* <Tab>
:RubySearch -p MyClass* -t <Tab>
:RubySearch -p MyClass* -t class <Tab>
:RubySearch -p MyClass* -t class -s <Tab>
:RubySearch -p MyClass* -t class -s project
<
- -p <pattern>: The pattern to search for.
Ex.
>
MyClass
myFunction
my*
<
- -t <type> (Default: all): The type of element to search for where
possible types include
- class
- method
- field
- -x <context> (Default: declarations): The context of the search,
where possible values include
- all - All occurances.
- declarations - Declarations matching the pattern or element.
- references - References of the pattern or element.
- -s <scope> (Default: all): The scope of the search where possible
values include
- all - Search the whole workspace.
- project - Search the current project, dependent projects, and
libraries.
- -i: Ignore case when searching.
- -a: The vim command to use to open the result (edit, split,
vsplit, etc).
Element Search
==============
Element searching allows you to place the cursor over just about any
element in a source file (method call, class name, constant) and
perform a search for that element. Performing an element search is
the same as performing a pattern search with the exception that you do
not specify the -p option since the element under the cursor will be
searched for instead.
If only one result is found and that result is in the current source
file, the cursor will be moved to the element found. Otherwise, on
single result matches, the value of |g:EclimRubySearchSingleResult|
will be consulted for the action to take. If there are multiple
results, the quickfix list will be opened with the list of results.
*:RubySearchContext*
As a convenience eclim also provides the command :RubySearchContext.
This command accepts only the optional -a argument described above,
and will perform the appropriate search depending on the context of
the element under the cursor.
- If the cursor is on a the definition of a method, class, module,
etc. then a search will be performed for all uses of that element.
- Otherwise, it will search for the declaration of the element.
Configuration
=============
Vim Settings (vim-settings)
*g:EclimRubySearchSingleResult*
- g:EclimRubySearchSingleResult (Default: 'split') - Determines what
action to take when a only a single result is found.
Possible values include:
- 'split' - open the result in a new window via "split".
- 'edit' - open the result in the current window.
- 'tabnew' - open the result in a new tab.
This setting overrides the global default for all supported language
types which can be set using the g:EclimDefaultFileOpenAction
setting which accepts the same possible values.
- g:EclimQuickFixOpen (Default: 'botright copen') Specifies the
command used to open the quickfix window when multiple results are
found.
- g:EclimQuickFixHeight (Default: 10) - Sets the height, in lines,
of the quickfix window when eclim opens it to display search
results.
vim:ft=eclimhelp

48
vim-plugins/bundle/eclim/doc/vim/ruby/validate.txt Normal file
View file

@ -0,0 +1,48 @@
*vim-ruby-validate.html*
*:Validate_ruby*
Ruby Validation
***************
When saving a ruby source file that resides in a project, eclim will
update that source file in Eclipse and will report any validation
errors found. Any errors will be placed in the current window's
location list (:help location-list) and the corresponding lines in the
source file will be marked via Vim's :sign functionality with '>>'
markers in the left margin.
Automatic validation of ruby source files can be disabled via the
g:EclimRubyValidate variable (described below). If you choose to
disable automatic validation, you can still use the :Validate command
to manually validate the current file.
Configuration
=============
Vim Settings (vim-settings)
*g:EclimRubyValidate*
- g:EclimRubyValidate (Default: 1) - If set to 0, disables source
code validation.
Note: When enabled, syntastic
(https://github.com/scrooloose/syntastic) is disabled so that
eclim and syntastic don't step on each other. If you'd like to use
syntastic over eclim for validation, then simply disable eclim's
validation.If you'd like to disable eclim's source code validation
for all languages, eclim provides a global variable for that as
well:>
let g:EclimFileTypeValidate = 0
<
- g:EclimValidateSortResults (Default: 'occurrence') - If set to
'severity', the validation results will be sorted by severity
(errors > warnings > info > etc.)
vim:ft=eclimhelp

22
vim-plugins/bundle/eclim/doc/vim/scala/complete.txt Normal file
View file

@ -0,0 +1,22 @@
*vim-scala-complete.html*
Scala Code Completion
*********************
Scala code completion uses the standard Vim code completion mechanism
(vim-code_completion) like so:
>
package eclim.test
class Test {
def test(){
val list = List("foo", "bar", "baz")
list.s<C-X><C-U>
}
}
<
vim:ft=eclimhelp

35
vim-plugins/bundle/eclim/doc/vim/scala/import.txt Normal file
View file

@ -0,0 +1,35 @@
*vim-scala-import.html*
*:ScalaImport*
Automated Imports
*****************
The automated import functionality is pretty straightforward. Simply
place the cursor over the element to import and issue the command:
:ScalaImport
and one of the following events will occur:
- If only one matching element is found, its import statement will
be placed in the file.
- If multiple matching elements are found, you will be prompted to
choose the element you wish to import from a list.
- If an element with the same name is already imported then no
changes will occur.
Note: Like the scala-ide (as of the time of this writting), imports
are simply appended to the end of your file's import block. There is
no attempt made to sort or group imports.
Configuration
=============
Eclim Settings (vim-settings)
- |org.eclim.java.import.exclude| - Scala importing honors the java
import exclussion setting.
vim:ft=eclimhelp

11
vim-plugins/bundle/eclim/doc/vim/scala/index.txt Normal file
View file

@ -0,0 +1,11 @@
*vim-scala-index.html*
Scala
*****
- Scala Code Completion (vim-scala-complete)
- Scala Validation (vim-scala-validate)
- Scala Search (vim-scala-search)
- Automated Imports (vim-scala-import)
vim:ft=eclimhelp

51
vim-plugins/bundle/eclim/doc/vim/scala/search.txt Normal file
View file

@ -0,0 +1,51 @@
*vim-scala-search.html*
*:ScalaSearch*
Scala Search
************
Eclim's scala searching currently supports searching for the
definition of the element under the cursor. Simply place the cursor on
the element you wish to search for and run :ScalaSearch. If the
definition of the element is found, the corresponding file will be
opened and the cursor placed on the element's definition. The command
used to open the result can be defined usin the
|g:EclimScalaSearchSingleResult| variable or on a per search basis by
supplying the -a <action> arg:
>
:ScalaSearch -a edit
<
Configuration
=============
Vim Settings (vim-settings)
*g:EclimScalaSearchSingleResult*
- g:EclimScalaSearchSingleResult (Default: 'split') - Determines
what action to take when a only a single result is found.
Possible values include:
- 'split' - open the result in a new window via "split".
- 'edit' - open the result in the current window.
- 'tabnew' - open the result in a new tab.
This setting overrides the global default for all supported language
types which can be set using the g:EclimDefaultFileOpenAction
setting which accepts the same possible values.
- g:EclimQuickFixOpen (Default: 'botright copen') Specifies the
command used to open the quickfix window when multiple results are
found.
- g:EclimQuickFixHeight (Default: 10) - Sets the height, in lines,
of the quickfix window when eclim opens it to display search
results.
vim:ft=eclimhelp

35
vim-plugins/bundle/eclim/doc/vim/scala/validate.txt Normal file
View file

@ -0,0 +1,35 @@
*vim-scala-validate.html*
*:Validate_scala*
Scala Validation
****************
When saving a scala source file that resides in a project, eclim will
update that source file in Eclipse and will report any validation
errors found. Any errors will be placed in the current window's
location list (:help location-list) and the corresponding lines in the
source file will be marked via Vim's :sign functionality with '>>'
markers in the left margin.
Automatic validation of scala source files can be disabled via the
g:EclimScalaValidate variable (described below). If you choose to
disable automatic validation, you can still use the :Validate command
to manually validate the current file.
Configuration
=============
Vim Settings (vim-settings)
*g:EclimScalaValidate*
- g:EclimScalaValidate (Default: 1) - If set to 0, disables source
code validation.
- g:EclimValidateSortResults (Default: 'occurrence') - If set to
'severity', the validation results will be sorted by severity
(errors > warnings > info > etc.)
vim:ft=eclimhelp

10
vim-plugins/bundle/eclim/doc/vim/search.txt Normal file
View file

@ -0,0 +1,10 @@
*vim-search.html*
- g:EclimQuickFixOpen (Default: 'botright copen') Specifies the
command used to open the quickfix window when multiple results are
found.
- g:EclimQuickFixHeight (Default: 10) - Sets the height, in lines,
of the quickfix window when eclim opens it to display search
results.
vim:ft=eclimhelp

38
vim-plugins/bundle/eclim/doc/vim/settings.txt Normal file
View file

@ -0,0 +1,38 @@
*vim-settings.html*
Settings
********
Certain aspects of eclim can be controlled by modifying one or more
settings. There are two types of settings available:
Eclim daemon settings
=====================
These are settings that reside in your Eclipse workspace or project
and are used to configure the behavior of the eclim daemon,
independent of which client you use (vim, emacs, etc).
These settings can be viewed and modified using one of the following
commands:
- :WorkspaceSettings (|vim-core-eclim#:WorkspaceSettings|): Edit
non-project dependent settings, or define defaults for settings not
overridden at the project level.
- |:ProjectSettings|: Define the settings for the current project.
Vim client settings
===================
These are the settings you use to control how vim (the primary eclimd
client) behaves. You can edit these settings one of two ways:
- :VimSettings (|vim-core-eclim#:VimSettings|): Allows you to view
and edit all of eclim's vim client settings. Settings edited here
will be stored at $HOME/.eclim/.eclim_settings.
- Alternately, you can add the equivalent g:EclimXXX setting to your
vimrc or an ftplugin file, and that setting will take precedence
over any value set using :VimSettings.
vim:ft=eclimhelp

15
vim-plugins/bundle/eclim/doc/vim/validation.txt Normal file
View file

@ -0,0 +1,15 @@
*vim-validation.html*
Note: When enabled, syntastic
(https://github.com/scrooloose/syntastic) is disabled so that eclim
and syntastic don't step on each other. If you'd like to use
syntastic over eclim for validation, then simply disable eclim's
validation.If you'd like to disable eclim's source code validation
for all languages, eclim provides a global variable for that as
well:>
let g:EclimFileTypeValidate = 0
<
vim:ft=eclimhelp

211
vim-plugins/bundle/eclim/doc/vim/xml/index.txt Normal file
View file

@ -0,0 +1,211 @@
*vim-xml-index.html*
Xml / Dtd / Xsd
***************
*xml*
Xml
===
Note: If you have xml files that do not have a .xml extension then
eclipse may not recognize it as an xml file resulting in validation,
completion, etc not working. Although the vim side may have the
correct file type set, you may still need to add the file's
extension to the list of xml content types in the eclipse
gui:Preferences ‣ General ‣ Content Types ‣ Text ‣ XML
Code Completion
---------------
Xml code completion uses the standard Vim code completion mechanism
(vim-code_completion) like so:
>
<ser<Ctrl-X><Ctrl-U>
<servlet>
<ser<Ctrl-X><Ctrl-U>
<servlet>
<servlet-name>
...
<
Note: Requires a valid dtd or xsd to determine possible completions.
Definition Lookup
-----------------
When editing xml files, eclim provides a couple commands which allow
you to quickly and easily open the file's data definition and
optionally jump to the definition of a particular element.
Note: When opening urls, these commands rely on netrw (:help netrw).
*:DtdDefinition*
- :DtdDefinition [<element>] - When invoked, this command will
attempt to locate the dtd declaration in the current xml file and
open the dtd in a new split window. If you supply an element name
when invoking the command, it will attempt to locate and jump to the
definition of that element within the dtd. If no element name is
supplied, but the cursor is located on an element name when invoke,
that element name will be used.
*:XsdDefinition*
- :XsdDefinition [<element>] - Behaves like :DtdDefinition except
this command locates and opens the corresponding schema definition
file.
*xml-validation*
Validation
----------
When editing a xml file eclim will default to validating the file when
it is written. Any errors will be added to the current window's
location list (:help location-list) and their corresponding line
number noted via Vim's sign functionality.
If you don't want xml files validated when saving them, you can set
the g:EclimXmlValidate variable described in the configuration section
below.
Regardless of whether you have validation enabled upon saving or not,
the following command is still available for validating xml files on
demand.
*:Validate_xml*
:Validate [<file>] - Validate the supplied file or the current file if
no file name provided.
If eclimd is not currently running, and the xmllint command is
available, eclim will validate the xml file using that. Eclim will
never use xmllint when saving the file with g:EclimXmlValidate
enabled.
*:XmlFormat*
Format
------
On occasion you may encounter some xml content that is unformatted
(like raw content from a web service).
>
<blah><foo>one</foo><bar>two</bar></blah>
<
Executing :XmlFormat will reformat the current xml file like so:
>
<blah>
<foo>one</foo>
<bar>two</bar>
</blah>
<
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimXmlValidate*
- g:EclimXmlValidate (Defualt: 1) - If set to 0, disables xml
validation when saving the file.
- g:EclimValidateSortResults (Default: 'occurrence') - If set to
'severity', the validation results will be sorted by severity
(errors > warnings > info > etc.)
*dtd*
Dtd
===
Validation
----------
When editing a dtd file eclim will default to validating the file when
it is written. Any errors will be added to the current window's
location list (:help location-list) and their corresponding line
number noted via Vim's sign functionality.
If you do not want your dtd files validated automatically when saved,
you can set the |g:EclimDtdValidate| variable described in the
configuration section below.
*:Validate_dtd*
Whether or not auto validation has been enabled, eclim also exposes
the command :Validate to manually execute the validation of the file.
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimDtdValidate*
- g:EclimDtdValidate (Default: 1) - If set to 0, disables validation
when saving the file.
- g:EclimValidateSortResults (Default: 'occurrence') - If set to
'severity', the validation results will be sorted by severity
(errors > warnings > info > etc.)
*xsd*
Xsd
===
Validation
----------
When editing a xsd file eclim will default to validating the file when
it is written. Any errors will be added to the current window's
location list (:help location-list) and their corresponding line
number noted via Vim's sign functionality.
If you do not want your xsd files validated automatically when saved,
you can set the |g:EclimXsdValidate| variable described in the
configuration section below.
*:Validate_xsd*
Whether or not auto validation has been enabled, eclim also exposes
the command :Validate to manually execute the validation of the file.
Configuration
-------------
Vim Settings (vim-settings)
*g:EclimXsdValidate*
- g:EclimXsdValidate (Default: 1) - If set to 0, disables validation
when saving the file.
- g:EclimValidateSortResults (Default: 'occurrence') - If set to
'severity', the validation results will be sorted by severity
(errors > warnings > info > etc.)
vim:ft=eclimhelp