Tuncer Ayaz wrote:
if you're a hardcore vi user
I'm a hardcore Emacs user on a sabbatical trying to learn vim :-)
you might want to take a look at http://eclim.sf.net :-)
Looks interesting.
I've been using Vim for many years and after using some major modes
in Emacs I'm using Emacs for most coding jobs (of course with a custom
dotemacs) these days. Especially stuff like distel (Erlang mode) or
the Haskell mode which allows you to use Unicode symbols/characters
for stuff like lambda instead of '\' is great :D
For quite some time I used Emacs with JDEE and ECB, but it's just not
the same as Eclipse. I especially missed quickfix, so I had a stab at
jde-quickfix.el, but that, too, is not as smart as it should be. I got
stopped when I discovered that I had to parse Java syntax.
For example, quickfix in Eclipse offers to cast an expression. And when
I looked at the compiler error message and the Java code and thought
about finding the bounds of the expression to cast I got very depressed
and thought that was too much for me.
I had heard of the Semantic Bovinator, but it turns out its Java parsing
is way too shallow -- it does not parse down to the expression level.
I think that Jikes can mark the boundaries of the expression, but Jikes
does not support Java 5...
BTW, I never understood why viplugin is proprietary, paysoft and full of
bugs. Its just anoying to have to pay for that so bad implementation.
Well, it doesn't crash for me. New versions fix some old bugs, so I'm
not disgruntled.
I think I can get along better with viplugin than the Eclipse Emacs
keybindings because I am just a casual user of vim whereas I know many
features of Emacs. Therefore, something that emulates 70% of Emacs
(just the keybindings, not Lisp) will feel incomplete for me, whereas
something that emulates 70% of vim (just the keybindings, not the
scripting language) will feel okay.
I have used javascript implementations for replacing textareas in webs
emulating vi with more features than viplugin and for free.
Cool! I am a friend of Vimperator, so perhaps one of those could
cooperate with it to provide the vi/vim experience when editing
textareas, too?
Regarding lock-in: Our build infrastructure is based on make, and I
integrated Eclipse and the build infrastructure. This means all
projects can be built using make. There is no lock-in. (In fact, some
team members prefer Emacs, and some use vi. We all collaborate on the
same projects.)
Yeah, eclipse is a very standard tool. Using ANT is far more better than
using make. IMHO make is also a weird tool that should be replaced
anytime. Current GNU implementation is full of unnecessary stuff and it
highly depends on the shell so, it breaks portability.
I don't want to pick this fight. Make works for us.
Regarding power of the editor: With viPlugin, I get enough basic editor
functionality so that I do not feel restrained. Yet, the Eclipse Java
editor knows Java syntax and offers a much higher level of source code
editing. Specifically, we have refactoring and quickfix support, and
code completion and navigation.
I miss lot of functionalities. And the bugs on it makes sometimes loss
time trying to fail into insert mode.
See my 70% comment above.
Quickfix means that the editor recognizes common compilation problems
and offers corrections. I use that to speed up typing: I say String x =
someObject.someMethod(someArg);, then wait for the editor to flag the
compilation error, then let it correct the type of x. This means that I
don't have to remember the exact type that someMethod returns, and also
I get the import statement for free.
My guidelines are mostly based on C, I know that coding for
btw you can do all the same stuff inside vim with code autocompletion
(there is an elcipse backend for vim), syntax highlighting, automatic
indentation, etc..
I see. Eclim can probably do it. I'll have to look into this.
I wrote some shellscript to replace all these features from the
commandline to get list of methods, find strings on source files,
enable/disable debug printfs, etc.. Most of these features are easy to
implement in the shell and give you more control on the source than
using the common user interfaces for code autocompletion and so.
Do your shell scripts parse the code to figure out the type of the
object that completion is invoked on? Completing "x." should do
different things depending on the type of x.
With C, it's a lot easier.
But I understand that maybe I'm a big freak on this. I'm just offering
my POV over these topics. not trying to change the mind of anybody or
anything else :)
I am happy to learn about your POV. It might teach and old dog new
tricks ;-)
Kai
