Dreaded_X/dotfiles
1
0
Fork 0
Code Issues 3 Pull Requests Packages Projects Releases Wiki Activity

Installed eclim + remved autocomplete plugins

Browse Source
This commit is contained in:
Dreaded_X
2014-08-31 22:16:01 +02:00
parent 9b88b794a1
commit ce98650c57
226 changed files with 32126 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
vim/bundle/eclim/doc/404.txt Normal file
View File

@@ -0,0 +1,11 @@
*404*
Page Not Found
**************
The page you requested does not exist or may have been moved.
You can use the "Site" drop down or the search box in the nav bar
above to search for your desired topic.
vim:ft=eclimhelp

1225
vim/bundle/eclim/doc/archive/changes.txt Normal file
View File

File diff suppressed because it is too large Load Diff

464
vim/bundle/eclim/doc/archive/news.txt Normal file
View File

@@ -0,0 +1,464 @@
*archive-news*
Eclim News Archive
******************
2011-09-10
==========
Eclim 1.7.2 (|1.7.2|) is now available.
This version fixes running the installer with java 7 as well as several other
small bug fixes and improvements.
I'd also like to announce the #eclim channel on freenode.
2011-07-02
==========
Eclim 1.7.1 (|1.7.1|) is now available.
This is a bug fix release.
2011-06-26
==========
Eclim 1.7.0 (|1.7.0|) is now available.
The most notable changes are:
- Eclim has been upgraded to support Eclipse 3.7 (Indigo).
Note: Eclim now requires Eclipse 3.7.
2011-04-16
==========
Eclim 1.6.3 (|1.6.3|) is now available.
This is primarily a bug fix release.
2011-02-26
==========
Eclim 1.6.2 (|1.6.2|) is now available.
This is mostly a bug fix release, but please note that a handful of vim
features have been broken out into separate projects and are no longer shipped
with eclim.
2010-10-23
==========
Eclim 1.6.1 (|1.6.1|) is now available.
This is mostly a bug fix release with a few minor features tossed in.
2010-08-01
==========
Eclim 1.6.0 (|1.6.0|) is now available.
The most notable changes are:
- Eclim has been upgraded to support Eclipse 3.6 (Helios).
Note: Eclim now requires Eclipse 3.6.
2010-06-26
==========
Eclim 1.5.8 (|1.5.8|) is now available.
This is a bug fix release for the installer as well as some php and ruby
features.
2010-06-20
==========
Eclim 1.5.7 (|1.5.7|) is now available.
The main focus of this release is bug fixes and improving the installer.
2010-03-06
==========
Eclim 1.5.6 (|1.5.6|) is now available.
2010-02-22
==========
Eclim 1.5.5 (|1.5.5|) is now available.
This is a bug fix release for the eclim installer.
2009-12-18
==========
Eclim 1.5.4 (|1.5.4|) is now available.
This is primarily a bug fix release for OSX users.
2009-12-12
==========
Eclim 1.5.3 (|1.5.3|) is now available.
2009-08-30
==========
Eclim 1.5.2 (|1.5.2|) is now available.
2009-07-18
==========
Eclim 1.5.1 (|1.5.1|) is now available.
This is primarily a bug fix release
2009-07-12
==========
Eclim 1.5.0 (|1.5.0|) is now available.
The most notable changes are:
- Eclim has been upgraded to support Eclipse 3.5 (Galileo).
Note: Eclim now requires Eclipse 3.5.
- Ruby support has been added using the eclipse dltk
(http://eclipse.org/dltk/).
2009-06-14
==========
Eclim 1.4.9 (|1.4.9|) is now available.
This is primarily a bug fix release, with a few refinements.
2009-05-30
==========
Eclim 1.4.8 (|1.4.8|) is now available.
This is primarily a bug fix release with a few enhancements.
2009-05-02
==========
Eclim 1.4.7 (|1.4.7|) is now available.
This is a bug fix release which resolves an installation on unix based
operating systems.
2009-05-02
==========
Eclim 1.4.6 (|1.4.6|) is now available.
The major highlight of this release is support for c/c++ using the
eclipse cdt (http://eclipse.org/cdt/) plugin.
2009-04-04
==========
Eclim 1.4.5 (|1.4.5|) is now available.
This is primarily a bug fix release.
2009-01-10
==========
Eclim 1.4.4 (|1.4.4|) is now available.
Highlights of this release include:
- re-enabled php support
- added ability to run eclimd inside of eclipse gui
- added support for embedding gvim in eclipse
2008-11-15
==========
Eclim 1.4.3 (|1.4.3|) is now available.
This release focuses on updating the installer to support ganymede's p2 for
upgrading / installing external dependencies and adding additional python
support.
2008-09-30
==========
Eclim 1.4.2 (|1.4.2|) is now available.
This is primary a bug fix release.
2008-08-24
==========
Eclim 1.4.1 (|1.4.1|) is now available.
This is primary a bug fix release, but there are some new features included
as well.
2008-07-27
==========
Eclim 1.4.0 (|1.4.0|) is now available.
Please note that eclim now requires the latest version of eclipse (http://eclipse.org)
(Ganymede, 3.4.x).
Also note that the eclipse pdt plugin which serves as the base for
eclim's php support has not yet been released for the latest version
of eclipse. For this reason php support has been temporarily removed
from this release and will hopefully return soon after the pdt team
release a Ganymede (3.4) compatible version.
Another major change worth noting, is that eclim is now licensed under
the GPLv3. This was done to give eclim the freedom to integrate with
other GPL projects in the future.
2008-03-11
==========
Eclim 1.3.5 (|1.3.5|) is now available.
You can view the release notes (|release notes|) for
more info.
2008-02-05
==========
Eclim 1.3.4 (|1.3.4|) is now available.
This release fixes a few minor bugs, improves the installer to account for
eclipse installs with per user plugin locations, and adds php support.
2007-12-15
==========
Eclim 1.3.3 (|1.3.3|) is now available.
This release fixes some installer issues. If you have already installed
1.3.2, then there is no need to upgrade to 1.3.3.
2007-12-04
==========
Eclim 1.3.2 (|1.3.2|) is now available.
2007-07-13
==========
Eclim 1.3.1 (|1.3.1|) is now available.
This is only a bug fix release.
2007-07-01
==========
Eclim 1.3.0 (|1.3.0|) is now available.
The most notable changes are:
- Eclim has been upgraded to support Eclipse 3.3.
Note: Eclim now requires Eclipse 3.3 and JDK 1.5.
- A new graphical installer (|installer|) built on the formic
(http://github.com/ervandew/formic/) installer framework.
- New functionality based on and requiring the eclipse wst
(http://eclipse.org/webtools/).
- Many more changes (|changes|).
2006-10-09
==========
All Users: A bug made its way into the initial 1.2.3 release which
prevents you from adding methods via :JavaImpl.
An updated eclim_vim_1.2.3.jar is now available to resolve this issue.
If you downloaded this file on October 8th or 9th you can either
download the updated version or execute the following within vim:
>
:PatchEclim eclim/autoload/eclim/util.vim 1.27
<
2006-10-08
==========
Eclim 1.2.3 is now available.
This is primarily a bug fix release.
Please view the release notes (|release notes|) for more info.
2006-09-08
==========
Eclim 1.2.2 is now available.
The previous release introduced two new bugs that managed to slip through the
cracks. These have now been fixed including a third that had been around for
some time but went previously unnoticed.
To see a list of fixes you may view the release notes (|release
notes|).
2006-09-07
==========
Eclim 1.2.1 is now available.
This is primarily a bug fix release, but some new functionality has been
added as well. This release should resolve all known issues.
To see a list of what's new / changed, be sure to take a look at the
release notes (|release notes|).
2006-07-17
==========
Windows Users: Eclim 1.2.0 contained a couple issues that can
potentially prevent eclim from functioning. A new version of
eclim_vim_1.2.0.jar is now available, which fixes these issues.
Simply download the new file and extract it as explained in the <a
href="guides/install.html#step3">installation guide</a>. There is no
need to download or re-install the Eclipse plugins.
If any other issues are encountered please report them.
2006-07-16
==========
Eclim 1.2.0 is now available.
This release requires Eclipse 3.2 (http://eclipse.org/downloads).
To see a list of what's new / changed, be sure to take a look at the
release notes (|release notes|).
Warning: The layout of eclim plugins within the Vim runtimepath has
changed. Please read the <a
href="changes.html#upgrade_1.2.0">details</a> in the release notes
and take the appropriate action prior to upgrading.
2006-05-07
==========
Eclim 1.1.2 is now available.
Before upgrading, you should upgrade your Vim installation to the stable
release of Vim 7.0 or greater.
To see a list of what's new / changed, be sure to take a look at the
release notes (|release notes|).
2006-02-19
==========
New version of eclim (1.1.1) is now available.
This is mostly a bug fix release will a few new additions.
Please note, that this latest version requires Eclipse version 3.1.2 for some
bug fixes and improvements.
To see a list of what's new / changed, be sure to take a look at the
release notes (|release notes|).
2005-12-26
==========
New version of eclim (1.1.0) is now available.
All questions, issues, suggestions are welcome and encouraged.
To see a list of what's new / changed, be sure to take a look at the
release notes (|release notes|).
2005-10-16
==========
The first eclim release (1.0.0) is now available. All questions,
issues, suggestions are welcome and encouraged.
Be sure to read the docs to see what features are currently available,
and take a look at the <a href="todo.html">todo</a> to see what's
coming in future releases.
2005-09-11
==========
Several new additions over the past couple weeks:
- Java code completion: Integrated into Vim via Vim 7's new "User
Defined Completion".
- Added eclim command line support for creating and updating
projects, including Vim support for editing Eclipse .classpath files
and updating Eclipse upon writing of those files.
- Integrated nailgun (http://www.martiansoftware.com/nailgun/) to
greatly improve the command line client performance.
- Started documenting eclim and its features.
With the addition of these features I'm going to stop adding new
functionality for the time being and focus on testing and ensuring
that everything works as expected on Windows.
2005-08-21
==========
Code navigation / searching is done! Most of the Vim integration for
searching is done as well. The only thing missing is viewing code for
results that are found in a jar file that have no corresponding source
attachment. I may end up doing what Eclipse appears to do, which is
to use javap to display the class and method signatures. That or I'll
use jad to decompile the whole source. My only issue with jad, is
that it is not up to date with the 1.5 byte code.
I also have automated importing done as well. The eclim server
request just returns a list of possible results to import for a given
request and the editor (Vim in this case) handles prompting the user
and updating the code.
Note: The Vim integration now requires Vim 7. Even though Vim 7 is
still alpha, I haven't had any major issues with it and the new
additions to the Vim scripting language are just too good to pass
up.
My next step is to start documenting everything and testing on a
Windows environment to ensure there aren't any compatibility issues.
After that I should be ready to put out a preliminary release. I'm
trying to be very careful about releasing anything too soon. The last
thing I want it to scare anyone off with a broken project that doesn't
seem to work properly.
2005-08-11
==========
Sourceforge site is up! Now it's just a matter of getting the ball
rolling again.
I'm hoping to have source code navigation working by the end of next
week. This includes the ability to simply hit <enter> on a class name,
method name, method call, etc. to jump to its declaration. Basically
I want to replace my previous Vim plug-in
(http://www.vim.org/scripts/script.php?script_id=1106) with the new
Eclipse one.
Before I put out any releases though, I want to have a comprehensive
set of documentation. For the first few releases, setup will probably
be pretty manual, with most of it occurring through the Eclipse
interface. Going forward, I want to move more of that functionality
into Vim.
vim:ft=eclimhelp

525
vim/bundle/eclim/doc/changes.txt Normal file
View File

@@ -0,0 +1,525 @@
*changes*
History of Changes
******************
*2.4.0*
2.4.0 (Aug. 24, 2014)
=====================
Eclim:
- Eclim now supports, and requires, Eclipse Luna
- :EclimSettings renamed to :WorkspaceSettings to better reflect
what is being edited.
- Added :VimSettings (|vim-core-eclim#:VimSettings|) command to
make viewing/editing of eclim's vim client settings easier.
- All eclim make based commands (:Ant, :Mvn, etc.) will now use
dispatch (https://github.com/tpope/vim-dispatch) if available. If
you would like to disable this behavior, add the following to
your vimrc:
>
let g:EclimMakeDispatchEnabled = 0
<
- Lot of bugs have also been fixed.
Scala:
- Scala support is disabled in this release. I tried waiting for
a final release of ScalaIDE 4.0.0 for Luna, but I don't want to
hold up the rest of eclim any longer. If you want to use eclim's
scala support, you'll need to install the ScalaIDE 4.0.0
milestone and build eclim from the master git branch.
Git Log (2.4.0) (https://github.com/ervandew/eclim/compare/2.3.4...2.4.0)
*1.7.19*
1.7.19 (May 07, 2014)
=====================
Indigo release which includes most of the changes from 2.3.3 and
2.3.4, excluding the new pydev support. This will most likely be the
final eclim release for indigo.
Git Log (1.7.19) (https://github.com/ervandew/eclim/compare/1.7.18...1.7.19)
*2.3.4*
2.3.4 (Apr. 12, 2014)
=====================
Project:
- Fixed the projects command result on Windows.
Git Log (2.3.4) (https://github.com/ervandew/eclim/compare/2.3.3...2.3.4)
*2.3.3*
2.3.3 (Apr. 06, 2014)
=====================
Installer:
- Fixed running of the installer with Java 8.
Eclimd:
- Starting eclimd in the background is now done using the -b flag
instead of passing a start argument.
- Eclimd debug logging can now be enabled at startup using the
--debug flag.
Ant:
- Fixed ant target completion for newer ant versions (those that
require java 5).
C/C++:
- Fixed adding of includes etc. in the C++ sections of
:CProjectConfig.
- Fixed searching to include macro results.
- TODO/FIXME markers are now ignored by validation.
Html:
- Fixed indentation after unclosed <br> and <input> tags.
Java:
- Fixed possible infinite loop when adding imports using
:JavaImport.
- Fixed an edge case which caused an additional empty line to be
added between imports that should be grouped together when using
:JavaImport.
- Fixed :Java command if the main class has no package
declaration.
- Fixed issue with large portions of code being re-formatted when
applying a correction suggestion.
- TODO/FIXME markers are now ignored by validation.
- Some of the eclipse java code completion settings are now
available via :ProjectSettings.
Javascript:
- Let tern supersede eclim's limited javascript completion.
Maven/Ivy:
- Removed dependency searching since the search provider no
longer exists.
Python:
- Eclim's python support been re-written to use pydev instead of
rope.
Note: Any exiting eclim python projects you have should be
re-created with the new python nature:>
:ProjectCreate /path/to/project -n python
<
Scala:
- Disabled use of temp files which could cause some validation
errors.
- Added support for automated imports (|:ScalaImport|).
Xml:
- Fixed validation of xml files with no dtd/schema to not raise
errors on missing dtd for non-english users.
Git Log (2.3.3) (https://github.com/ervandew/eclim/compare/2.3.2...2.3.3)
*2.3.2* *1.7.18*
2.3.2 / 1.7.18 (Sep. 12, 2013)
==============================
Installer:
- Fixed extraction of scala vim files when installing scala
support.
Php:
- Fixed completion of php namespaces.
Git Log (2.3.2) (https://github.com/ervandew/eclim/compare/2.3.1...2.3.2)
Git Log (1.7.18) (https://github.com/ervandew/eclim/compare/1.7.17...1.7.18)
*2.3.1*
2.3.1 (Jul. 27, 2013)
=====================
Installer:
- Fixed dependencies to point at the Kepler update site.
Git Log (2.3.1) (https://github.com/ervandew/eclim/compare/2.3.0...2.3.1)
*2.3.0* *1.7.17*
2.3.0 / 1.7.17 (Jul. 21, 2013)
==============================
Java:
- :NewJarEntry (|:NewJarEntry_java|) now accepts up to 3
arguments allowing you to create the jar entry with the path to
the jar, path to the source, and the path to the javadocs.
- On javadoc search, all results, including results found in jar
files, will be fully translated to usable urls to be opened by
vim instead of sending jar results back to eclipse to let it open
them. With this change your chosen brower on the vim side will
always be used.
- Fix for import grouping by package on Kepler.
Php:
Warning: Reminder: The format of the h2 database used for php
searching and code completion has changed in Kepler which may
result in searching / code completion not returning any results,
both in eclim and in the standard eclipse php editor. To fix
this you'll need to stop eclipse, remove the old index, and then
restart:>
$ rm -r <your workspace>/.metadata/.plugins/org.eclipse.dltk.core.index.sql.h2/
<
Scala:
- Updated to require 3.0.1 of the Scala IDE which now supports
Kepler (for eclim 2.3.0 only). Since this version of the Scala
IDE seems to only support Scala 2.10.x now, the option to install
2.9.x version has been removed, however the indigo release of
eclim (1.7.17) still supports the Scala 2.9.x version of Scala
IDE 3.0.0.
Xml:
- |:XmlFormat| now uses the DOM3 APIs to improve the formatted
result, honoring your textwidth and indent settings.
Git Log (2.3.0) (https://github.com/ervandew/eclim/compare/2.2.7...2.3.0)
Git Log (1.7.17) (https://github.com/ervandew/eclim/compare/1.7.16...1.7.17)
*2.2.7* *1.7.16*
2.2.7 / 1.7.16 (Jul. 14, 2013)
==============================
Java:
- Fix for some completions on Kepler.
- Fix for rare case where an invalid classpath entry could result
in the .classpath file reverted to the eclipse default.
- |:JavaCallHierarchy| added to show the caller or callee
hierarchy of a method. Thanks to Alexandre Fonseca.
Php:
Warning: The format of the h2 database used for php searching and
code completion has changed in Kepler which may result in
searching / code completion not returning any results, both in
eclim and in the standard eclipse php editor. To fix this you'll
need to stop eclipse, remove the old index, and then restart:>
$ rm -r <your workspace>/.metadata/.plugins/org.eclipse.dltk.core.index.sql.h2/
<
Ruby:
- Fixed the inserted completion text for some ruby libraries.
Scala:
- The graphical installer now includes a compiled eclim sdt
bundle for both scala 2.9.x and 2.10.x for which one will be
chosen for you if you already have the scala-ide installed,
otherwise you can pick one and the appropriate version of the
scala-ide will be installed for you.
Vimplugin:
- The option to force focusing of gvim with a simulated click is
now disabled by default, but when enabled, it should be less
likely to have unintended side affects.
Cygwin:
- Performance optimization for user's with many projects.
Installer:
- The installer will now properly shutdown eclimd instances
registered using the old non-json format.
Docs:
- Expanded the developer docs (|development-index|) to include
docs on creating new commands (|development-commands|) along with
some of the basics for adding new eclim plugins
(|development-plugins|).
Git Log (2.2.7) (https://github.com/ervandew/eclim/compare/2.2.6...2.2.7)
Git Log (1.7.16) (https://github.com/ervandew/eclim/compare/1.7.14...1.7.16)
*2.2.6* *1.7.14*
2.2.6 / 1.7.14 (May 18, 2013)
=============================
Bug Fixes:
- Fixed eclimd to prevent incorrect addition of -d32 on 64bit
systems, which prevents eclimd from starting.
- Fix potential conflicts between syntastic validation vs eclim
validation (syntastic validation will be diabled if eclim
validation is available for the current file type).
- Many more fixes.
Android:
- Updated for ADT 22.0.0
C/C++:
- |:CCallHierarchy| now support showing callee tree.
Java:
- |:JavaImpl| now supports anonymous inner classes and will also
properly handle suggesting methods from a nested superclass.
Php:
- Eclim will no longer run php files through html validation by
default (see the Php Validation (|vim-php-validate|) doc for
settings to enable html validation).
Scala:
- Scala support updated for Scala IDE 3.0.0.
- Scala now supported on both versions of eclim (Juno and
Indigo).
Git Log (2.2.6) (https://github.com/ervandew/eclim/compare/2.2.5...2.2.6)
Git Log (1.7.14) (https://github.com/ervandew/eclim/compare/1.7.13...1.7.14)
*2.2.5* *1.7.13*
2.2.5 / 1.7.13 (Nov. 25, 2012)
==============================
Eclim:
- 1.7.13 and above will now support Eclipse 3.8 as well as 3.7.
- Fix |:ProjectGrep| and |:ProjectTodo| to search in all of the
project's links as well.
- Other minor bug fixes.
Git Log (2.2.5) (https://github.com/ervandew/eclim/compare/2.2.4...2.2.5)
Git Log (1.7.13) (https://github.com/ervandew/eclim/compare/1.7.12...1.7.13)
*2.2.4* *1.7.12*
2.2.4 / 1.7.12 (Nov. 18, 2012)
==============================
Eclim:
- Updated |:ProjectTree| and |:ProjectTab| to support an
arbitrary directory as an argument, allowing you to use the
command for project's not managed by eclipse/eclim. :TreeTab has
been removed since the update to :ProjectTab makes it redundant.
- Creation of projects in nested directories in the eclipse
workspace (vs at the root of the workspace) is now properly
supported through eclim.
Android:
- Updated for ADT 21.0.0.
C/C++:
- Fix placement of some error markers.
Php:
- Some indentation fixes.
Git Log (2.2.4) (https://github.com/ervandew/eclim/compare/2.2.3...2.2.4)
Git Log (1.7.12) (https://github.com/ervandew/eclim/compare/1.7.11...1.7.12)
*2.2.3* *1.7.11*
2.2.3 / 1.7.11 (Oct. 19, 2012)
==============================
Eclim:
- Fixes execution of eclim commands from vim on Windows when
using the external nailgun client (vs the python client).
Git Log (2.2.3) (https://github.com/ervandew/eclim/compare/2.2.2...2.2.3)
Git Log (1.7.11) (https://github.com/ervandew/eclim/compare/1.7.10...1.7.11)
*2.2.2* *1.7.10*
2.2.2 / 1.7.10 (Oct. 07, 2012)
==============================
Eclimd:
- Updated eclimd script for Linux/OSX to supply reasonable
defaults for heap and perm gen space if not already set by
~/.eclimrc.
C/C++:
- Fixed C++ project creation to auto add the required C nature.
- Fixed C/C++ issues introduced by the eclipse 4.2.1 release
(project create/refresh and call hierarchy).
Java:
- :JavaImportSort, :JavaImportClean, and :JavaImportMissing all
removed in favor of a new command which performs the
functionality of all three: |:JavaImportOrganize|
- The vim option g:EclimJavaImportExclude has been replaced with
the eclim setting org.eclim.java.import.exclude
(|org-eclim-java-import-exclude|).
- The vim option g:EclimJavaImportPackageSeparationLevel has been
replaced with the eclim setting
org.eclim.java.import.package_separation_level
(|org-eclim-java-import-package-separation-level|).
- g:EclimJavaBeanInsertIndexed vim variable removed in favor of
suffixing :JavaGetSet methods with '!'.
- :JavaCorrect, :JavaImpl, :JavaDelegate, :JavaConstructor, and
:JUnitImpl all now perform their code manipulations using eclipse
operations.
- Initial support added for running :JavaSearch commands from
source file results (library source files) not in a project.
- g:EclimJavaCheckstyleOnSave replaced with the eclim setting
org.eclim.java.checkstyle.onvalidate
(|org-eclim-java-checkstyle-onvalidate|).
- g:EclimJavaSrcValidate renamed to g:EclimJavaValidate.
- :JUnitExecute replaced with a new and improved |:JUnit|
command.
- Added the command |:JUnitFindTest| to open the corresponding
test for the current file.
- Removed :Javac command since eclipse's continuous incremental
builds typically make the :Javac call a no op, and in cases where
you need to induce compilation, |:ProjectBuild| does so in a
language agnostic way.
- Added |:JavaMove| command to move a java source file from one
package to another.
- Added |:JavaDocPreview| to display the javadoc of the element
under the cursor in vim's preview window.
Git Log (2.2.2) (https://github.com/ervandew/eclim/compare/2.2.1...2.2.2)
Git Log (1.7.10) (https://github.com/ervandew/eclim/compare/1.7.9...1.7.10)
*1.7.9*
1.7.9 (Sep. 09, 2012)
=====================
Scala:
- Add support for scala code completion (|vim-scala-complete|),
code validation (|vim-scala-validate|), and element definition
searches (|vim-scala-search|).
Git Log (1.7.9)
(https://github.com/ervandew/eclim/compare/1.7.8...1.7.9)
*2.2.1* *1.7.8*
2.2.1 / 1.7.8 (Sep. 01, 2012)
=============================
Documentation:
- Redesigned the eclim website using the sphinx bootstrap theme
(https://github.com/ervandew/sphinx-bootstrap-theme).
- Reorganized many of the docs to consolidate similar features to
hopefully make them easier to find and make the docs less
sprawling.
- Improved the translation of the docs to vim help files.
Android:
- Eclim now has support for creating android projects
(|gettingstarted-android|).
Java:
- Fixed searching for JDK classes on OSX.
- Added support for searching for inner classes and their
methods.
- Fixed remaining tab vs spaces indenting related issues with
code added via eclipse.
Vimplugin:
- Fixed disabling of conflicting Eclipse keybindings on Juno
while the embedded vim has focus (fixes usage of Ctrl+V for
blockwise visual selections).
Git Log (2.2.1) (https://github.com/ervandew/eclim/compare/2.2.0...2.2.1)
Git Log (1.7.8) (https://github.com/ervandew/eclim/compare/1.7.7...1.7.8)
*2.2.0* *1.7.7*
2.2.0 / 1.7.7 (Aug. 07, 2012)
=============================
Eclipse:
- Eclim 2.2.0 and above now requires Java 6 or later.
- Eclim 2.2.0 and above now requires the latest version of
eclipse (Juno, 4.2).
Eclimd:
- Updated eclimd script to always set the jvm architecture
argument, preventing possible issue starting eclimd on OSX if the
default architecture order of the java executable doesn't match
the eclipse architecture.
C/C++:
- Semantic errors are now included in the validation results.
- Added folding support to C/C++ call hierarchy buffer.
- |:ProjectRefresh| now waits on the C/C++ indexer to finish
before returning focus to the user.
- Fixed auto selecting of the tool chain when creating C/C++
projects from eclim.
- Fixed |:CCallHierarchy| from possibly using a cached version of
the file resulting in incorrect or no results.
Java:
- Fixed inserted code from |:JavaCorrect| when file format is
'dos'.
- Fixed off by one issue prevent several code correction
suggestions from being suggested.
Ruby:
- Fixed to prompt for the path to the ruby interpreter if
necessary when importing a ruby project or adding the ruby nature
to an existing project.
Vimplugin:
- Fixed executing of some operations when vim is currently in
insert mode (opening new file from eclipse in a new external vim
tab, using "Save As" from eclipse, and jumping to a line number
from the project tree etc.)
Git Log (2.2.0) (https://github.com/ervandew/eclim/compare/1.7.6...2.2.0)
Git Log (1.7.7) (https://github.com/ervandew/eclim/compare/1.7.6...1.7.7)
*1.7.6*
1.7.6 (Jun. 07, 2012)
=====================
Bug Fixes:
- Couple other minor bug fixes.
Installer:
- Fixed install location of eclim's vim help files (broken in the
previous release).
Git Log (1.7.6)
(https://github.com/ervandew/eclim/compare/1.7.5...1.7.6)
*1.7.5*
1.7.5 (Jun. 03, 2012)
=====================
Note: This release is not compatible with Eclipse Juno (4.2). The
next major release of eclim (2.2.0) will be built for Juno.
Installer:
- Added uninstall (|uninstall|) support to the eclim installer.
- Updated the installer to fully embrace eclipse's provisioning
framework (p2).
Common:
- Added |:ProjectTreeToggle|.
Vimplugin
- Fixed key binding conflict handling to not inadvertently switch
your key binding scheme back to the default scheme.
Java:
- Added support for importing the necessary type during code
completion.
- Improved location of a project's main class for the |:Java|
command, when not explicitly set.
Git Log (1.7.5)
(https://github.com/ervandew/eclim/compare/1.7.4...1.7.5)
*1.7.4*
1.7.4 (Apr. 22, 2012)
=====================
Bug Fixes:
- Fixed possible NPE saving eclim settings.
- Several other small bug fixes.
C/C++:
- Fixed code completion by disabling the use of temp files.
Java:
- Fixed :Java on windows as well as handling of stdin for ant
1.8.2+.
Git Log (1.7.4)
(https://github.com/ervandew/eclim/compare/1.7.3...1.7.4)
*1.7.3*
1.7.3 (Mar. 18, 2012)
=====================
Bug Fixes:
- Lots of various bug fixes.
Common:
- Added |:ProjectBuild| to build the current or supplied project.
- Updated |:ProjectProblems| to support optional bang
(:ProjectProblems!) to only show project errors.
- Updating eclipse's local history (|vim-core-history|) when
writing in vim is now only enabled by default when gvim is opened
from the eclipse gui.
C/C++:
- Fixed project creation issue encountered on some systems.
Java:
- Added project settings for specifying default jvm args for
|:Java| and default args for :Javac.
- Code inserted by |:JavaConstructor|, |:JavaGetSet|,
|:JavaImpl|, |:JavaDelegate|, and |:JUnitImpl| is now formatted
according to the eclipse code formatter settings configured from
the eclipse gui.
Maven:
- Now when saving your pom.xml file your .classpath will be auto
updated (|classpath-maven-pom|) with the dependencies found in
your pom.xml.
Php:
- Now handles completion from within php short tags.
Git Log (1.7.3)
(https://github.com/ervandew/eclim/compare/1.7.2...1.7.3)
Eclim Changes Archive (|archive-changes|)
vim:ft=eclimhelp

347
vim/bundle/eclim/doc/cheatsheet.txt Normal file
View File

@@ -0,0 +1,347 @@
*cheatsheet*
Cheatsheet
**********
Here you will find a comprehensive list of eclim commands that you can
use as a reference.
Global Commands
===============
- :PingEclim (|vim-core-eclim#:PingEclim|) - Pings eclimd server.
- :ShutdownEclim (|vim-core-eclim#:ShutdownEclim|) - Shuts down
eclimd server.
- :VimSettings (|vim-core-eclim#:VimSettings|) - View / edit eclim's
vim client settings.
- :WorkspaceSettings (|vim-core-eclim#:WorkspaceSettings|) - View /
edit global workspace settings.
- :EclimDisable (|vim-core-eclim#:EclimDisable|) - Temporarily
disables communication with eclimd.
- :EclimEnable (|vim-core-eclim#:EclimEnable|) - Re-enables
communication with eclimd.
- :EclimHelp (|vim-core-eclim#:EclimHelp|) [helptopic] - View eclim
documentation in vim.
- :EclimHelpGrep (|vim-core-eclim#:EclimHelpGrep|) /regex/ - Search
the eclim documentation in vim.
Project Commands
================
- |:ProjectCreate| <folder> [-p <project_name>] -n <nature> ... [-d
<project_dependency> ...] - Create a new project.
- |:ProjectImport| <folder> - Import a project from an existing
eclipse project folder.
- |:ProjectList| - List current projects.
- |:ProjectSettings| [<project>] - View / edit project settings.
- |:ProjectDelete| <project> - Delete a project.
- |:ProjectRename| [<project>] <name> - Rename a project.
- |:ProjectMove| [<project>] <dir> - Move a project.
- |:ProjectRefresh| [<project> <project> ...] - Refresh supplied
list of projects against the current files on disk. If no project
names supplied, refresh the current project.
- |:ProjectRefreshAll| - Refresh all projects.
- |:ProjectBuild| [<project>] - Build the current or supplied
project.
- |:ProjectInfo| [<project>] - Echos info for the current or
supplied project.
- |:ProjectOpen| [<project>] - Opens a project.
- |:ProjectClose| [<project>] - Closes a project.
- |:ProjectNatures| [<project>] - View the configured natures for
one or all projects.
- |:ProjectNatureAdd| <project> [<nature> ...] - Add one or more
natures to a project.
- |:ProjectNatureRemove| <project> [<nature> ...] - Remove one or
more natures from a project.
- |:ProjectProblems| [<project>] - Populates vim's quickfix with all
eclipse build errors and warnings for the current, or specified
project, and all related projects.
- |:ProjectCD| - Changes the global current working directory to the
root directory of the current file's project (executes a :cd).
- |:ProjectLCD| - Changes the current working directory of the
current window to the root directory of the current file's project
(executes a :lcd).
- |:ProjectTree| [<project> <project> ...] - Opens navigable a tree
for one or more projects.
- |:ProjectsTree| - Opens a tree containing all projects.
- |:ProjectTab| <project> - Opens a new tab containing the project
tree and the tab local working directory set to the supplied
project's root.
- |:ProjectGrep| /<pattern>/ file_pattern [file_pattern ...] -
Issues a vimgrep starting at the root of the current project.
- |:ProjectGrepAdd| /<pattern>/ file_pattern [file_pattern ...] -
Issues a vimgrepadd starting at the root of the current project.
- |:ProjectLGrep| /<pattern>/ file_pattern [file_pattern ...] -
Issues a lvimgrep starting at the root of the current project.
- |:ProjectLGrepAdd| /<pattern>/ file_pattern [file_pattern ...] -
Issues a lvimgrepadd starting at the root of the current project.
- |:ProjectTodo| - Searches project files for todo / fixme patterns
and adds them to the location list.
- |:Todo| - Searches the current file for todo / fixme patterns and
adds them to the location list.
Android Commands
================
- |: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).
Ant Commands
============
- |:Ant| [<target> ...] - Execute ant from the current project.
- |:AntDoc| [<element>] - Find and open the documentation for the
element under the cursor or the element supplied as an argument.
- :Validate (|:Validate_ant|) - Validate the current ant build file.
C/C++ Commands
==============
- :Validate (|:Validate_c|) - Validate the current file.
- |:CSearch| [-p <pattern> -t <type> -s <scope> -x <context>] -
Search for classes, functions, methods, macros, etc.
- |:CSearchContext| - Find the element under the cursor based on its
context.
- |:CProjectConfigs| [project] - Open a temp buffer to view/modify
the current projects cdt configurations.
- |:CCallHierarchy| - Display the call hierarchy for the function or
method under the cursor.
Css Commands
============
- :Validate (|:Validate_css|) - Validate the current file.
Dtd Commands
============
- :Validate (|:Validate_dtd|) - Validate the current file.
Html Commands
=============
- :Validate (|:Validate_html|) - Validate the current file.
- |:BrowserOpen| - Opens the current file in your configured
browser.
Groovy Commands
===============
- :Validate (|:Validate_groovy|) - Validate the current file.
Ivy Commands
============
- |:IvyRepo| <path> - Sets the necessary IVY_REPO classpath variable
for supporting automatic updates to .classpath files upon ivy.xml
updates.
Java Commands
=============
- |:JavaGet| - Create a java bean getter method.
- |:JavaSet| - Create a java bean setter method.
- |:JavaGetSet| - Create both a java bean getter and setter method.
- |:JavaConstructor| - Creates class constructor, either empty or
based on selected class fields.
- |:JavaCallHierarchy| - Display the call hierarchy for the method
under the cursor.
- |:JavaHierarchy| - View the type hierarchy tree.
- |:JavaImpl| - View implementable / overridable methods from super
classes and implemented interfaces.
- |:JavaDelegate| - View list of methods that delegate to the field
under the cursor.
- |:JUnit| [testcase] - Allows you to execute junit test cases.
- |:JUnitFindTest| - Attempts to find the corresponding test for the
current source file.
- |:JUnitImpl| - Similar to :JavaImpl, but creates test methods.
- |:JUnitResult| [testcase] - Allows you to view the results of a
test case.
- |:JavaImport| - Import the class under the cursor.
- |:JavaImportOrganize| - Import undefined types, remove unused
imports, sort and format imports.
- |:JavaSearch| [-p <pattern>] [-t <type>] [-x <context>] [-s
<scope>] - Search for classes, methods, fields, etc. (With pattern
supplied, searches for the element under the cursor).
- |:JavaSearchContext| - Perform a context sensitive search for the
element under the cursor.
- |:JavaCorrect| - Suggest possible corrections for a source error.
- |:JavaDocSearch| - Search for javadocs. Same usage as
:JavaSearch.
- |:JavaDocComment| - Adds or updates the comments for the element
under the cursor.
- |:JavaDocPreview| - Display the javadoc of the element under the
cursor in vim's preview window.
- |:JavaRename| [new_name] - Rename the element under the cursor.
- |:JavaMove| [new_package] - Move the current class/interface to
another package.
- |:Java| - Executes the java using your project's main class.
- |:JavaClasspath| [-d <delim>] - Echos the project's classpath
delimited by the system path separator or the supplied delimiter.
- |:Javadoc| [file, file, ...] - Executes the javadoc utility
against all or just the supplied source files.
- |:JavaListInstalls| - List known JDK/JRE installs.
- |:JavaFormat| - Formats java source code.
- |:Checkstyle| - Invokes checkstyle on the current file.
- |:Jps| - Opens window with information about the currently running
java processes.
- :Validate (|:Validate_java|) - Manually runs source code
validation.
Java .classpath Commands
========================
- :NewSrcEntry (|:NewSrcEntry_java|) <dir> - Add a new source dir
entry.
- :NewProjectEntry (|:NewProjectEntry_java|) <project> - Add a new
project entry.
- :NewJarEntry (|:NewJarEntry_java|) <file> [<src_path>
<javadoc_path>] - Add a jar entry.
- :NewVarEntry (|:NewVarEntry_java|) <VAR/file> [<src_path>
<javadoc_path>] - Add a new var entry.
- |:VariableList| List available classpath variables and their
corresponding values.
- |:VariableCreate| <name> <path> - Creates or updates the variable
with the supplied name.
- |:VariableDelete| <name> - Deletes the variable with the supplied
name.
Javascript Commands
===================
- :Validate (|:Validate_javascript|) - Validate the current
javascript file.
Log4j Commands
==============
- :Validate (|:Validate_log4j|) - Validate the current log4j xml
configuration file.
Maven Commands
==============
- |:Maven| [<goal> ...] - Execute maven 1.x from the current
project.
- |:Mvn| [<goal> ...] - Execute maven 2.x from the current project.
- |:MavenRepo| - Sets the necessary MAVEN_REPO classpath variable
for maven's (1.x) eclipse support.
- |:MvnRepo| - Sets the necessary M2_REPO classpath variable for
maven's (2.x) eclipse support.
Php Commands
============
- |:PhpSearch| [-p <pattern> -t <type> -s <scope> -x <context>] -
Search for classes, methods, and constants.
- |:PhpSearchContext| - Find the element under the cursor based on
its context.
- :Validate (|:Validate_php|) - Manually runs source code
validation.
Python Commands
===============
- |:PythonSearch| - Find the element under the cursor or, if
requested, all references to that element.
- |:PythonSearchContext| - Find the element under the cursor or its
references based on the current context in the file.
- :Validate (|:Validate_python|) - Validates the current file.
- |:DjangoManage| - Invokes django's manage.py from any file in the
same directory as your manage.py or in any of the child directories.
- |:DjangoFind| - Available when editing a django html template
file. Finds tag/filter definition, other template files, and static
files.
- |:DjangoTemplateOpen| - Available when editing a python file.
Finds the template referenced under the cursor.
- |:DjangoViewOpen| - Available when editing a python file. When
within a django url patterns definition, finds the view referenced
under the cursor.
- |:DjangoContextOpen| - Available when editing a python file.
Executes :DjangoViewOpen, :DjangoTemplateOpen, or
:PythonSearchContext depending on the context of the text under the
cursor.
Ruby Commands
=============
- |:RubySearch| [-p <pattern> -t <type> -s <scope> -x <context>] -
Search for modules, classes, methods, etc.
- |:RubySearchContext| - Find the element under the cursor based on
its context.
- :Validate (|:Validate_ruby|) - Manually runs source code
validation.
- |:RubyInterpreterAdd| [-n <name>] <path> - Add a ruby interpreter.
- |:RubyInterpreterRemove| <path> - Remove a ruby interpreter.
- |:RubyInterpreterList| - List the available ruby interpreters.
Scala Commands
==============
- |:ScalaSearch| - Search for the definition of the element under
the cursor.
- |:ScalaImport| - Import the type under the cursor.
- :Validate (|:Validate_scala|) - Manually runs source code
validation.
WebXml Commands
===============
- :Validate (|:Validate_webxml|) - Validate the current web.xml
file.
Xml Commands
============
- |:DtdDefinition| [<element>] - Open the current xml file's dtd and
jump to the element definition if supplied.
- |:XsdDefinition| [<element>] - Open the current xml file's xsd and
jump to the element definition if supplied.
- :Validate (|:Validate_xml|) [<file>] - Validates the supplied xml
file or the current file if none supplied.
- |:XmlFormat| - Reformats the current xml file.
Xsd Commands
============
- :Validate (|:Validate_xsd|) - Validate the current file.
Misc. Commands
==============
- |:LocateFile| [file] - Locates a relative file and opens it.
- |:Tcd| dir - Like :lcd but sets the tab's local working directory.
- |:DiffLastSaved| - Performs a diffsplit with the last saved
version of the currently modifed file.
- |:SwapWords| - Swaps two words (with cursor placed on the first
word). Supports swapping around non-word characters like commas,
periods, etc.
- |:Sign| - Toggles adding or removing a vim sign on the current
line.
- |:Signs| - Opens a new window containing a list of signs for the
current buffer.
- |:SignClearUser| - Removes all vim signs added via :Sign.
- |:SignClearAll| - Removes all vim signs.
- |:QuickFixClear| - Removes all entries from the quick fix window.
- |:LocationListClear| - Removes all entries from the location list
window.
- |:Buffers| - Opens a temporary window with a list of all the
currently listed buffers, allowing you to open or remove them.
- |:BuffersToggle| - Opens the buffers window if not open, otherwise
closes it.
- |:Only| - Closes all but the current window and any windows
excluded by g:EclimOnlyExclude.
- |:History| - View the local history entries for the current file.
- |:HistoryClear| - Clear the local history entries for the current
file.
- |:HistoryDiffNext| / |:HistoryDiffPrev| - Diff the current file
against the next/previous entry in the history stack.
- |:RefactorUndo| / |:RefactorRedo| - Undo / Redo the last
refactoring.
- |:RefactorUndoPeek| / |:RefactorRedoPeek| - Display a short
description of the refactoring to be undone / redone.
- |:OpenUrl| [url] - Opens a url in your configured web browser.
vim:ft=eclimhelp

60
vim/bundle/eclim/doc/contribute.txt Normal file
View File

@@ -0,0 +1,60 @@
*contribute*
Contribute
**********
Eclim is a project developed entirely in my spare time, so its growth
and success can be directly impacted by contributions from the
community. There are several ways in which you can contribute:
1. Documentation: The documentation can always use improvements.
Right now it is written entirely by me, and as such, it may not be
as detailed in some areas as it should. What the documentation
could really use is some help from its users:
- Point out any grammar or spelling errors, since some always
manage to slip through.
- Point out areas of the documentation that are vague and could
use elaboration.
- Write new guides to be included in the "Guides" section of the
site.
2. Bug Reports: Some people are a bit shy about speaking up and
reporting bugs. I want to urge people not to be. If something
doesn't work, report it. It may be a bug, but even if it is just a
configuration issue on your end, a misconception on how you thought
it should work, or some other quirk specific to your environment,
speak up. These can signal that some scripts may need to validate
or account for some aspect of the user's environment, or that the
documentation may need some work to ensure the user knows what to
expect. Any issue that goes unreported, goes unfixed, so please
report all issues, big and small.
3. Feature Requests: On occasion I receive a request or two, but I
would like to encourage more people to voice their opinion on what
they think should be added or changed in eclim. Once again,
nothing is too small to suggest. Chances are, that if you have
something that you would like added or changed, there are others
out there that would benefit from the same addition or
modification.
To see what features I have already thought about, you can view my
todo list (http://github.com/ervandew/eclim/blob/master/notes.txt).
4. Code Contributions: In addition to reporting bugs or requesting
features, you can also take that next step and implement a fix or
feature yourself. I just ask that you document your patch
accordingly so that I know exactly what you are attempting to fix
or add. Also, if you plan to add a medium or large feature, please
let me know prior to beginning your work. That way I can keep a
small list of who is working on what to avoid any duplication of
effort and link people together that wish to work on the same
feature. The list would also afford me the ability to contact you
should a change to eclim possibly affect what you are working on.
If you plan on making any code contributes, please read the
developer guide (|development-gettingstarted|) first.
5. Monetary Contributions: I am not currently accepting any
donations. My day job pays well, and I work on eclim for the love
of it. If you have money you would like to donate, it would go to
much better use if you donated to vim
(http://www.vim.org/sponsor/index.php), where it is used to help
children in Uganda. Feel free to mention your referral from eclim
if appropriate.
vim:ft=eclimhelp

38
vim/bundle/eclim/doc/development/architecture.txt Normal file
View File

@@ -0,0 +1,38 @@
*development-architecture*
Architecture
************
The eclim architecture is pretty straight forward. Commands issued by
a user in vim are relayed via nailgun
(http://www.martiansoftware.com/nailgun/) to the running eclim daemon
and the proper command implementation is then located and executed.
Here is a diagram showing the sequence in a bit more detail:
[diagram]
The commands which are executed on the eclimd side are also fairly
simple. They accept an object containing the command line parameters
passed into the eclim invocation and then return an object (String,
Collection, etc) which is converted to a json response. Below is a
simple class diagram showing the hierarchy of a couple typical
commands.
[diagram]
Another important aspect of eclim's architecture is support for
plugins. Plugins for eclim are bundled as eclipse plugins with their
auto start attribute set to false. When the eclim daemon starts it
will locate and load any eclipse plugin with an 'org.eclim.' prefix.
When a plugin is loaded, eclim will locate the plugin's required
resources provider and invoke its initialize method which will then
inject its resources (messages, command options, etc) into eclim and
register any new commands.
Here is graphical representation of this process:
[diagram]
vim:ft=eclimhelp

242
vim/bundle/eclim/doc/development/commands.txt Normal file
View File

@@ -0,0 +1,242 @@
*development-commands*
Commands
********
For each eclipse feature that is exposed in eclim, there is a
corresponding command on the daemon which handles calling the
appropriate eclipse APIs and returning a result back to the client.
This page will walk you through creating a simple command to
familiarize you with the process.
Creating a Command
==================
Commands are simple classes which extend AbstractCommand and are
registered using the @Command annotation. They then define an execute
method which can return any object that can be serialized
appropriately using gson (http://code.google.com/p/google-gson/).
Here is an example of a trivial command which returns a map of the
arguments it was supplied, with the supplied project and file paths
converted to absolute paths and the file byte offset converted to a
character offset (eclim's vim function eclim#util#GetOffset() returns
the offset in bytes since getting a character offset in vim with multi
byte characters is less reliable, but most eclipse APIs expect
character offsets):
Note: Eclim's source code is grouped by bundles (org.eclim,
org.eclim.core, etc), each of which has java directory containing
the java source code for that bundle.
>
package org.eclim.plugin.core.command.sample;
import java.util.HashMap;
import org.eclim.annotation.Command;
import org.eclim.command.CommandLine;
import org.eclim.command.Options;
import org.eclim.plugin.core.command.AbstractCommand;
import org.eclim.plugin.core.util.ProjectUtils;
import org.eclipse.core.resources.IProject;
@Command(
name = "echo",
options =
"REQUIRED p project ARG," +
"REQUIRED f file ARG," +
"REQUIRED o offset ARG," +
"OPTIONAL e encoding ARG"
)
public class EchoCommand
extends AbstractCommand
{
@Override
public Object execute(CommandLine commandLine)
throws Exception
{
String projectName = commandLine.getValue(Options.PROJECT_OPTION);
String file = commandLine.getValue(Options.FILE_OPTION);
IProject project = ProjectUtils.getProject(projectName);
// translates client supplied byte offset to a character offset using the
// 'project', 'file', 'offset', and 'encoding' command line args.
int offset = getOffset(commandLine);
HashMap<String,Object> result = new HashMap<String,Object>();
result.put("project", ProjectUtils.getPath(project));
result.put("file", ProjectUtils.getFilePath(project, file));
result.put("offset", offset);
if (commandLine.hasOption(Options.ENCODING_OPTION)){
result.put("encoding", commandLine.getValue(Options.ENCODING_OPTION));
}
return result;
}
}
<
When registering the command with the @Command annotation, you give it
a name and a comma separated list of options. Each option consists of
4 parts in the form of:
>
REQUIRED|OPTIONAL s longname ARG|NOARG|ANY
<
Where each part is defined as:
1. REQUIRED or OPTIONAL
2. a single letter short name for the option
3. a long name for the option
4. whether the option requires an argument, no argument, or can
have any number of additional arguments. In the case of ANY, you
should only have one option with that value and when running the
command from the command line, that option should be supplied last.
That should give you the basics on what's involved with creating a new
command, but the biggest hurdle for creating most commands is locating
and deciphering the eclipse API calls that are necessary to implement
the feature you want. Unfortunately most of the eclipse code that
you'll need to hook into will most likely have little to no
documentation so you're going to have to dig through the eclipse code.
Eclim does provide a couple ant tasks to at least help you to quickly
extract any docs or source code found in your eclipse install:
- eclipse.doc: This target will extract any doc jars from your
eclipse install to a 'doc' directory in your eclipse home (or user
local eclipse home).
- eclipse.src: This target will extract any src jars from your
eclipse install to a 'src' directory in your eclipse home (or user
local eclipse home). If you download the sdk version of eclipse then
the jdt and all the core eclipse source will be available. Some
other plugins provide sdk versions which include the source code and
this target can extract those as well, but some plugins don't seem
to have this option when installing via eclipse's update manager
(and may not include the source when installed from a system package
manager). For those you can often download a zip version of their
update site which should include source bundles. Once you've
extracted that file, you can tell this target to extract source
bundles from a specified directory. Here is an example of extracting
the source from an unpacked dltk update site:
>
$ ant -Dsrc.dir=/home/ervandew/downloads/dltk-core-5.0.0/plugins eclipse.src
<
Running a Command
=================
Once you've created your command you then need to compile the code
using eclim's ant build file. After you've done that you can then
start eclimd and execute your command from the command line to test
it:
>
$ eclim -pretty -command echo -p eclim -f org.eclim.core/plugin.properties -o 42 -e utf-8
<
Note: As you are developing your commands, you can avoid restarting
eclimd after every change by using eclim's reload command which will
reload all of eclim's plugin bundles with the exception of
org.eclim.core (so unfortunately it won't help with our example
above if we put that command in the org.eclim.core bundle):>
$ eclim -command reload
<
Adding to Vim
=============
Continuing with our echo command example, we can add the command to
vim by first defining a new vim command in
org.eclim.core/vim/eclim/plugin/eclim.vim:
Note: If the command should only be available for a specific file
type, then you'd put it in a vim/eclim/ftplugin/somefiltetype.vim
file instead.
>
command EclimEcho :call eclim#echo#Echo()
<
Now that we've created the command, we then need to define our
eclim#echo#Echo() function accordingly in
org.eclim.core/vim/eclim/autoload/eclim/echo.vim:
>
" Script Variables {{{
let s:echo_command =
\ '-command echo -p "<project>" -f "<file>" ' .
\ '-o <offset> -e <encoding>'
" }}}
function! eclim#echo#Echo() " {{{
if !eclim#project#util#IsCurrentFileInProject(0)
return
endif
let project = eclim#project#util#GetCurrentProjectName()
let file = eclim#project#util#GetProjectRelativeFilePath()
let command = s:echo_command
let command = substitute(command, '<project>', project, '')
let command = substitute(command, '<file>', file, '')
let command = substitute(command, '<offset>', eclim#util#GetOffset(), '')
let command = substitute(command, '<encoding>', eclim#util#GetEncoding(), '')
let response = eclim#Execute(command)
" if we didn't get back a dict as expected, then there was probably a
" failure in the command, which eclim#Execute will handle alerting the user
" to.
if type(response) != g:DICT_TYPE
return
endif
" simply print the response for the user.
call eclim#util#Echo(string(response))
endfunction " }}}
<
And that's all there is to it. After re-building eclim, restarting
eclimd, and restarting vim, you can now execute the command :EclimEcho
to see the response printed in vim.
Now that you know the basics, you can explore the many existing eclim
commands found in the eclim source code to see detailed examples of
how to access various eclipse features to expose them for use in vim
or the editor of your choice.
You should also take a look at the eclim Plugins
(|development-plugins|) documentation which documents how to create a
new eclim plugin, including information on adding new eclim settings,
managing the plugin's dependencies through its META-INF/MANIFEST.MF,
etc.
vim:ft=eclimhelp

268
vim/bundle/eclim/doc/development/gettingstarted.txt Normal file
View File

@@ -0,0 +1,268 @@
*development-gettingstarted*
Developers Guide
****************
This guide is intended for those who wish to contribute to eclim by
fixing bugs or adding new functionality.
Checking out the code and building it.
======================================
1. Check out the code:
----------------------
>
$ git clone git://github.com/ervandew/eclim.git
<
Note: If you are still using Eclipse 3.7 (Indigo) you will need to
checkout the eclim indigo branch before attempting to build eclim:>
$ cd eclim
$ git checkout indigo
<
2. Build eclim:
---------------
>
$ cd eclim
$ ant -Declipse.home=/your/eclipse/home/dir
<
Note: If your eclipse home path contains a space, be sure to quote
it:>
> ant "-Declipse.home=C:/Program Files/eclipse"
<
This will build and deploy eclim to your eclipse and vim directories.
Note: If your vimfiles directory is not located at the default
location for your OS, then you can specify the location using the
"vim.files" property:>
$ ant -Dvim.files=<your vimfiles dir>
<
When the build starts, it will first examine your eclipse installation
to find what eclipse plugins are available. It will then use that list
to determine which eclim features/plugins should be built and will
output a list like the one below showing what will be built vs what
will be skipped:
>
[echo] ${eclipse}: /opt/eclipse
[echo] # Skipping org.eclim.adt, missing com.android.ide.eclipse.adt
[echo] # Skipping org.eclim.dltk, missing org.eclipse.dltk.core
[echo] # Skipping org.eclim.dltkruby, missing org.eclipse.dltk.ruby
[echo] # Skipping org.eclim.pdt, missing org.eclipse.php
[echo] Plugins:
[echo] org.eclim.cdt
[echo] org.eclim.jdt
[echo] org.eclim.pydev
[echo] org.eclim.sdt
[echo] org.eclim.wst
<
In this case we can see that four eclim plugins will be skipped along
with the eclipse feature that would be required to build those
plugins. If you see an eclipse feature in that list that you know you
have, it may be the case that you installed it as a regular user, so
that feature was installed in your user local eclipse directory. In
that case you will need to notify the build of that directory so it
can examine it as well (just replace the <version> portion below with
the actual version found in your ~/.eclipse directory):
>
$ ant \
-Declipse.home=/opt/eclipse \
-Declipse.local=$HOME/.eclipse/org.eclipse.platform_<version>
<
If you don't want to supply the eclipse home directory, or any other
properties, on the command line every time you build eclim, you can
create a user.properties file at the eclim source root and put all
your properties in there:
>
$ vim user.properties
eclipse.home=/opt/eclipse
vim.files=${user.home}/.vim/bundle/eclim
<
Note: The eclim vim help files, used by the :EclimHelp
(|vim-core-eclim#:EclimHelp|) command, are not built by default. To
build these you first need to install sphinx
(http://sphinx-doc.org), then run the following command:>
$ ant vimdocs
<
This target also supports the vim.files property if you want the
docs deployed to a directory other than the default location.
*coding-style*
Coding Style
============
When contributing code please try to adhere to the coding style of
similar code so that eclim's source can retain consistency throughout.
For java code, eclim includes a checkstyle configuration which can be
run against the whole project:
>
$ ant checkstyle
<
or against the current java file from within vim:
>
:Checkstyle
<
*development-patches*
Developing / Submitting Patches
===============================
The preferred means of developing and submitting patches is to use a
github fork. Github provides a nice guide to forking
(http://help.github.com/forking/) which should get you started.
Although using a github fork is preferred, you can of course still
submit patches via email using git's format-patch command:
>
$ git format-patch -M origin/master
<
Running the above command will generate a series of patch files which
can be submitted to the eclim development group
(http://groups.google.com/group/eclim-dev).
Building the eclim installer
============================
It should be rare that someone should need to build the eclim
installer, but should the need arise here are the instructions for
doing so.
To build the installer you first need a couple external tools
installed:
- sphinx (http://sphinx-doc.org): Sphinx is used to build the eclim
documentation which is included in the installer.
Eclim also uses a custom sphinx theme which is included in eclim as
a git submodule. So before you can build the installer you will need
to initialize the submodule:
>
$ git submodule init
$ git submodule update
<
- graphviz (http://www.graphviz.org/): The docs include a few uml
diagrams which are generated using plantuml
(http://plantuml.sourceforge.net/) (included in the eclim source
tree) which in turn requires graphviz (http://www.graphviz.org/).
- formic (http://github.com/ervandew/formic): The eclim installer
has been developed using the formic framework, and requires it to
build the installer distributables. Formic doesn't currently have
an official release, so you'll need to check out the source code:
>
$ git clone git://github.com/ervandew/formic.git
<
After checking out the code, you'll need to build the formic
distribution:
>
$ cd formic
$ ant dist
<
Then extract the formic tar to the location of your choice
>
$ tar -zxvf build/dist/formic-0.2.0.tar.gz -C /location/of/your/choice
<
Once you have installed the above dependencies, you can then build the
eclim installer with the following command.
>
$ ant -Dformic.home=/your/formic/install/dir dist
<
In lieu of supplying the formic home on the command line, you can
instead put it in a user.properties file at the eclim source root:
>
$ vim user.properties
formic.home=/your/formic/install/dir
<
What's Next
===========
Now that you're familiar with the basics of building and patching
eclim, the next step is to familiarize yourself with the eclim
architecture and to review the detailed docs on how new features are
added.
All of that and more can be found in the eclim development docs
(|development-index|).
vim:ft=eclimhelp

21
vim/bundle/eclim/doc/development/index.txt Normal file
View File

@@ -0,0 +1,21 @@
*development-index*
Development Docs
****************
Developers Guide (|development-gettingstarted|)
Architecture (|development-architecture|)
Explains the underlying architecture that eclim utilizes including
an overview of the call sequence from vim to eclipse.
Commands (|development-commands|)
Details the process of adding a new command to vim which calls to a
corresponding implementation in eclipse.
Plugins (|development-plugins|)
Details the process of adding a new plugin to eclim.
... More To Come
vim:ft=eclimhelp

226
vim/bundle/eclim/doc/development/plugins.txt Normal file
View File

@@ -0,0 +1,226 @@
*development-plugins*
Plugins
*******
Note: This guide is a work in progress. If in the process of writing
a new plugin you find anything here that is unclear or missing,
please don't hesitate to post to the eclim-dev
(http://groups.google.com/group/eclim-dev) mailing list with
questions, suggestions, etc.
To allow eclim to support different languages, eclim is broken up into
eclipse plugins, each of which depend on a corresponding eclipse
feature which provides support for that language. When you install or
build eclim, it will examine your eclipse install to determine which
features are available and will add the corresponding eclim plugins to
expose those features. This page documents the core aspects of what
goes into the creation of a new eclim plugin.
Bootstrapping the plugin artifacts
==================================
Eclim includes a set of templates to help you bootstrap a new plugin.
To utilize them you can run the following ant target:
>
$ ant plugin.create
<
You will be prompted to enter a name for this plugin along with some
guidelines on choosing an appropriate name.
Once you've chosen a name, the plugin's directory structure will be
created and populated with bare bones version of the required
artifacts. Eclim's build.xml file will also be updated to include a
target to the new plugin's unit test target.
Updating the initial artifacts
==============================
After you've bootstrapped your plugin, you can now start updating the
generated artifacts:
build_<plugin_name>.gant
------------------------
The first file you'll need to modify is a gant file for your plugin.
The main eclim build.gant script will load this file during the build
process to determine what the plugin's eclipse dependency is, so it
knows whether it can be built against the target eclipse install. So
the first thing we need to do is to fill in that information by
updating the feature_<plugin_name> variable with the name of the
eclipse feature that this plugin depends on. For example, the eclim
jdt plugin has this set to 'org.eclipse.jdt'. The build script will
look in the features directory of your eclipse install (including the
dropins and your user local eclipse dir if set), to find this feature,
so the value you set, must be found in one of those locations (the
version suffixes will be removed from the features in order to match
it against the value you've set).
You'll also notice that there is a unit test target in the gant file.
You can ignore that for now.
META-INF/MANIFEST.MF
--------------------
The next file to note is the plugin's META-INF/MANIFEST.MF. This is
the file that eclipse will use to determine how to load the bundle and
what to include in its classpath. The only part of this file that you
should edit is the Require-Bundle: section. This is a comma separated
list of bundles (or plugins) which this bundle depends on. When this
bundle is loaded only those bundles listed here will be available in
the classpath. So when you start running commands you've written
later, if you receive a ClassNotFoundException, that is likely due to
the bundle containing that class not being listed in your plugin's
Require-Bundle: list. At this point you probably don't know yet what
bundles you need to add to this list. When you start writing commands
for your plugin, you'll have to find out which bundles contain the
classes imported from the eclipse plugin you are integrating with, and
you'll need to add those bundles accordingly.
It's also worth noting that eclim provides a custom classpath
container which scans the manifest of each eclim plugin and loads the
required bundles of each into the classpath. So when adding new
bundles, if you want validation, search, code completion, etc to work
with classes from those new bundles, you'll have to restart the eclim
daemon. While restarting can be annoying, this is generally better
than having to add/remove entries from the .classpath file or worrying
about one user having different bundle version numbers from another.
PluginResources.java
--------------------
At this point you'll typically need to start customizing your plugin's
org.eclim.<name>/java/org/eclim/plugin/<name>/PluginResources.java
file. Here is where you will map a short alias to the project nature,
or natures, of the plugin you are integrating with, register a project
manager for initializing project's for this plugin, register any
plugin settings that users can configure, etc. You'll be doing all
this inside of the initialize method which has been generated for you.
Project Nature
~~~~~~~~~~~~~~
You'll first need to find out where the plugin's nature id is defined.
Here are some examples that should give you an idea of where to look:
- jdt: org.eclipse.jdt.core.JavaCore.NATURE_ID
- cdt:
- org.eclipse.cdt.core.CProjectNature.CNATURE_ID
- org.eclipse.cdt.core.CCProjectNature.CC_NATURE_ID
- dltkruby: org.eclipse.dltk.ruby.core.RubyNature.NATURE_ID
- adt: com.android.ide.eclipse.adt.AdtConstants.NATURE_DEFAULT
One way to find it is to open up the .project file in a project
containing the nature, locate the fully qualified name in the
<natures> section, then grep the plugin's code for that name.
Once you have the reference to the nature id, you can then create a
public static variable called NATURE:
>
public static final String NATURE = SomeClass.NATURE_ID;
<
You'll be using this constant as the key to register features for
project containing this nature, but first we'll register a short alias
for this nature since the actual nature id tends to be long and
unstandardized, and we don't want users to have to type it out when
creating projects from eclim:
>
ProjectNatureFactory.addNature("shortname", NATURE);
<
Project Manager
~~~~~~~~~~~~~~~
The next thing you'll probably need to do is to create a project
manager for your project
(org.eclim.<name>/java/org/eclim/plugin/<name>/project/SomeProjectManager.java).
The project manager is responsible for performing any post create,
update, delete, or refresh logic required for projects of this nature.
This logic can include things such as creating an initial
classpath/buildpath, validate the classpath/buildpath on update,
forcing a full update of the search index on refresh, or any number of
other things.
Overriding the create method will almost certainly be necessary, but
the logic you'll need here varies widely. Finding what you'll need is
a matter of digging through the parent plugin's source code, typically
looking for the project creation wizard class, to see what it does to
create a project of this nature and later comparing the created
artifacts from your code against those of a project created from the
eclipse gui. This can be a difficult hurdle to get past for someone
doing this the first time, so please don't be shy about asking for
help on the eclim-dev (http://groups.google.com/group/eclim-dev)
mailing list.
Eclim does provide a couple ant tasks to at least help you to quickly
extract any docs and source code found in your eclipse install:
- eclipse.doc: This target will extract any doc jars from your
eclipse install to a 'doc' directory in your eclipse home (or user
local eclipse home).
- eclipse.src: This target will extract any src jars from your
eclipse install to a 'src' directory in your eclipse home (or user
local eclipse home). If you download the sdk version of eclipse then
the jdt and all the core eclipse source will be available. Some
other plugins provide sdk versions which include the source code and
this target can extract those as well, but some plugins don't seem
to have this option when installing via eclipse's update manager
(and may not include the source when installed from a system package
manager). For those you can often download a zip version of their
update site which should include source bundles. Once you've
extracted that file, you can tell this target to extract source
bundles from a specified directory. Here is an example of extracting
the source from an unpacked dltk update site:
>
$ ant -Dsrc.dir=/home/ervandew/downloads/dltk-core-5.0.0/plugins eclipse.src
<
Once you've created your project manager, you then map it to your
plugin's nature inside of your PluginResources.initialize method like
so:
>
ProjectManagement.addProjectManager(NATURE, new SomeProjectManager());
<
Project Settings
~~~~~~~~~~~~~~~~
At this point you should have the minimum of what is needed for a new
plugin. Hopefully you can now create new projects with your plugin's
defined nature. The next step would be to start adding commands
(|development-commands|) to provide validation, code completion, etc.
The remaining items in this list are not required to continue. They
provide you with the ability to setup your own preferences or to
expose the parent plugin's defined preferences inside of vim. When
you've come to the point that you need to work with preferences, then
feel free to come back here and continue reading.
To Be Continued...
vim:ft=eclimhelp

437
vim/bundle/eclim/doc/eclimd.txt Normal file
View File

@@ -0,0 +1,437 @@
*eclimd*
The Eclim Daemon
****************
*eclimd-headless*
Headless eclipse server
=======================
The most mature usage scenario that eclim provides, is the running of
a headless eclipse server and communicating with that server inside of
vim. Starting and stopping of the headless eclipse instance is
detailed below.
Starting eclimd
Linux / Mac / BSD (and other unix based systems): To start eclimd from
linux, simply execute the eclimd script found in your eclipse root
directory: $ECLIPSE_HOME/eclimd
Note: When starting the eclim daemon, you must start it as the same
user who will be running vim.
Windows: The easiest way to start eclimd in windows is to double click
on the eclimd.bat file found in your eclipse root directory:
%ECLIPSE_HOME%/eclimd.bat
Note: Even though an eclipse gui is not started in eclim's headless
mode, eclipse still requires a running X server to function. To run
eclimd on a truely headless server, please see the headless guide
(|install-headless|).
Stopping eclimd
To cleanly shutdown eclim use any one of the following.
- From Vim:
>
:ShutdownEclim
<
- From a console:
>
$ $ECLIPSE_HOME/eclim -command shutdown
<
- Lastly you can use Ctrl-C at the console if you are running eclimd
in the foreground, or issue a kill to the eclimd java process.
>
$ kill *pid*
<
You will need to kill the java process since killing the eclimd or
eclipse process will not do so. While eclim provides a shutdown
hook to support a clean shutdown when the java process is killed in
this manner, it is still recommended that you utilize one of the
first two methods instead, and reserve this as a last resort. Also
note that when killing the java process eclipse will pop up an alert
dialog notifying you that the java process was terminated underneath
it. This is nothing to be alarmed about.
*eclimd-headed*
Headed eclipse server
=====================
For users that find themselves periodically needing the eclipse gui,
or otherwise wanting to keep the gui open while using eclim, there is
support for running the eclim server inside of a headed eclipse
instance.
Starting eclimd
The eclim daemon inside of eclipse is implemented as an eclipse view
which can be found via:
Window ‣ Show View ‣ Other ‣ Eclim ‣ eclimd
The view will be opened in a new tab in the same pane as the
"Problems" tab, as shown below.
[image]
Note: By default, if you open an instance of gvim from within
eclipse, the eclimd view will be opened for you if necessary. This
behavior is configurable via the Vimplugin preferences.
Stopping eclimd
As long as the eclimd tab is open then the eclim daemon will be
running. Stopping the eclim daemon is just a matter of closing the
eclimd tab. Also note that leaving the tab open and closing eclipse
will shutdown the daemon as well, and on the next start of eclipse the
tab will be opened, but the eclim daemon will not start until the tab
is forced to display itself. In other words, the daemon will not start
until the eclimd tab is the active tab in that group.
*gvim-embedded*
Embedded gvim
=============
Note: Embedding is only supported on Windows and Unix systems (where
gvim is compiled with the gtk gui).Embedding of macvim for OSX is
not supported since macvim does not currently have the ability to be
embedded like gvim. Macvim can still be used to open files from
eclipse, but macvim will open as an external editor. Also note that
macvim snapshots 56 through 63 contain a bug
(https://github.com/b4winckler/macvim/pull/22) where opening a file
from eclipse will open an instance of macvim, but the file will not
be loaded into that instance.
Another feature provided by eclim for those who prefer to work inside
of the eclipse gui, is the embedding of gvim inside of eclipse. This
feature is provided by an eclim local fork of vimplugin
(http://vimplugin.org). The feature adds a new editor to eclipse
which allows you to open files in gvim by right clicking the file name
in the eclipse tree and then selecting:
Open With ‣ Vim
[image]
Please note that if you want to use supported eclipse features (code
completion, validation, searching, etc.) from the embedded gvim
editor, you must have the eclimd view open.
Note: If you'd like to have the embedded gvim editor as the default
for one or more file types, you can configure it to be in your
eclipse preferences:Window ‣ Preferences ‣ General ‣ Editors ‣ File
Associations
The eclim installer should take care of locating your gvim
installation for use inside of eclipse, but in the event that it could
not locate it, you can set the location and other settings via the
vimplugin preferences:
Window ‣ Preferences ‣ Vimplugin
For MacVim users on OSX, the eclim installer will attempt to locate
MacVim's mvim script on your path. If it's not found you can set the
location of that script in the Vimplugin preferences:
Eclipse ‣ Preferences ‣ Vimplugin
Note: If you have a non-eclim version of vimplugin installed you
should remove it prior to using the eclim version.
Note: Some users have reported issues with the embedded gvim's
command line being cut off or possible rendering issues when
scrolling through the file. If you experience either of these
issues, try adding the following to your vimrc file, which should
hopefully resolve those problems:>
set guioptions-=m " turn off menu bar
set guioptions-=T " turn off toolbar
<
Additionally, some users have reported that gvim's left scrollbar
may also need to be disabled:>
set guioptions-=L " turn off left scrollbar
set guioptions-=l
<
*eclim-gvim-embedded-focus*
Embedded gvim focus
In some windowing environments, the embedded gvim is treated more like
a separate window. The result of this is that clicking the eclipse tab
(or using tab focusing keyboard shortcuts) may focus that tab, but it
won't focus the embedded gvim on that tab. Eclim adds a setting to
vimplugin which when enabled, will attempt to simulate a click on the
embedded gvim window to force it to focus:
Window ‣ Preferences ‣ Vimplugin ‣ Force gvim focus via automated
click
*eclim-gvim-embedded-shortcuts*
Eclipse/Vim key shortcuts in embedded gvim
Depending on your OS and windowing system, when the embedded gvim has
focus, you will fall into one of two groups:
1. In the first group of users, all key presses are received by
eclipse prior to sending them to gvim.
For this group, when typing a possible key shortcut (ctrl-n for
example), eclipse will first evaluate that key stroke to see if
there are any eclipse key bindings registered. If there are, then
eclipse will run the associated command and the key stroke is never
sent to gvim. If no key binding is found, then eclipse will pass
the key stroke through to gvim. What this means for you is that
for any gvim key mappings that you use that have an eclipse key
binding, they will not be evaluated inside of gvim. So, if you
encounter this issue, you'll need to remap the keys in vim or
eclipse. To remove the key binding from the eclipse side, simply
open the "Keys" preferences page:
Window ‣ Preferences ‣ General ‣ Keys
Then find the entry in the list that corresponds with the key
binding you want to remove, select it, and hit the "Unbind Command"
button.
Note: By default eclim will auto-remove a couple of the standard
eclipse bindings whenever an embedded gvim editor has focus and
then restore them with a non-gvim editor gains focus:
- Ctrl+U: in eclipse this runs "Execute", but in gvim this is
needed to run code completion (ex. ctrl-x ctrl-u).
- Ctrl+N: in eclipse this runs the "New" wizard, but in gvim
this is also needed as a part of code completion, to scroll
through the results.
- Ctrl+V: in eclipse this pastes text from the clipboard
(though not into gvim), but in gvim this is needed for column
wise visual selections.
- Ctrl+W: in eclipse this closes a tab, but in gvim this is
needed to switch windows (ex. ctrl-w j).
- Ctrl+X: in eclipse this cuts a selection to the clipboard,
but in gvim this is needed to start various insert completions
(ex. ctrl-x ctrl-u).
- Delete: prevent the eclipse delete key binding from
suppressing delete attempts in the embedded gvim.
*FeedKeys*
2. In the second group, all key presses are received by gvim and
not evaluated at all by eclipse.
For this group of users, you may have an eclipse key shortcut that
you like to use (Shift+Ctrl+R for example), but when you hit that
key combination, it will be evaluated by gvim instead of eclipse.
To remedy this situation, eclim provides a means to map eclipse
shortcuts inside of gvim. To register a shortcut, simply add your
mappings to your vimrc, gvimrc, or other standard gvim file like
so:
>
" maps Ctrl-F6 to eclipse's Ctrl-F6 key binding (switch editors)
nmap <silent> <c-f6> :call eclim#vimplugin#FeedKeys('Ctrl+F6')<cr>
" maps Ctrl-F7 to eclipse's Ctrl-F7 key binding (switch views)
nmap <silent> <c-f7> :call eclim#vimplugin#FeedKeys('Ctrl+F7')<cr>
" maps Ctrl-F to eclipse's Ctrl-Shift-R key binding (find resource)
nmap <silent> <c-f> :call eclim#vimplugin#FeedKeys('Ctrl+Shift+R')<cr>
" maps Ctrl-M to eclipse's Ctrl-M binding to maximize the editor
nmap <silent> <c-m> :call eclim#vimplugin#FeedKeys('Ctrl+M', 1)<cr>
<
The value supplied to the FeedKeys function must be an eclipse
compatible key binding string as found in:
Windows ‣ Preferences ‣ General ‣ Keys
Be sure to notice the extra argument to the FeedKeys function in
the last mapping. Supplying 1 as the arg will result in the
refocusing of gvim after the eclipse key binding has been executed.
*eclimrc*
~/.eclimrc
==========
On unix platforms (linux, mac, bsd) eclim supports an optional
.eclimrc file located in your home directory. In this file you may
supply any system properties or vm args which you would like passed to
eclimd at startup. The format of this file is the same as the
standard java properties file format with the exception of any vm args
which you would like to include.
Ex.
>
# Bind eclimd to all interfaces
nailgun.server.host=0.0.0.0
# Specifies the port that nailgun / eclimd listens on for client requests.
nailgun.server.port=10012
# Specifies the workspace directory to use
# See $ECLIPSE_HOME/configuration/config.ini for other osgi properties.
osgi.instance.area.default=@user.home/myworkspace
# increase heap size
-Xmx256M
# increase perm gen size
-XX:PermSize=64m
-XX:MaxPermSize=128m
<
The eclim client will also utilize this file, but only to determine
the nailgun server port should you choose to change the default.
Note: Your system must have perl and sed available so that eclim can
process your .eclimrc file.
Both the eclim and eclimd scripts also support a -f argument allowing
you to specify an alternate location for your .eclimrc:
>
$ eclimd -f ~/.my_eclimrc
$ eclim -f ~/.my_eclimrc -command ping
<
eclimd logging
==============
Eclimd utilizes log4j for all of its logging. As such, the logging
can be configured via the
$ECLIPSE_HOME/plugins/org.eclim_version/log4j.xml file.
By default, eclimd writes all logging info to both the console and to
a log file in your workspace: <workspace>/eclimd.log
*eclimd-multiworkspace*
Multiple Workspaces
===================
Running eclim against more than one eclipse workspace can be
accomplished by running multiple eclimd instances. You must configure
each instance to run nailgun on a unique port and supply the path to
the workspace you which that instance to use. Once your eclimd
instances are up and running the vim client will automatically
determine which server to send requests to based on your context. In
some cases you may be prompted for which workspace to use if one
cannot be determined for you.
Below are some different ways in which you can configure your eclimd
instances:
1. All Users: Supply the nailgun port and eclipse workspace path
when starting eclimd:
>
$ eclimd -Dosgi.instance.area.default=@user.home/workspace1 -Dnailgun.server.port=9091
$ eclimd -Dosgi.instance.area.default=@user.home/workspace2 -Dnailgun.server.port=9092
<
If you are using the eclimd view in the eclipse gui, then you can
start the eclipse gui with the desired nailgun server port (note
that you must place the -vmargs option before the list of jvm
arguments):
>
$ eclipse -vmargs -Dnailgun.server.port=9092
<
2. Linux, OSX, BSD Users: Specify the port and workspace in eclimrc
files and start eclimd with the -f or --file argument:
>
$ vim ~/.eclimrc1
osgi.instance.area.default=@user.home/workspace1
nailgun.server.port=9091
$ vim ~/.eclimrc2
osgi.instance.area.default=@user.home/workspace2
nailgun.server.port=9092
$ eclimd -f ~/.eclimrc1
$ eclimd --file ~/.eclimrc2
<
Note: The -f/--file argument is not supported by eclipse so the
above option is only available when using a headless eclimd
instance.
3. Windows Users: Create Windows shortcuts:
- In Windows Explorer, open your eclipse folder.
- Hold down the right mouse button and drag the eclimd.bat file
to where you want the shortcut to exist (like your desktop) and
release the right mouse button.
- Choose "Create Shortcut(s) Here"
- Right click the shortcut and choose "Properties"
- On the "Shortcut" tab edit the "Target:" field and append:
-Dosgi.instance.area.default=@user.home/workspace1
-Dnailgun.server.port=9091
- Repeat this process for your other workspaces.
*eclimd-extdir*
Hosting third party nailgun apps in eclimd
==========================================
Since nailgun provides a simple way to alleviate the startup cost of
the jvm, other projects utilize it as well. However, running several
nailgun servers isn't ideal, so eclim supports hosting other nailgun
apps via an ext dir where you can drop in jar files which will be made
available to eclim's nailgun server.
The ext dir that eclim reads from is located in your vim files
directory:
Linux / BSD / OSX:
>
~/.eclim/resources/ext
<
Windows:
>
$HOME/.eclim/resources/ext
<
vim:ft=eclimhelp

356
vim/bundle/eclim/doc/faq.txt Normal file
View File

@@ -0,0 +1,356 @@
*faq*
FAQ / Troubleshooting
*********************
FAQ
===
*eclim_workspace*
How do I tell eclim which eclipse workspace to use?
---------------------------------------------------
To configure the workspace you can start eclimd like so:
>
$ eclimd -Dosgi.instance.area.default=@user.home/another_workspace
<
Note the system property osgi.instance.area.default, which is used to
specify the location of your workspace. Also note the variable
@user.home which will be replaced with your home directory at runtime.
If you are running a unix variant (linux, mac osx, bsd, etc.) then you
can specify the above system property in the .eclimrc file in your
home directory.
>
$ echo "osgi.instance.area.default=@user.home/another_workspace" >> ~/.eclimrc
<
*eclimd_options_windows*
For Windows users there are a couple alternatives to the unsupported
.eclimrc:
1. Your first option is to add a new environment variable:
- Windows 2000: Control Panel ‣ System ‣ Advanced ‣ Environment
Variables Windows XP: Control Panel ‣ Performance And Maintenance
‣ System ‣ Advanced ‣ Environment Variables
- Under "User variables..." click "New..." Variable Name:
ECLIMD_OPTS Variable Value:
-Dosgi.instance.area.default=@user.home/another_workspace
- Then you can start eclimd as normal (via the eclimd.bat file).
2. The second option is to create a shortcut to the eclimd.bat
file:
- In Windows Explorer, open your eclipse folder.
- Hold down the right mouse button and drag the eclimd.bat file
to where you want the shortcut to exist (like your desktop) and
release the right mouse button.
- Choose "Create Shortcut(s) Here"
- Right click the shortcut and choose "Properties"
- On the "Shortcut" tab edit the "Target:" field and append:
-Dosgi.instance.area.default=@user.home/another_workspace
*eclim_proxy*
How can I configure eclim to use a proxy?
-----------------------------------------
The occasional eclim feature requires network access to function
properly. For example, xml validation may require validating the file
against a dtd or xsd located remotely. If you are behind a proxy then
you may need to provide eclim with the necessary proxy settings.
>
$ eclimd -Dhttp.proxyHost=my.proxy -Dhttp.proxyPort=8080
<
If you are running a unix variant (linux, mac osx, bsd, etc.) then you
can specify the above system property in the .eclimrc file in your
home directory.
>
$ echo -e "http.proxyHost=my.proxy\nhttp.proxyPort=8080" >> ~/.eclimrc
<
If your proxy requires authentication, you'll need to supply the
-Dhttp.proxyUser and -Dhttp.proxyPassword properties as well.
On Windows systems you can use the same steps described above, for
setting the workspace location, to also set the proxy settings.
*eclim_memory*
How do I specify jvm memory arguments for eclim (fix OutOfMemory errors).
-------------------------------------------------------------------------
If you are using the headless version of eclimd, then you have a
couple options:
1. pass the necessary jvm args to eclimd. For example, to increase
the heap size:
>
$ eclimd -Xmx256M
<
2. if you are using a unix variant, then you can add the necessary
vm args to a .eclimrc file in your home directory.
>
# increase heap size
-Xmx256M
# increase perm gen size
-XX:PermSize=64m
-XX:MaxPermSize=128m
<
On Windows systems you can use the same steps described above, for
setting the workspace location, to also specify the jvm memory
args.
If you are using the headed version of eclimd, then setting the jvm
memory arguments for eclim is the same procedure as setting them for
eclipse. Details can be found on the eclipse wiki
(http://wiki.eclipse.org/Eclipse.ini).
*eclim_troubleshoot*
How do I troubleshoot features not functioning, or errors encountered?
----------------------------------------------------------------------
For troubleshooting eclim, please see the dedicated troubleshooting
section below.
*eclim_full_headless*
How can I run eclimd on a truly headless server?
------------------------------------------------
Please see the headless guide (|install-headless|).
*eclim_encoding*
How can I set the default encoding used by eclipse/eclimd?
----------------------------------------------------------
To set the default encoding you can set the file.encoding system
property according to your setup:
1. Headless eclimd users on any unix variant (Linux, OSX, etc) can
simply add the property your .eclimrc file in your home directory:
>
# set the default file encoding
file.encoding=utf-8
<
2. Headless eclimd users on Windows can add the system property
(eg. -Dfile.encoding=utf-8) using the same steps described above,
for setting the workspace location.
3. Headed eclimd users can add the system property (eg.
-Dfile.encoding=utf-8) to your eclipse.ini file found in your
eclipse install's root directory. Be sure to add the property on a
new line after the -vmargs line:
>
...
-vmargs
...
-Dfile.encoding=utf-8
<
You can read more about the eclipse.ini file on the eclipse wiki
(http://wiki.eclipse.org/Eclipse.ini).
*troubleshooting*
Troubleshooting
===============
The purpose of this guide is to serve as a means to help troubleshoot
common issues encountered when getting start with eclim, or providing
information if you've discovered a possible bug.
The first thing to note is that as of eclim 1.6.1, errors raised by
eclimd when executing an autocmd from vim, like validating a file on
write, are no longer echoed as errors to the user. Instead these
errors are logged and only displayed if your eclim log level is set to
a relevant level. You can set the log level at any time by running:
>
:let g:EclimLogLevel = 'trace'
<
in vim, which in this case sets the logging to verbose (the default
log level is 4). After setting the log level any external commands
that are run or autocmd errors encountered will be printed (you may
need to run :messages to see them all).
Below are a series of sections broken up by the behavior (or lack of)
experienced and the steps for diagnosing the cause of that behavior.
If you can't find the answer to your question here, be sure to take a
look at the faq to see if your question is answered there.
*ts_workspace*
Eclim does not recognize any of my existing projects.
-----------------------------------------------------
A fairly common occurrence for users new to eclim, is that after
starting eclimd and then attempting to execute some project dependent
functionality, the functionality appears to do nothing or eclim
complains that the project could not be determined. If you have
existing projects created in eclipse and eclim is not finding them,
then the likely cause is that your projects are located in a
non-default workspace location.
For the answer to how to specify the location of your workspace when
starting eclimd, please see the faq devoted to this.
*ts_completion*
I'm editing a [java, python, php, etc] file and code completion doesn't work.
-----------------------------------------------------------------------------
- If you receive the message "E764: Option 'completefunc' is not
set", please see the file type section below.
- Next step is to make sure that the current file is in an eclipse
project by running the following command in the vim windows
containing the file you are working on.
>
:ProjectInfo
<
If that returns an error that it is unable to determine the project,
then see the workspace section above or the guide on creating a new
project (|gettingstarted-create|).
- If the correct project info is found, then try running the
completion again, if it still doesn't return any results run the
command:
>
:messages
<
This will print out any messages that you might have missed. If you
see an error regarding a java exception while running a command then
see the section on troubleshooting exceptions.
*ts_ftplugin*
I'm editing a [java, python, php, etc] file and none of the file type commands exist.
-------------------------------------------------------------------------------------
This usually indicates that you don't have file type plugins enabled
in vim. To check you can run:
>
:EclimValidate
<
If it complains about filetype plugin support not being found, then
follow its directions on adding the following to your vimrc:
>
filetype plugin indent on
<
*ts_signs_misplaced*
Code validation signs are showing up on the wrong lines.
--------------------------------------------------------
This is most likely a result of eclipse being setup to use a different
file encoding than vim, most likely cp1251 (windows-1251) vs utf-8.
You should be able to resolve this issue by setting eclipse's default
encoding accordingly.
If you're unsure what encoding to use, try using utf-8.
*ts_exception*
I received a java exception "while executing command" message.
--------------------------------------------------------------
If you receive a java exception while performing some action in vim,
it should also include a message indicating the issue. However, if
you receive something like a NullPointerException or some other
exception which doesn't include a helpful message, then you may have
encountered a bug.
Once you've encountered this type of issue, the first step it to get
more details which you can do by enabling eclim debugging in vim:
>
:let g:EclimLogLevel = 'trace'
<
Then you can perform the same action that triggered the error again.
This time you should receive the full stack trace of the error.
Once you've obtained the stack trace, the next step it to send it to
the eclim-user (http://groups.google.com/group/eclim-user) mailing
list along with a description of what you were doing when the error
occurred, as well as the OS you are on, and whether you were using
eclimd headless or headed (inside of the eclipse gui).
*ts_incompatible_plugins*
Incompatible Plugins
--------------------
There are some third party eclipse plugins which currently may
interfere with eclim. Below is a list of these known plugin
incompatibilities.
- Spring IDE: At least one user has reported that eclim's java
validation no longer works after installing the Spring IDE.
- viPlugin: Attempting to open a file using the embedded gvim
support fails if viPlugin is installed. This issue has been
reported on the viPlugin site.
vim:ft=eclimhelp

131
vim/bundle/eclim/doc/features.txt Normal file
View File

@@ -0,0 +1,131 @@
*features*
Features
********
The following is a partial list of eclim features with much more still
to come. For more details please see the detailed documentation
(|vim-index|). For a more comprehensive list you can also visit the
cheatsheet (|cheatsheet|).
Eclipse Projects
================
- Create, update, and delete Eclipse projects.
- Easily manage Eclipse .classpath files (support for maven and
ivy).
- Quickly and easily manage settings globally or on a project basis.
C/C++
=====
- Context sensitive code completion.
- Searching.
- Source code validation.
Css
===
- Context sensitive code completion.
- Source code validation.
Html
====
- Context sensitive code completion.
- Automatic validation (w/ visual marking of errors and warnings).
Java
====
- Automatic source code validation (w/ visual marking of errors and
warnings).
- Context sensitive code completion.
- Code correction suggestions with option to apply a suggestion.
- Class constructor generation.
- Java Bean getter and setter generation.
- Generation of delegate methods.
- Java source and java doc searching capabilities.
- Generate stub methods from implemented interfaces or super
classes.
- Generate stub methods for junit testing.
- Quickly clean and sort imports and easily import new classes.
- Automatic generation of logging initialization code, upon first
usage of a logger.
- Javadoc generation for package, class, field, method, etc.
- Java regular expression testing.
- Support for Checkstyle.
- Validation of log4j xml files.
Android
-------
- Support for creating android projects from vim.
Ant
---
- Ant execution from any file.
- Context sensitive code completion when editing build files.
- Automatic validation of build files (w/ visual marking of errors
and warnings).
- Quick access to ant documentation.
Maven
-----
- Maven execution from any file.
- Maven repository searching and ability to add results to pom file.
JavaScript
==========
- File validation using jsl (http://www.javascriptlint.com/).
Php
===
- Context sensitive code completion.
- Searching.
- Source code validation.
Python
======
- Context sensitive code completion.
- Find element definition/references support.
- Source code validation.
- Regular expression testing.
- Django functionality.
Ruby
====
- Context sensitive code completion.
- Searching.
- Source code validation.
Vim Script
==========
- Find user defined command, function, or global variable
declarations / references.
- Quickly lookup help topic for a keyword, functions, command, etc.
Xml / Dtd / Xsd
===============
- Automatic validation (w/ visual marking of errors and warnings).
- Quickly look up element definition from the current xml file's dtd
or xsd.
- Context sensitive code completion.
Common Vim Functionality
========================
- Commands to locate a project, workspace, or current file relative
file and open it (split, edit, or tabnew).
- Much more...
vim:ft=eclimhelp

49
vim/bundle/eclim/doc/gettinghelp.txt Normal file
View File

@@ -0,0 +1,49 @@
*gettinghelp*
Getting Help
************
Mailing Lists
=============
If at any time you have any questions or feedback, feel free to post
to one of the eclim mailing lists:
- eclim-user (http://groups.google.com/group/eclim-user): For all
questions regarding installation, usage, troubleshooting, etc.
- eclim-dev (http://groups.google.com/group/eclim-dev): For all
eclim development related discussions.
IRC (#eclim on freenode.net)
============================
If you would like to get help or ask questions on IRC, then feel free
to join #eclim on freenode.net. Please note that I (Eric Van
Dewoestine, ervandew on irc) try to stay in the channel as much as
possible, but I might not be available to answer questions
immediately. It's also worth noting that I live in California, so if
you are in Europe, Asia, or some other timezone whose normal waking
hours don't overlap well with mine, then you may be better off getting
help using one of the mailing lists above.
Reporting Bugs
==============
If you've found a bug please report the issue to either the eclim-dev
(http://groups.google.com/group/eclim-dev) mailing list or create a
new issue on eclim's github issue tracker
(http://github.com/ervandew/eclim/issues).
When reporting a bug, please include the following information:
- What OS are you on?
- Linux users: please include the distro and version.
- What version of eclim, vim, and eclipse are you using?
- Linux users: please indicate whether you installed eclipse via
your distro's package manager or not, and if not, please indicate
what distribution of eclipse you are using ("Eclipse Classic",
"Eclipse IDE for C/C++ Developers", some other eclipse bundle).
vim:ft=eclimhelp

323
vim/bundle/eclim/doc/gettingstarted.txt Normal file
View File

@@ -0,0 +1,323 @@
*gettingstarted*
Getting Started
***************
Once you've installed (|install|) eclim, the next step is to create
your first project after which you can then start writing code and
familiarizing yourself with eclim's features.
First make sure eclimd is running (see the eclimd docs (|eclimd|) if
you are unsure how to start eclimd).
*gettingstarted-create*
Creating your first project
===========================
Once you've got eclimd running, open an instance of vim and create
your project like so:
Note: Android Users: the android section below contains additional
info regarding the creation of android projects.Maven Users: you may
refer to the maven section below for an alternate way to create a
java project.
>
:ProjectCreate /path/to/my_project -n java
<
This example creates a project with a java nature (-n java), but the
same method can be used to create a project for other languages by
simply changing the nature accordingly:
>
:ProjectCreate /path/to/my_java_project -n android
:ProjectCreate /path/to/my_c_project -n c
:ProjectCreate /path/to/my_cpp_project -n c++
:ProjectCreate /path/to/my_groovy_project -n groovy
:ProjectCreate /path/to/my_java_project -n java
:ProjectCreate /path/to/my_php_project -n php
:ProjectCreate /path/to/my_python_project -n python
:ProjectCreate /path/to/my_ruby_project -n ruby
:ProjectCreate /path/to/my_scala_project -n scala
<
The path supplied to the |:ProjectCreate| command will be the path to
the root of your project. This path may or may not exist. If it does
not exist it will be created for you. After you've created your
project, there will be a .project file added to your project's root
along with another file where references to your project's source
directories and any third party libraries your project uses reside.
The name of this file will vary depending on your project's nature,
but in all cases eclim will provide you with commands to manage this
file:
- java, android - .classpath file (|vim-java-classpath|)
- php, ruby - .buildpath file (|vim-dltk-buildpath|)
- c, c++ - .cproject, managed via the |:CProjectConfigs| command
- python - .pydevproject file (|vim-python-path|)
Once you've created your project you can use the :ProjectList command
to list the available projects and you should see your newly created
one in the list.
>
my_project - open - /path/to/my_project
<
The :ProjectList result is in the form of projectName - (open|closed)
- /project/root/path. When you create projects, the last path element
will be used for the project name. If that element contains any
spaces, these will be converted to underscores.
Adding project source directories
=================================
Before you can start writing code, you will first need to create and
register your project's source directories. If you created your
project from an existing code base, then this step may have been
perform automatically for you, but you should validate the settings to
be sure.
We will use a java project in this example but the steps for other
languages are very similar. Please see the relevant docs for your
language for more details:
- java and android (|vim-java-classpath|)
- php and ruby (|vim-dltk-buildpath|)
- c and c++ (|:CProjectConfigs|)
- python (|vim-python-path|)
For the purpose of this example we will assume that you will store
your source files at:
>
/path/to/my_project/src/java
<
So, given that location, you will need to open the file
/path/to/my_project/.classpath in Vim.
>
vim /path/to/my_project/.classpath
<
To add the source directory simply execute the following
>
:NewSrcEntry src/java
<
This will add the necessary entry to the end of your .classpath file.
The contents of this file should now look something like this:
>
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="output" path="bin"/>
<classpathentry kind="src" path="src/java"/>
</classpath>
<
Now that your source directory is setup, you can proceed to edit java
files in that directory and make use of the java functionality
(|vim-java-index|) provided by eclim.
*gettingstarted-coding*
Writing code in your new project
================================
Now that you have a project created, you can start writing code and
utilize the features that eclim provides.
Note: Below we'll walk through a trivial java example, but some of
the steps apply to all the languages that eclim supports, although
the command names may differ a bit. For additional docs on working
with the language of your choice, please see the relevant section of
the docs:
- c/c++ (|vim-c-index|)
- java (|vim-java-index|)
- php (|vim-php-index|)
- python (|vim-python-index|)
- ruby (|vim-ruby-index|)
- etc. (|vim-index|)
Lets get started writing our first java application using eclim.
1. First, navigate to your new project's source directory (src/java
in this example) and create any necessary package directories:
>
$ cd /path/to/my_project/src/java
$ mkdir -p org/test/
<
2. Then start editing your first java source file:
>
$ vim org/test/TestMain.java
<
>
package org.test;
public class TestMain
{
public static final void main(String[] args)
{
}
}
<
3. You can start to use some of the core features now. For
example, lets add the following code to the main method so we can
test eclim's source code validation:
>
System.
<
Then save the file and note that an error marker is placed in the
left margin of your file and when the cursor is on that line an
error message is printed at the bottom of your vim window. You can
also run :lopen to view all the errors in the file at once.
4. Now lets try out code completion. Place your cursor on the '.'
of 'System.' and start insert mode in vim using 'a', then follow
the example below:
>
System.<ctrl-x><ctrl-u> // starts the completion mode
System.<ctrl-n> // cycle through the completion suggestions
System.out // assuming you chose the 'out' suggestion
System.out.p<ctrl-x><ctrl-u> // now start completion again
System.out.p<ctrl-n> // hit <ctrl-n> until you get 'println'
System.out.println(
System.out.println("Hello World"); // finish up the example code.
<
5. After saving the file you should have no more validation errors,
so now we can run the code like so:
>
:Java
<
After running the :Java command in vim you should now see your
output in a new split window.
This only scratches the surface on the number of java features
(|vim-java-index|) that eclim provides, but hopefully this example was
enough to get you started.
*gettingstarted-android*
Android Users
=============
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.
*gettingstarted-maven*
Maven Users
===========
Creating your first project with maven can be accomplished using the
same method as any other java project, or you can utilize some of
maven's built in features to get your project started.
1. Run maven's generate archetype to create the project directory
and samples:
>
$ mvn archetype:generate
<
2. Once you've created the initial project directory, cd into that
directory and run the following command to generate the necessary
eclipse files:
>
$ cd <project_dir>
$ mvn eclipse:eclipse
<
3. Now you can start an instance of vim at the project's root
directory and run the following commands to:
- set the necessary eclipse classpath variable to point to your
maven repository.
- import your new project into eclipse.
>
$ vim
:MvnRepo
:ProjectImport /path/to/new/project
<
vim:ft=eclimhelp

329
vim/bundle/eclim/doc/index.txt Normal file
View File

@@ -0,0 +1,329 @@
*index*
Welcome to Eclim
****************
The power of Eclipse in your favorite editor.
What is it?
===========
Eclim provides the ability to access Eclipse (http://eclipse.org) code
editing features (code completion, searching, code validation, and
many more (|features|)) via the command line or a local network
connection, allowing those features to be integrated with your
favorite editor. Eclim provides an integration with Vim
(http://www.vim.org), but third party clients (|relatedprojects|) have
been created to add eclim support to other editors as well (emacs,
sublime text 2, textmate).
There are three primary usage scenarios in which eclim is designed to
be used:
[image]
1. The first scenario (|eclimd-headless|) is for those for which
vim is their primary editing interface. In this scenario you run a
headless instance of eclipse which all vim instances can then
communicate with to provide the various eclipse features.
2. The second scenario (|eclimd-headed|) is for those who prefer
using vim as their main interface, but frequently end up jumping
back to eclipse for any features not provided by eclim. In this
case you can run the eclim server inside of the eclipse gui and
then interact with it via external vim instances just like the
first scenario.
3. The last scenario (|gvim-embedded|) is for those who wish to use
the eclipse interface full time, but want to use gvim as an
embedded eclipse editor. Just like the previous use case, the eclim
server is run inside of the eclipse gui and the embedded gvim will
interact with it just like external vim instances would. This
feature is only support on Windows and Unix systems (where gvim is
compiled with the gtk gui).
Note: Please be aware that the embedded vim does not behave like
a standard eclipse editor. It's a separate program (vim) embedded
into eclipse, so eclipse features are provided by eclim's vim
plugins and not the usual eclipse key bindings, context menus,
etc. For those that just want vim like key bindings in their
eclipse editors, vrapper (http://vrapper.sourceforge.net/home/)
is an excellent alternative which provides exactly that.
Eclim is released under the GPLv3
(http://www.gnu.org/licenses/gpl-3.0-standalone.html).
How do I get/install it?
========================
You can follow the eclim install guide (|install|) which will walk you
through downloading and installing eclim.
How do I use it?
================
After you've installed eclim, you can refer to the getting started
(|gettingstarted|) page which will walk you through creating your
first project.
Where can I get help?
=====================
Mailing Lists
-------------
If at any time you have any questions or feedback, feel free to post
to one of the eclim mailing lists:
- eclim-user (http://groups.google.com/group/eclim-user): For all
questions regarding installation, usage, troubleshooting, etc.
- eclim-dev (http://groups.google.com/group/eclim-dev): For all
eclim development related discussions.
IRC (#eclim on freenode.net)
----------------------------
If you would like to get help or ask questions on IRC, then feel free
to join #eclim on freenode.net. Please note that I (Eric Van
Dewoestine, ervandew on irc) try to stay in the channel as much as
possible, but I might not be available to answer questions
immediately. It's also worth noting that I live in California, so if
you are in Europe, Asia, or some other timezone whose normal waking
hours don't overlap well with mine, then you may be better off getting
help using one of the mailing lists above.
How do I report a bug?
======================
Reporting Bugs
--------------
If you've found a bug please report the issue to either the eclim-dev
(http://groups.google.com/group/eclim-dev) mailing list or create a
new issue on eclim's github issue tracker
(http://github.com/ervandew/eclim/issues).
When reporting a bug, please include the following information:
- What OS are you on?
- Linux users: please include the distro and version.
- What version of eclim, vim, and eclipse are you using?
- Linux users: please indicate whether you installed eclipse via
your distro's package manager or not, and if not, please indicate
what distribution of eclipse you are using ("Eclipse Classic",
"Eclipse IDE for C/C++ Developers", some other eclipse bundle).
What's New?
===========
[image: Rss Feed for What's New][image] (index.rss)
Aug 24, 2014
------------
Eclim has finally been released with Eclipse Luna support. Please note
however that scala support is disabled in this release. I tried
waiting for a final release of ScalaIDE 4.0.0 for Luna, but I don't
want to hold up the rest of eclim any longer. If you want to use
eclim's scala support, you'll need to install the ScalaIDE 4.0.0
milestone and build eclim from the master git branch.
- Eclim 2.4.0 (|2.4.0|)
May 07, 2014
------------
Release of eclim for indigo users.
- Eclim 1.7.19 (|1.7.19|)
Apr. 12, 2014
-------------
Eclim has been updated to fix an issue on Windows that could prevent
many features from working.
- Eclim 2.3.4 (|2.3.4|)
Apr. 06, 2014
-------------
This release includes many bug fixes and refinements as well as a
rewrite of eclim's python support to utilize pydev instead of rope.
- Eclim 2.3.3 (|2.3.3|)
Warning: Any exiting eclim python projects you have should be
re-created with the new python nature:>
:ProjectCreate /path/to/project -n python
<
Sep. 12, 2013
-------------
This release fixes the extraction of the necessary vim files when
installing scala support.
- Eclim 2.3.2 (|2.3.2|) for Eclipse 4.3 (Kepler).
- Eclim 1.7.18 (|1.7.18|) for Eclipse 3.7/3.8 (Indigo).
Jul. 27, 2013
-------------
The previous eclim installer for Kepler was still pointing at the Juno
update site. This release remedies that.
- Eclim 2.3.1 (|2.3.1|) for Eclipse 4.3 (Kepler).
Jul. 21, 2013
-------------
The focus of this release is to bring eclim fully up to date with
Eclipse Kepler support. The installer for eclim 2.3.0 now requires
that you install against Kepler.
- Eclim 2.3.0 (|2.3.0|) for Eclipse 4.3 (Kepler).
- Eclim 1.7.17 (|1.7.17|) for Eclipse 3.7/3.8 (Indigo).
Jul. 14, 2013
-------------
This is primarily a bug fix release with a few new features. Unless
some critical error is found, this will be the last release targeting
Juno. The next release will likely target Kepler though this release
should work fine on Kepler as well, with the exception of scala
support which has not been tested. Indigo support will continue but
will likely end with the release of Luna, possibly sooner.
- Eclim 2.2.7 (|2.2.7|) for Eclipse 4.2 (Juno).
- Eclim 1.7.16 (|1.7.16|) for Eclipse 3.7/3.8 (Indigo).
May 18, 2013
------------
Eclim has been updated to support the Android Development Toolkit
version 22.0.0, scala is now supported for both Juno and Indigo, and
there are a few other improvements and many bug fixes.
- Eclim 2.2.6 (|2.2.6|) for Eclipse 4.2 (Juno).
- Eclim 1.7.14 (|1.7.14|) for Eclipse 3.7/3.8 (Indigo).
Nov. 25, 2012
-------------
The most notable change in this release is support for Eclipse 3.8
with the Indigo release (1.7.13). Both releases also include several
small bug fixes.
- Eclim 2.2.5 (|2.2.5|) for Eclipse 4.2 (Juno).
- Eclim 1.7.13 (|1.7.13|) for Eclipse 3.7/3.8 (Indigo).
Nov. 18, 2012
-------------
This is another bug fix release which includes support for the latest
Android development toolkit (21.0.0).
- Eclim 2.2.4 (|2.2.4|) for Eclipse 4.2 (Juno).
- Eclim 1.7.12 (|1.7.12|) for Eclipse 3.7 (Indigo).
Oct. 19, 2012
-------------
This is a bug fix release for Windows users which fixes executing of
eclim commands from vim:
- Eclim 2.2.3 (|2.2.3|) for Eclipse 4.2 (Juno).
- Eclim 1.7.11 (|1.7.11|) for Eclipse 3.7 (Indigo).
Oct. 07, 2012
-------------
Two new eclim updates are once again available with several bug fixes
and improvements.
- Eclim 2.2.2 (|2.2.2|) for Eclipse 4.2 (Juno).
- Eclim 1.7.10 (|1.7.10|) for Eclipse 3.7 (Indigo).
Sep. 09, 2012
-------------
Eclim 1.7.9 (|1.7.9|) for Eclipse 3.7 (Indigo) is now available.
This release adds initial support for scala (|vim-scala-index|).
Please note that the Scala IDE (http://scala-ide.org) , which eclim
uses to provide scala support, is not yet available for Eclipse 4.2
(Juno), so eclim's scala support will not be available for the eclim
2.2.x releases until sometime after the Scala IDE has been updated for
Juno.
Sep. 01, 2012
-------------
Another set of releases are now available for both Juno and Indigo.
These both include several bug fixes along with new support for
creating android projects.
- Eclim 2.2.1 (|2.2.1|) for Eclipse 4.2 (Juno).
- Eclim 1.7.8 (|1.7.8|) for Eclipse 3.7 (Indigo).
Eclim also has a newly redesigned site using the sphinx bootstrap
theme (https://github.com/ervandew/sphinx-bootstrap-theme).
Aug. 07, 2012
-------------
Two new versions of eclim have been released, one for the latest
Eclipse version, Juno, the other a bug fix release for the previous
version of Eclipse, Indigo.
- Eclim 2.2.0 (|2.2.0|) for Eclipse 4.2 (Juno).
- Eclim 1.7.7 (|1.7.7|) for Eclipse 3.7 (Indigo).
Jun. 07, 2012
-------------
Eclim 1.7.6 (|1.7.6|) is now available.
This is a minor bug fix release.
Jun. 03, 2012
-------------
Eclim 1.7.5 (|1.7.5|) is now available.
This is a minor release with an improved installer, some bug fixes, and a few
minor enhancements.
Apr. 22, 2012
-------------
Eclim 1.7.4 (|1.7.4|) is now available.
This is a bug fix release.
Mar. 18, 2012
-------------
Eclim 1.7.3 (|1.7.3|) is now available.
This version fixes numerious small bugs and adds a handful of small features.
Warning: Non vim users (emacs-eclim, subclim, etc.): The underlying
command response format for eclim has changed, which means that any
project relying on the old format isn't going to work. So if you are
installing eclim for use with a client other than vim, then be sure
to check with the client project to see if it has been updated for
eclim 1.7.3 or later.
Eclim News Archive (|archive-news|)
vim:ft=eclimhelp

593
vim/bundle/eclim/doc/install.txt Normal file
View File

@@ -0,0 +1,593 @@
*install*
Download / Install
******************
Requirements
============
Before beginning the installation, first confirm that you have met the
following requirements.
- Java Development Kit
(http://www.oracle.com/technetwork/java/javase/downloads/index.html)
1.7 or greater
- Vim (http://www.vim.org/download.php) 7.1 or greater
- Eclipse eclipse_version (http://eclipse.org/downloads/index.php)
- Mac and Linux users must also have make and gcc installed.
Minimum Vim Settings: In order for eclim to function properly, there
is a minimum set of vim options that must be enabled in your vimrc
file (:h vimrc).
- set nocompatible
Execute :h 'compatible' for more info. You can confirm that
compatibliity is turned off by executing the following in vim:
>
:echo &compatible
<
Which should output '0', but if not, then add the following to
your ~/.vimrc files (_vimrc on Windows):
>
set nocompatible
<
- filetype plugin on
Execute :h filetype-plugin-on for more info. You can confirm that
file type plugins are enabled by executing the following:
>
:filetype
<
Which should output 'filetype detection:ON plugin:ON indent:ON',
showing at least 'ON' for 'detection' and 'plugin', but if not,
then update your ~/.vimrc (_vimrc on Windows) to include:
>
filetype plugin indent on
<
Download
========
You can find the official eclim installer on eclim's sourceforge
downloads page (https://sourceforge.net/projects/eclim/files/eclim/):
- eclim_2.4.0.jar
(http://sourceforge.net/projects/eclim/files/eclim/2.4.0/eclim_2.4.0.jar/download)
Third Party Packages
--------------------
As an alternative to the official installer, there are also some
packages maintained by third parties:
- Arch: aur (eclim) (http://aur.archlinux.org/packages.php?ID=7291),
aur (eclim-git) (http://aur.archlinux.org/packages.php?ID=33120)
Installing / Upgrading
======================
Eclim can be installed a few different ways depending on your
preference and environment:
- Graphical Installer
- Unattended (automated) Installer
- Build from source
- Install on a headless server
*installer*
Graphical Installer
-------------------
Step 1: Run the installer
~~~~~~~~~~~~~~~~~~~~~~~~~
Note: If you have eclipse running, please close it prior to starting
the installation procedure.
- First download the installer: eclim_2.4.0.jar
(http://sourceforge.net/projects/eclim/files/eclim/2.4.0/eclim_2.4.0.jar/download)
- Next run the installer:
>
$ java -jar eclim_2.4.0.jar
<
Windows and OSX users should be able to simply double click on the
jar file to start the installer.
After the installer starts up, simply follow the steps in the wizard
to install eclim.
If your machine is behind a proxy, take a look at the instructions
for running the installer behind a proxy.
If you encounter an error running the installer, then consult the
known potential issues below.
Step 2: Test the installation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To test eclim you first need to start the eclim daemon. How you start
the daemon will depend on how you intend to use eclim.
Note: More info on running the eclim daemon can be found in the
eclimd (|eclimd|) docs.
If you plan on using eclim along with the eclipse gui, then simply
start eclipse and open the eclimd view:
Window ‣ Show View ‣ Other ‣ Eclim ‣ eclimd
By default the eclimd view will also be auto opened when you open a
file using:
Open With ‣ Vim
If you plan on using eclim without the eclipse gui, then:
- start the eclimd server.
- Linux / Mac / BSD (and other unix based systems): To start
eclimd from linux, simply execute the eclimd script found in your
eclipse root directory:
>
$ $ECLIPSE_HOME/eclimd
<
- Windows: The easiest way to start eclimd in windows is to double
click on the eclimd.bat file found in your eclipse root directory:
>
%ECLIPSE_HOME%/eclimd.bat
<
Once you have the eclim daemon (headed or headless) running, you can
then test eclim:
- open a vim window and issue the command, :PingEclim
(|vim-core-eclim#:PingEclim|). The result of executing this command
should be the eclim and eclipse version echoed to the bottom of your
Vim window. If however, you receive unable to connect to eclimd -
connect: Connection refused, or something similar, then your eclimd
server is not running or something is preventing eclim from
connecting to it. If you receive this or any other errors you can
start by first examining the eclimd output to see if it gives any
info as to what went wrong. If at this point you are unsure how to
proceed you can view the troubleshooting guide (|troubleshooting|)
or feel free to post your issue on the eclim-user
(http://groups.google.com/group/eclim-user) mailing list.
Example of a successful ping:
[image]
Example of a failed ping:
[image]
- Regardless of the ping result, you can also verify your vim
settings using the command :EclimValidate. This will check various
settings and options and report any problems. If all is ok you will
receive the following message:
>
Result: OK, required settings are valid.
<
*installer-proxy*
Running The Installer Behind a Proxy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you are behind a proxy, you may need to run the installer like so
(be sure to take a look at the related faq (|eclim-proxy|) as well):
>
$ java -Dhttp.proxyHost=my.proxy -Dhttp.proxyPort=8080 -jar eclim_2.4.0.jar
<
If your proxy requires authentication, you'll need to supply the
-Dhttp.proxyUser and -Dhttp.proxyPassword properties as well.
You can also try the following which may be able to use your system
proxy settings:
>
$ java -Djava.net.useSystemProxies=true -jar eclim_2.4.0.jar
<
*installer-issues*
Potential Installation Issues
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In some rare cases you might encounter one of the following errors:
1. Any exception which denotes usage of gcj.
>
java.lang.NullPointerException
at org.pietschy.wizard.HTMLPane.updateEditorColor(Unknown Source)
at org.pietschy.wizard.HTMLPane.setEditorKit(Unknown Source)
at javax.swing.JEditorPane.getEditorKit(libgcj.so.90)
...
<
Gcj (GNU Compile for Java), is not currently supported. If you
receive any error which references libgcj, then gcj is your current
default jvm. So, you'll need to install the openjdk or a jdk from
oracle to resolve the installation error.
2. >
java.lang.IncompatibleClassChangeError
at org.formic.ant.logger.Log4jLogger.printMessage(Log4jLogger.java:51)
...
<
This is most likely caused by an incompatible version of log4j
installed in your jave ext.dirs. To combat this you can run the
installer like so:
>
$ java -Djava.ext.dirs -jar eclim_2.4.0.jar
<
If you encounter an error not covered here, then please report it to
the eclim-user (http://groups.google.com/group/eclim-user) mailing
list.
*installer-automated*
Unattended (automated) install
------------------------------
As of eclim 1.5.6 the eclim installer supports the ability to run an
automated install without launching the installer gui. Simply run the
installer as shown below, supplying the location of your vim files and
your eclipse install via system properties:
>
$ java \
-Dvim.files=$HOME/.vim \
-Declipse.home=/opt/eclipse \
-jar eclim_2.4.0.jar install
<
Please note that when using this install method, the installer will
only install eclim features whose third party dependecies are already
present in your eclipse installation. So before installing eclim, you
must make sure that you've already installed the necessary
dependencies (for a full list of dependencies, you can reference
eclim's installer dependencies
(https://github.com/ervandew/eclim/blob/master/org.eclim.installer/build/resources/dependencies.xml)
file).
Required Properties:
- eclipse.home - The absolute path to your eclipse installation.
- vim.files (or vim.skip=true) - The absolute path to your vim files
directory. Or if you want to omit the installation of the vim files
(emacs-eclim users for example) you can supply -Dvim.skip=true
instead.
*install-source*
Building from source
--------------------
1. Check out the code:
~~~~~~~~~~~~~~~~~~~~~~
>
$ git clone git://github.com/ervandew/eclim.git
<
Note: If you are still using Eclipse 3.7 (Indigo) you will need to
checkout the eclim indigo branch before attempting to build eclim:>
$ cd eclim
$ git checkout indigo
<
2. Build eclim:
~~~~~~~~~~~~~~~
>
$ cd eclim
$ ant -Declipse.home=/your/eclipse/home/dir
<
Note: If your eclipse home path contains a space, be sure to quote
it:>
> ant "-Declipse.home=C:/Program Files/eclipse"
<
This will build and deploy eclim to your eclipse and vim directories.
Note: If your vimfiles directory is not located at the default
location for your OS, then you can specify the location using the
"vim.files" property:>
$ ant -Dvim.files=<your vimfiles dir>
<
When the build starts, it will first examine your eclipse installation
to find what eclipse plugins are available. It will then use that list
to determine which eclim features/plugins should be built and will
output a list like the one below showing what will be built vs what
will be skipped:
>
[echo] ${eclipse}: /opt/eclipse
[echo] # Skipping org.eclim.adt, missing com.android.ide.eclipse.adt
[echo] # Skipping org.eclim.dltk, missing org.eclipse.dltk.core
[echo] # Skipping org.eclim.dltkruby, missing org.eclipse.dltk.ruby
[echo] # Skipping org.eclim.pdt, missing org.eclipse.php
[echo] Plugins:
[echo] org.eclim.cdt
[echo] org.eclim.jdt
[echo] org.eclim.pydev
[echo] org.eclim.sdt
[echo] org.eclim.wst
<
In this case we can see that four eclim plugins will be skipped along
with the eclipse feature that would be required to build those
plugins. If you see an eclipse feature in that list that you know you
have, it may be the case that you installed it as a regular user, so
that feature was installed in your user local eclipse directory. In
that case you will need to notify the build of that directory so it
can examine it as well (just replace the <version> portion below with
the actual version found in your ~/.eclipse directory):
>
$ ant \
-Declipse.home=/opt/eclipse \
-Declipse.local=$HOME/.eclipse/org.eclipse.platform_<version>
<
If you don't want to supply the eclipse home directory, or any other
properties, on the command line every time you build eclim, you can
create a user.properties file at the eclim source root and put all
your properties in there:
>
$ vim user.properties
eclipse.home=/opt/eclipse
vim.files=${user.home}/.vim/bundle/eclim
<
Note: The eclim vim help files, used by the :EclimHelp
(|vim-core-eclim#:EclimHelp|) command, are not built by default. To
build these you first need to install sphinx
(http://sphinx-doc.org), then run the following command:>
$ ant vimdocs
<
This target also supports the vim.files property if you want the
docs deployed to a directory other than the default location.
*install-headless*
Installing on a headless server
-------------------------------
The eclim daemon supports running both inside of the eclipse gui and
as a "headless" non-gui server. However, even in the headless mode,
eclipse still requires a running X server to function. If you are
running eclim on a desktop then this isn't a problem, but some users
would like to run the eclim daemon on a truly headless server. To
achieve this, you can make use of X.Org's Xvfb server.
Note: This guide uses the Ubuntu server distribution to illustrate
the process of setting up a headless server, but you should be able
to run Xvfb on the distro of your choice by translating the package
names used here to your distro's equivalents.
The first step is to install the packages that are required to run
eclipse and eclim:
- Install a java jdk, xvfb, and the necessary build tools to compile
eclim's nailgun client during installation (make, gcc, etc).
>
$ sudo apt-get install openjdk-6-jdk xvfb build-essential
<
Then you'll need to install eclipse. You may do so by installing it
from your distro's package manager or using a version found on
eclipse.org (http://eclipse.org/downloads/). If you choose to install
a version from you package manager, make sure that the version to be
installed is compatible with eclim since the package manager version
can often be out of date. If you choose to install an eclipse.org
(http://eclipse.org/downloads/) version, you can do so by first
downloading eclipse using either a console based browser like elinks,
or you can navigate to the download page on your desktop and copy the
download url and use wget to download the eclipse archive. Once
downloaded, you can then extract the archive in the directory of your
choice.
>
$ wget <eclipse_mirror>/eclipse-<version>-linux-gtk.tar.gz
$ tar -zxf eclipse-<version>-linux-gtk.tar.gz
<
Note: Depending on what distribution of eclipse you installed and
what eclim features you would like to be installed, you may need to
install additional eclipse features. If you installed eclipse from
your package manager then your package manager may also have the
required dependency (eclipse-cdt for C/C++ support for example). If
not, you can install the required dependency using eclipse's p2
command line client. Make sure the command references the correct
repository for your eclipse install (juno in this example) and that
you have Xvfb running as described in the last step of this guide:>
DISPLAY=:1 ./eclipse/eclipse -nosplash -consolelog -debug
-application org.eclipse.equinox.p2.director
-repository http://download.eclipse.org/releases/juno
-installIU org.eclipse.wst.web_ui.feature.feature.group
<
For a list of eclim plugins and which eclipse features they require,
please see the installer dependencies
(https://github.com/ervandew/eclim/blob/master/org.eclim.installer/build/resources/dependencies.xml).
Note that the suffix '.feature.group' must be added to the
dependency id found in that file when supplying it to the
'-installIU' arg of the above command.
Once eclipse is installed, you can then install eclim utilizing the
eclim installer's automated install option (see the Unattended
(automated) install section for additional details):
>
$ java \
-Dvim.files=$HOME/.vim \
-Declipse.home=/opt/eclipse \
-jar eclim_2.4.0.jar install
<
The last step is to start Xvfb followed by eclimd:
>
$ Xvfb :1 -screen 0 1024x768x24 &
$ DISPLAY=:1 ./eclipse/eclimd -b
<
When starting Xvfb you may receive some errors regarding font paths
and possibly dbus and hal, but as long as Xvfb continues to run, you
should be able to ignore these errors.
The first time you start eclimd you may want to omit the 'start'
argument so that you can see the output on the console to ensure that
eclimd starts correctly.
Note: When starting the eclim daemon, you must start it as the same
user who will be running vim.
Upgrading
---------
The upgrading procedure is the same as the installation procedure but
please be aware that the installer will remove the previous version of
eclim prior to installing the new one. The installer will delete all
the org.eclim* eclipse plugins along with all the files eclim adds to
your .vim or vimfiles directory (plugin/eclim.vim, eclim/**/*).
*uninstall*
Uninstall
=========
To uninstall eclim you can use any eclim distribution jar whose
version is 1.7.5 or greater by running it with the 'uninstaller'
argument like so:
>
$ java -jar eclim_2.4.0.jar uninstaller
<
That will open a graphical wizard much like the install wizard which
will ask you again for the location of your vimfiles and eclipse home
where you've installed eclim and will then remove the eclim
installation accordingly.
Note: The uninstaller is backwards compatible and can be used to
uninstall older versions of eclim.
*uninstall-automated*
Unattended (automated) uninstall
--------------------------------
Like the installer, the uninstaller also supports an unattended
uninstall. You just need to supply your vim files and eclipse paths as
system properties:
>
$ java \
-Dvim.files=$HOME/.vim \
-Declipse.home=/opt/eclipse \
-jar eclim_2.4.0.jar uninstall
<
Required Properties:
- eclipse.home - The absolute path to your eclipse installation.
- vim.files (or vim.skip=true) - The absolute path to your vim files
directory. Or if you never installed the vim files (emacs-eclim
users for example) you can supply -Dvim.skip=true instead.
vim:ft=eclimhelp

22
vim/bundle/eclim/doc/relatedprojects.txt Normal file
View File

@@ -0,0 +1,22 @@
*relatedprojects*
Related Projects
****************
Eclim clients for other editors:
================================
- Emacs (emacs-eclim (http://github.com/senny/emacs-eclim))
- Sublime Text 2 (Subclim (http://github.com/JulianEberius/Subclim))
- Texmate (Eclim.tmbundle
(http://github.com/JulianEberius/Eclim.tmbundle))
Vim emulator plugins for Eclipse:
=================================
- Vrapper (http://vrapper.sourceforge.net) (free and open source)
- viPlugin (http://www.satokar.com/viplugin/index.php)
- Viable (http://viableplugin.com)
vim:ft=eclimhelp

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

@@ -0,0 +1,24 @@
*vim-c-complete*
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/bundle/eclim/doc/vim/c/index.txt Normal file
View File

@@ -0,0 +1,30 @@
*vim-c-index*
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/bundle/eclim/doc/vim/c/inspection.txt Normal file
View File

@@ -0,0 +1,59 @@
*vim-c-inspection*
*: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/bundle/eclim/doc/vim/c/project.txt Normal file
View File

@@ -0,0 +1,62 @@
*vim-c-project*
*: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

129
vim/bundle/eclim/doc/vim/c/search.txt Normal file
View File

@@ -0,0 +1,129 @@
*vim-c-search*
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>]
All of the results will be placed into the current window's location
list (:help location-list) so that you can easily navigate the
results.
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 location 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.
- 'lopen' - open the location list to display the result.
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:EclimLocationListHeight (Default: 10) - Sets the height in lines
of the location list window when eclim opens it to display search
results.
vim:ft=eclimhelp

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

@@ -0,0 +1,48 @@
*vim-c-validate*
*: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/bundle/eclim/doc/vim/code_completion.txt Normal file
View File

@@ -0,0 +1,127 @@
*vim-code_completion*
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/bundle/eclim/doc/vim/core/eclim.txt Normal file
View File

@@ -0,0 +1,172 @@
*vim-core-eclim*
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/bundle/eclim/doc/vim/core/history.txt Normal file
View File

@@ -0,0 +1,85 @@
*vim-core-history*
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/bundle/eclim/doc/vim/core/index.txt Normal file
View File

@@ -0,0 +1,12 @@
*vim-core-index*
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/bundle/eclim/doc/vim/core/locate.txt Normal file
View File

@@ -0,0 +1,111 @@
*vim-core-locate*
*: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

452
vim/bundle/eclim/doc/vim/core/project.txt Normal file
View File

@@ -0,0 +1,452 @@
*vim-core-project*
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
<
*: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.
*:ProjectBuild*
- :ProjectBuild [<project>]
Builds the current or supplied project.
*: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:EclimProjectProblemsQuickFixOpen*
- g:EclimProjectProblemsQuickFixOpen (Default: 'botright copen')
Specified 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.
*: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/bundle/eclim/doc/vim/core/util.txt Normal file
View File

@@ -0,0 +1,220 @@
*vim-core-util*
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/bundle/eclim/doc/vim/dltk/buildpath.txt Normal file
View File

@@ -0,0 +1,55 @@
*vim-dltk-buildpath*
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/bundle/eclim/doc/vim/groovy/complete.txt Normal file
View File

@@ -0,0 +1,16 @@
*vim-groovy-complete*
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/bundle/eclim/doc/vim/groovy/index.txt Normal file
View File

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

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

@@ -0,0 +1,35 @@
*vim-groovy-validate*
*: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/bundle/eclim/doc/vim/html/index.txt Normal file
View File

@@ -0,0 +1,159 @@
*vim-html-index*
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/bundle/eclim/doc/vim/index.txt Normal file
View File

@@ -0,0 +1,32 @@
*vim-index*
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/bundle/eclim/doc/vim/java/android.txt Normal file
View File

@@ -0,0 +1,70 @@
*vim-java-android*
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

218
vim/bundle/eclim/doc/vim/java/ant.txt Normal file
View File

@@ -0,0 +1,218 @@
*vim-java-ant*
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
(|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/bundle/eclim/doc/vim/java/classpath.txt Normal file
View File

@@ -0,0 +1,371 @@
*vim-java-classpath*
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/bundle/eclim/doc/vim/java/complete.txt Normal file
View File

@@ -0,0 +1,35 @@
*vim-java-complete*
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

77
vim/bundle/eclim/doc/vim/java/format.txt Normal file
View File

@@ -0,0 +1,77 @@
*vim-java-format*
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
=============
Currently source code formatting is only configurable via the eclipse
GUI. To do so, shutdown eclim, start the eclipse GUI and configure
your settings via:
>
Preferences : Java / Code Style / Formatter / Active Profile: / Edit
<
vim:ft=eclimhelp

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

@@ -0,0 +1,60 @@
*vim-java-import*
*: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

55
vim/bundle/eclim/doc/vim/java/index.txt Normal file
View File

@@ -0,0 +1,55 @@
*vim-java-index*
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)
- 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)
- 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

101
vim/bundle/eclim/doc/vim/java/inspection.txt Normal file
View File

@@ -0,0 +1,101 @@
*vim-java-inspection*
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!
<
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/bundle/eclim/doc/vim/java/java.txt Normal file
View File

@@ -0,0 +1,109 @@
*vim-java-java*
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

123
vim/bundle/eclim/doc/vim/java/javadoc.txt Normal file
View File

@@ -0,0 +1,123 @@
*vim-java-javadoc*
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
=============
Vim Settings (|vim-settings|)
*g:EclimJavaDocSearchSingleResult*
- g:EclimJavaDocSearchSingleResult (Default: 'open') - Determines
what action to take when only a singe result is found.
Possible values include:
- 'open' - open the result in a browser.
- 'lopen' - open the temp window to display the result.
- g:EclimLocationListHeight (Default: 10) - Sets the height in lines
of the location list window when eclim opens it to display search
results.
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

103
vim/bundle/eclim/doc/vim/java/logging.txt Normal file
View File

@@ -0,0 +1,103 @@
*vim-java-logging*
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
(|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/bundle/eclim/doc/vim/java/maven.txt Normal file
View File

@@ -0,0 +1,51 @@
*vim-java-maven*
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

245
vim/bundle/eclim/doc/vim/java/methods.txt Normal file
View File

@@ -0,0 +1,245 @@
*vim-java-methods*
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.
*: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/bundle/eclim/doc/vim/java/refactor.txt Normal file
View File

@@ -0,0 +1,171 @@
*vim-java-refactor*
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

229
vim/bundle/eclim/doc/vim/java/search.txt Normal file
View File

@@ -0,0 +1,229 @@
*vim-java-search*
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>]
All of the results will be placed into the current window's location
list (:help location-list) so that you can easily navigate the
results.
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 occurances.
- 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
=============
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.
- 'lopen' - open the location list to display the result.
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:EclimLocationListHeight (Default: 10) - Sets the height in lines
of the location list 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). By default this is enabled.
vim:ft=eclimhelp

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

@@ -0,0 +1,233 @@
*vim-java-unittests*
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", "-XX:MaxPermSize=128m"]
<
*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/bundle/eclim/doc/vim/java/validate.txt Normal file
View File

@@ -0,0 +1,142 @@
*vim-java-validate*
*: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

38
vim/bundle/eclim/doc/vim/java/webxml.txt Normal file
View File

@@ -0,0 +1,38 @@
*vim-java-webxml*
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
(|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/bundle/eclim/doc/vim/javascript/index.txt Normal file
View File

@@ -0,0 +1,66 @@
*vim-javascript-index*
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/bundle/eclim/doc/vim/php/buildpath.txt Normal file
View File

@@ -0,0 +1,58 @@
*vim-php-buildpath*
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/bundle/eclim/doc/vim/php/complete.txt Normal file
View File

@@ -0,0 +1,27 @@
*vim-php-complete*
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/bundle/eclim/doc/vim/php/index.txt Normal file
View File

@@ -0,0 +1,29 @@
*vim-php-index*
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

110
vim/bundle/eclim/doc/vim/php/search.txt Normal file
View File

@@ -0,0 +1,110 @@
*vim-php-search*
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>]
All of the results will be placed into the current window's location
list (:help location-list) so that you can easily navigate the
results.
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 location 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.
- 'lopen' - open the location list to display the result.
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:EclimLocationListHeight (Default: 10) - Sets the height in lines
of the location list window when eclim opens it to display search
results.
vim:ft=eclimhelp

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

@@ -0,0 +1,57 @@
*vim-php-validate*
*: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/bundle/eclim/doc/vim/python/complete.txt Normal file
View File

@@ -0,0 +1,21 @@
*vim-python-complete*
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/bundle/eclim/doc/vim/python/django.txt Normal file
View File

@@ -0,0 +1,285 @@
*vim-python-django*
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/bundle/eclim/doc/vim/python/index.txt Normal file
View File

@@ -0,0 +1,41 @@
*vim-python-index*
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/bundle/eclim/doc/vim/python/path.txt Normal file
View File

@@ -0,0 +1,100 @@
*vim-python-path*
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

78
vim/bundle/eclim/doc/vim/python/search.txt Normal file
View File

@@ -0,0 +1,78 @@
*vim-python-search*
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 location 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.
- 'lopen' - open the location list to display the result.
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:EclimLocationListHeight (Default: 10) - Sets the height in lines
of the location list window when eclim opens it to display search
results.
vim:ft=eclimhelp

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

@@ -0,0 +1,47 @@
*vim-python-validate*
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/bundle/eclim/doc/vim/refactoring.txt Normal file
View File

@@ -0,0 +1,42 @@
*vim-refactoring*
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/bundle/eclim/doc/vim/ruby/buildpath.txt Normal file
View File

@@ -0,0 +1,113 @@
*vim-ruby-buildpath*
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/bundle/eclim/doc/vim/ruby/complete.txt Normal file
View File

@@ -0,0 +1,25 @@
*vim-ruby-complete*
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/bundle/eclim/doc/vim/ruby/index.txt Normal file
View File

@@ -0,0 +1,11 @@
*vim-ruby-index*
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

115
vim/bundle/eclim/doc/vim/ruby/search.txt Normal file
View File

@@ -0,0 +1,115 @@
*vim-ruby-search*
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>]
All of the results will be placed into the current window's location
list (:help location-list) so that you can easily navigate the
results.
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 location 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.
- 'lopen' - open the location list to display the result.
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:EclimLocationListHeight (Default: 10) - Sets the height in lines
of the location list window when eclim opens it to display search
results.
vim:ft=eclimhelp

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

@@ -0,0 +1,48 @@
*vim-ruby-validate*
*: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/bundle/eclim/doc/vim/scala/complete.txt Normal file
View File

@@ -0,0 +1,22 @@
*vim-scala-complete*
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/bundle/eclim/doc/vim/scala/import.txt Normal file
View File

@@ -0,0 +1,35 @@
*vim-scala-import*
*: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/bundle/eclim/doc/vim/scala/index.txt Normal file
View File

@@ -0,0 +1,11 @@
*vim-scala-index*
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

49
vim/bundle/eclim/doc/vim/scala/search.txt Normal file
View File

@@ -0,0 +1,49 @@
*vim-scala-search*
*: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.
- 'lopen' - open the location list to display the result.
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:EclimLocationListHeight (Default: 10) - Sets the height in lines
of the location list window when eclim opens it to display search
results.
vim:ft=eclimhelp

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

@@ -0,0 +1,35 @@
*vim-scala-validate*
*: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

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

@@ -0,0 +1,38 @@
*vim-settings*
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/bundle/eclim/doc/vim/validation.txt Normal file
View File

@@ -0,0 +1,15 @@
*vim-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
<
vim:ft=eclimhelp

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

@@ -0,0 +1,211 @@
*vim-xml-index*
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