JavaVi - vi/vim editor clone nbvi
Brought to you by:
err
With nb-15, can point suite properties into a maven project; jvi-nb-lib - yeneta: random methods to access into modules; funelled through nbvi-module/src/org/netbeans/modules/jvi/NB.java jvi-nb-windows - yenta: access to core.windows yenta-cluster - cluster copy into nbvi for VCS inclusion =========================================================================== NOTES vdiff /ref/nb/src/netbeans/ide/editor.completion/src/org/netbeans/spi/editor/completion/support/CompletionUtilities.java /src/jvi-dev/nbvi/nbvi-module/src/org/netbeans/modules/jvi/completion/CompletionUtilities.java Help understanding the nbm-maven-plugin The following is deprecated, http://bits.netbeans.org/mavenutilities/nbm-maven-plugin/nbm.html but the *same* stuff seems to be under <configuration>. There is additional stuff, can't find mention <verifyRuntime> Can access maven modules directly in platform.properties (aka module chaining?) NB-jVi-SPI/build/cluster:\ /src/jvi-dev/yenta/api/target/nbm/netbeans/extra:\ /src/jvi-dev/nbvi/jvi-lib/target/nbm/clusters/extra so the following is not needed +------------------------------------------------------------------ | jvi-lib-bridge, yenta-bridge are trivial projects their build/cluster | is symlinked to maven project <proj>/target/nbm/clusters/extra. See the | $jvi/nbvi/doc/mkbridge for something that sets up the links, or detects a | problem. BTW, make clean on the bridge wipes out the target/.../extra. | The bridge is used in the nbvi's cluster. The real (not bridge) stuff | are added as regular nbm's in the update center. +------------------------------------------------------------------ Trying to open any file @ActionRegistration( displayName="#LBL_openFile", iconBase="org/netbeans/modules/openfile/openFile.png", iconInMenu=false ) @ActionID(category="System", id="org.netbeans.modules.openfile.OpenFileAction") @ActionReference(path="Menu/File", position=800) public class OpenFileAction implements ActionListener { ide/utilities/src/org/netbeans/modules/openfile/OpenFile.java openFile(File f, int line) from openFileAction.actionPerformed openFile.openFile((files[i], -1) public static String open(FileObject fileObject, int line) { for (OpenFileImpl impl : Lookup.getDefault().lookupAll(OpenFileImpl.class)) { if (impl.open(fileObject, line)) { return null; } } return NbBundle.getMessage(OpenFile.class, "MSG_FileIsNotPlainFile", fileObject); } 1st is project open, which fails 2nd is openfile/DefaultOpenFileImpl After some amazingly complex stuff DefaultDataObject.open() - asks about binary file since getCookie(EditorCookie.class) is null - then getCookie(EditorCookie.class, true) the "true" is a "force" argument Give jVi access to "User Utilities" ide/utilities/nbproject/project.xml <friend>org.netbeans.modules.jvi</friend> =========================================================================== ALERT: NOTE: jVi-2.0 goes back to the NB caret and uses MIN_WIDTH property To fix https://issues.apache.org/jira/browse/NETBEANS-4940 things get messy. You can ignore this unless you want to modify the underlying caret code. Rather than depend on NetBeans' BaseCaret/ExtCaret jVi has copied the source into a Maven module, jvi-nb-caret, for building. They are renamed NbJviBaseCaret/NbJviExtCaret. Also included in this maven module is Yenta, though it is not used in this module, but rather in caret-wrapper. caret-wrapper is checked in with the jar files so you shouldn't have to build jvi-nb-caret. But if you want to, you also need to build yenta to get <yenta.version>1.2-SNAPSHOT</yenta.version>. (Perhaps in the future the "lib" artifact will be available in a released yenta version.) After building jvi-nb-caret, run nbvi/jvi-nb-caret/copy-caret-binaries.sh; this populates caret-wrapper with the new binaries. Edit the script to the the "base" variable. Note that jvi-nb-caret is a standalone project only use to generate the binaries for caret-wrapper. caret-wrapper is a library wrapper module and is in the nbvi module suite. Both jvi and nbvi should be checked out of the Mercurial repository, and they should reside in the same directory, eg jvi-srcdir. You can run nbvi (jVi in NB) from NB or use NB to build the modules needed to install jVi in NetBeans. Open the projects <srcdir>/nbvi (nbvi-suite) <srcdir>/nbvi/NBjVi-SPI <srcdir>/nbvi/jvi-help You can also open the following projects, but shouldn't be needed <scrdir>/nbvi/nbvi-module (jVi for NetBeans) <scrdir>/nbvi/jvi-wrapper (jVi Core) And note that <srcdir>/jvi can be opened; it is a plain old java project. It gets wrapped. It has the core jVi sources. It can be run and gives a standalone/debug jVi (with no netbeans). To build jVi with NetBeans, first build modules NB-jVi-SPI and jViHelp. Then you can RUN or DEBUG nbvi-suite; this starts up a copy of NB with jVi. This is all done from within NetBeans. FYI, if you look at properties for nbvi-suite you will see that under properties>Libraries, jViHelp and NB-jVi-SPI are added to the platform. If you want to install jVi, you'll need the NBMs; run target "Package as > NBMs" and look in nbvi/build/updates. You'll also need the modules for NB-jVi-SPI and jvi-help nbvi-module (aka jVi for NetBeans) is the module that interfaces jVi to NetBeans. This is all NetBeans code (and a few features that should be split/refactored to the jVi project). jvi-wrapper (aka jVi Core) is a module wrapper for the standalone jVi project; it is independent of NetBeans. A clean and build on the wrapper, does clean and build on the project. Some features of jVi in NetBeans, particularly the editor window move commands, use reflection to get at some internal NB capabilities. NB-jVi-SPI encapsulates this NetBeans access though either reflection or patching There are some additional modules that can be built and installed. jvi-help is a placeholder for future work. NOTE: patch-windows is no longer needed. patch-windows is a module suite that patches the NetBeans IDE. Its installation is optional. It provides support for resizing an editor window. It is used by jVi to set the size of a window as part of a window split/move and to implement the window resize commands.