Re: [dwm] Coding styles

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
Received on Fri Aug 01 2008 - 09:09:38 UTC